Internasjonale standarder

Transkript

1 Vedlegg 5A Forprosjektrapport Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller

2 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Forord Denne rapporten oppsummerer funn og kunnskap som er tilegnet i løpet av konseptfasen i prosjektet Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller. I rapporten gis en introduksjon av kontekst og begreper knyttet til informasjonsmodellering, samt en redegjørelse av nåsituasjon nasjonalt og internasjonalt. Rapporten er basert på presentasjoner og drøfting i nasjonale fora samt dialogmøter med internasjonale eksperter som har bred kunnskap om standarder og informasjonsmodeller. Dette arbeidet utføres innenfor fase 2 av prosjektet Internasjonale standarder. Fase 1 av prosjektet gjorde i 2016 vurderinger av et utvalg av internasjonale standarder innenfor ulike samhandlingsmodeller. Konseptfasen har pågått februar-juli Rapporten er utarbeidet juliaugust 2017 med bidrag fra hele prosjektgruppen. Innholdet i rapporten utgjør det faglige beslutningsgrunnlaget for videre arbeid i prosjektet. 2

3 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Innhold 1 Innledning Begrepsbeskrivelser Informasjonsmodell Felles informasjonsmodell Rammeverk for informasjonsmodeller Eksempler på innhold i et rammeverk for informasjonsmodeller Andre begreper Nåsituasjonsbeskrivelse Bakgrunn og problemstilling Dagens situasjon Registre og pasientjournaler Nasjonale meldingsdefinisjoner Spesialisthelsetjenestens arbeid med arketyper Anvendelse av felles informasjonsmodeller Rammeverk for vurdering Dialogmøter med nasjonale fagfora NIKT Fagforum arkitektur og Klinisk IKT fagforum Fagnettverk for informasjonsarkitektur Dagens situasjon internasjonalt Standarder og verktøy FHIR openehr DCM Detailed Clinical Models HL7 CDA Metode for informasjonsmodeller Australia USA Storbritannia Nederland Sverige Oppsummering rammeverk Felles modeller og oversettelse mellom standarder Utvalg av standarder [Rapportnummer] 3

4 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Myndighetsstyrt, brukerstyrt eller leverandørstyrt standardisering Små modeller eller store modeller Arenaer for samarbeid Oppsummering og videre arbeid Kilder

5 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Sammendrag Nasjonal e-helsestrategi og mål sier at det skal utredes og etableres «rammeverk og prinsipper for felles informasjonsmodeller». Med utgangspunkt i dette og konklusjoner fra fase 1: «Internasjonale standarder vurdering av internasjonale standarder», er følgende lagt til grunn for videre arbeid i prosjektet: Ulike internasjonale standarder for integrasjon benyttes til ulike formål Definisjonen av strukturert innhold for ett formål skal kunne gjenbrukes helt eller delvis for andre formål Basert på egne vurderinger og dialog med nasjonale og internasjonale fora, har prosjektet kommet frem til følgende problemstilling for videre arbeid: Hvordan kan man beskrive felles informasjonsmodeller slik at disse i størst mulig grad kan gjenbrukes for ulike formål med ulike internasjonale eller nasjonale standarder? Hvilket rammeverk (standarder, metoder, verktøy) og prinsipper skal man benytte? Erfaringer internasjonalt bekrefter at problemstillingen er godt kjent. Det har vært gjort ulike forsøk på å løse utfordringene i de land vi har sett på, og noen virker lovende. I det videre arbeidet vil det være viktig å se nærmere på de metodene som er under utvikling eller bruk i aktuelle land, og vurdere om dette kan gjenbrukes for nasjonale formål i Norge. Argonaut-prosjektet i USA, DCM-modellering i Nederland og etablering av felles informasjonsmodeller i Sverige er identifisert som relevante initiativ og metoder. Det er også relevant å jobbe videre med HL7 FHIR og openehr for å undersøke hvordan disse best kan samvirke og utfylle hverandre. Prosjektet skal i gjennomføringsfasen se nærmere på aktuelle rammeverk for felles informasjonsmodeller og gjøre vurderinger av disse. I arbeidet planlegges det videre oppfølging med flere av ekspertene som er konsultert så langt. 5

6 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 1 Innledning Denne rapporten oppsummerer erfaringer og kartlegging gjort i prosjektets konseptfase. I denne fasen har det blitt arbeidet med å undersøke og definere problemstillingen, kartlagt tilgjengelig dokumentasjon og innhentet erfaringer fra tilsvarende arbeid i andre land. Kapittel 2 gir en begrepsbeskrivelse av viktige konsepter. Kapittel 3 beskriver problemstillingen og dagens situasjon nasjonalt. Kapittel 4 oppsummerer erfaringer fra internasjonale initiativ som er kommet frem gjennom dialogmøter og gjennomgang av relevant dokumentasjon. 6

7 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 2 Begrepsbeskrivelser Begrepene «informasjonsmodell» og «felles informasjonsmodell» er sentralt for forståelsen av problemstillingen for prosjektet, og vil derfor bli nærmere beskrevet i dette kapitlet. 2.1 Informasjonsmodell En informasjonsmodell benyttes vanligvis til å beskrive en informasjonsmengde som skal implementeres i en eller flere tekniske løsninger og skal være «teknologinøytral». Modellene skal inneholde alle nødvendige klasser med attributter (egenskaper), samt alle relasjoner mellom klassene. De skal inneholde avgrensninger av verdiområdet for attributtene og kan også inneholde andre former for begrensninger og regler for informasjonsinnholdet. Begrepet informasjonsmodell brukes om både overordnede modeller som omfatter konsepter og relasjonene mellom dem, og om mer detaljerte modeller som også angir de enkelte dataelementene tilhørende hvert konsept. Figur 1 Eksempel på informasjonsmodell modellert i UML Kilder: [1] 7

8 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 2.2 Felles informasjonsmodell En felles informasjonsmodell skaper felles forståelse av et fagområde ved hjelp av begreper, definisjoner og sammenhenger mellom disse. En felles informasjonsmodell er uavhengig av løsning (implementasjon), system og teknologi. Slike felles modeller skal brukes sammen med andre metoder og teknikker til å lage nye informasjonsmodeller for applikasjoner slik at disse kan samhandle med hverandre. Bruk av felles informasjonsmodeller skal redusere behovet for å bygge spesifikke informasjonsmodeller for det enkelte bruksbehov. Felles informasjonsmodeller øker samhandlingsevnen mellom parter og deres løsninger av flere grunner: Nye modeller gjenbruker felles informasjonsmodeller som sikrer samhandlingsevnen til nye løsninger Eksisterende løsninger med lokale modeller bruker fellesmodellen som en felles referansemodell og bro for oversetting fra en modell til en annen Gjenbruk av fellesmodeller bidrar til at informasjon er definert likt utover det enkelte bruksbehov En fellesmodell kan gjenbrukes på flere måter, i hovedsak innebærer det enten å utvide modellen eller innskrenke den: Utvide med nye klasser, egenskaper eller relasjoner Snevre inn fellesmodellen ved å fjerne valgfrie egenskaper m.m. Spesialisere klasser, egenskaper eller relasjoner Kilder: [2] 2.3 Rammeverk for informasjonsmodeller Med rammeverk for informasjonsmodeller menes de standarder og spesifikasjoner som brukes for å representere informasjonsmodeller, verktøyene en bruker for å utarbeide og dokumentere informasjonsmodellene på ulike nivå, og stegene for å komme frem til en informasjonsmodell (metoden). Referanse til og bruk av terminologi og kodeverk kan også inngå i informasjonsmodeller, men prosjektet skal i denne sammenheng begrense seg til å beskrive forholdet til terminologi og kodeverk der det er nødvendig. Det pågår egne prosjekter innenfor terminologi og kodeverk (Målbilde for terminologi og kodeverk) som dette prosjektet må koordinere med. 8

9 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Figur 2 Rammeverk for informasjonsmodeller Figur 2 viser overordnet hvordan en ser for seg et rammeverk for informasjonsmodeller. Rammeverket består av flere metodesteg som f.eks. kan være å kartlegge behov, beskrive krav eller utforme selve modellen. Metodestegene kan basere seg på bruk av en eller flere standarder, f.eks. openehr arketyper som utgangspunkt for definisjon av strukturert innhold. Metodestegene vil også typisk bruke et eller flere verktøy som støtte, f.eks. et modelleringsverktøy for å utforme selve informasjonsmodellen. Resultatet av å bruke et slikt rammeverk for informasjonsmodeller er typisk en informasjonsmodell med tilhørende dokumentasjon Eksempler på innhold i et rammeverk for informasjonsmodeller Standarder: Verktøy: HL7 FHIR (logical models, profiler) openehr referansemodell, arketyper og templater ISO/EN referansemodell og arketyper Visual Paradigm for UML-diagram openehr CKM for kliniske modeller Forge FHIR Profile Editor Metode (elementer): Innhente krav fra klinikere, generelle kliniske modeller Sjekke av mot de tekniske standardene som skal benyttes Formalisere modellen i f.eks. en UML-notasjon Utarbeide ferdig modell med tilhørende dokumentasjon 9

10 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 2.4 Andre begreper Ord: Attributt Data HCIM (nl-zib) Forklaring: Egenskap Tolkbar representasjon av informasjon som er formalisert på en måte som forenkler kommunikasjon, tolkning eller prosessering Informasjonsmodeller brukt i Nederland "A HCIM is a model in the information layer, which defines the way in which (with regard to coding, unit of measurement, attributes etc.) a set of related data elements can be recorded in a system within a process, to allow interoperability at semantic level, if these data elements also need to be available in other processes (and associated systems) (such as allergies, present medication or current pregnancy)." Informasjon Interoperabilitet Kliniske modeller/kliniske informasjonsmodeller Prosessmodell Semantisk interoperabilitet UML Kunnskap knyttet til objekter som har en spesifikk mening i en bestemt kontekst Muligheten for å utveksle data mellom to datasystemer. Informasjonsmodell som beskriver kliniske begreper Abstrakt, formell og forenklet representasjon av en prosess slik den er eller bør være. Mulighet for datasystemer å utveksle informasjon med entydig og delt meningsinnhold Unified Modeling Language En industristandard for datarelatert modellering 10

11 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 3 Nåsituasjonsbeskrivelse 3.1 Bakgrunn og problemstilling Nasjonal e-helsestrategi og mål sier at det skal utredes og etableres «rammeverk og prinsipper for felles informasjonsmodeller». [3] Arbeidet i fase 1: «Internasjonale standarder vurdering av internasjonale standarder» [4] viste at det blant internasjonale standarder som kan brukes for interoperabilitet mellom systemer i helse- og omsorgstjenesten ikke finnes én standard som kan dekke alle formål, men at ulike standarder dekker ulike formål. Videre er det et uttalt ønske om at helseopplysninger skal kunne gjenbrukes for ulike formål (Innsatsområde 3 i strategien) både for primær- og sekundærformål. For eksempel ønsker man at informasjon som skal overføres til et EPJ-system eller register hentes direkte fra systemet det overføres fra. Det forutsetter at ulike formål benytter den samme definisjonen av innhold. Dette kan oppsummeres på følgende måte: Ulike internasjonale standarder for integrasjon benyttes til ulike formål Definisjonen av strukturert innhold for ett formål skal kunne gjenbrukes helt eller delvis for andre formål. Sammenstillingen av disse to punktene viser at informasjon som er definert og representert med en standard også må kunne representeres i en annen standard. Det betyr at man enten må kunne oversette innhold mellom standarder, eller lage en felles definisjon av strukturert innhold som kan representeres i de ulike standardene. Det er uhensiktsmessig å definere innhold flere ganger fordi dette er tidkrevende og kan føre til ulikheter mellom definisjonene (informasjonsmodellene). Det utløser i tillegg et behov for å definere et stort antall direkte transformasjoner mellom modellene for å understøtte interoperabilitet. Det bør derfor, i den grad det er mulig, legges opp til at man baserer seg på ett sett med felles, nasjonale informasjonsmodeller som kan gjenbrukes i alle bruksområder der de er relevante. Et felles rammeverk for informasjonsmodellering vil bidra til at felles informasjonsmodeller i størst mulig grad kan realiseres i ulike nasjonale og internasjonale standarder slik at behovene for semantisk interoperabilitet og gjenbruk av informasjon lettere kan ivaretas. 11

12 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Figur 3 Bruk av felles informasjonsmodell Figuren illustrerer at informasjonsmodeller utarbeidet ved hjelp av rammeverket bør kunne representeres i aktuelle internasjonale standarder, slik at modellen og rammeverket i minst mulig grad legger føringer for valg av teknisk løsning, standard eller produkt. Prosjektet vil arbeide videre med følgende problemstilling: Hvordan kan man beskrive felles informasjonsmodeller slik at disse i størst mulig grad kan gjenbrukes for ulike formål med ulike internasjonale eller nasjonale standarder? Hvilket rammeverk (standarder, metoder, verktøy) og prinsipper skal man benytte? 3.2 Dagens situasjon Registre og pasientjournaler Stortingsmelding 9 «Én innbygger, én journal» spesifiserer at man i fremtiden ønsker at «innrapportering til registre skal skje mest mulig automatisk, uten dobbeltregistrering, og være en integrert del av de faste arbeidsprosessene.». Dagens registre strukturerer informasjon på en måte som ikke stemmer overens med hvordan informasjonen registreres i EPJ. De forskjellige registrene har i stor grad ulike definisjoner av like kliniske begreper som heller ikke samsvarer med de modellene som ligger til grunn for EPJ-system eller som er definert i forbindelse med meldingsutveksling. Dette gjør det svært vanskelig å nå målet om automatisk innrapportering. For registre er det vanlig at for eksempel spørsmål om tidligere sykdommer blir formulert som «Har pasienten Sykdom X?», med svaralternativene «Ja», «Nei», og «Ukjent». I en strukturert journal vil en positiv tilstedeværelse registreres, slik at journalen enkelt vil kunne svare automatisk «Ja», men «Nei» og «Ukjent» er mer problematisk. For å kunne svare «Nei», må det dokumenteres en utelukkelse i journalen, som er mye vanskeligere å komme fram til og som har svært begrenset gyldighet. «Ukjent» har et definisjonsproblem: Betyr det at den som svarer ikke har informasjon, at man ikke har undersøkt, at man har undersøkt men ikke kommet fram til en konklusjon, eller noe annet? Denne typen forskjeller i tankegang og informasjonsmodeller mellom registre og pasientjournaler må avklares før man kan ha håp om å oppfylle ambisjonen i stortingsmeldingen. Felles nasjonale informasjonsmodeller som spenner over både registre og pasientjournaler kan være en hensiktsmessig måte å gjøre dette på. 12

13 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Denne typen mismatch eksisterer også i betydelig utstrekning mellom forskjellige kliniske systemer, der informasjonsmodellene ofte er utarbeidet i isolasjon fra andre løsninger. Dersom informasjon i kliniske løsninger som det kan være aktuelt å utveksle ikke samsvarer med felles informasjonsmodeller, kan det være vanskelig å oppnå semantisk interoperabilitet (f.eks. mellom et kjerne-epj og et fagspesifikt system på et sykehus) Nasjonale meldingsdefinisjoner I dag er informasjonsmodellene som benyttes for meldingsutveksling tett knyttet til utvekslingsformat. Hver standard har sin egen informasjonsmodell og samme informasjon vil derfor kunne modelleres ulikt på tvers av standardene. Det er få/ingen overordnede informasjonsmodeller som beskriver helsefaglig informasjon uavhengig av utvekslingsformat og bruksområde. Informasjonsmodellene dokumenteres ved bruk av UML, og XML-skjema for utveksling generes automatisk fra disse. Figur 4 Dagens rammeverk for informasjonsmodeller Figur 4 viser dagens rammeverk som tradisjonelt har vært brukt for utvikling av informasjonsmodeller for meldingsutveksling i Direktoratet for e-helse. Metodestegene består av å innhente og utforme krav som så blir modellert i en informasjonsmodell i UML. Basert på UML-modellen blir det generert XML schema som blir det tekniske utvekslingsformatet. Basert på UML-modellen blir det også laget tilhørende dokumentasjon, typisk et dokument. Til metodestegene brukes det ulike verktøy, primært Visual Paradigm for modellering, Altova XML Spy for XML-håndtering og Microsoft Word for dokumentasjon. Ved utvikling av informasjonsmodell og XML-schema for et konkret behov gjenbrukes det som tidligere er modellert i andre standarder til andre bruksbehov. Gjenbruk består i praksis hovedsakelig av at tidligere modellert informasjon blir kopiert inn i en ny modell, men en har noen felleskomponenter (f.eks. for pasient, avsender og mottaker) som en ikke behøver å kopiere/modellere på nytt, men gjenbruker via felleskomponenten. Tilsvarende gjelder for gjenbruk på XML-schema nivå. 13

14 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Rammeverksbeskrivelse Dagens rammeverk og prinsipper for felles informasjonsmodeller nasjonalt: Metode o Kravspesifikasjoner utarbeides i samarbeid med helsefaglige brukere og jurister. o Informasjonsmodellene utarbeides på grunnlag av kravspesifikasjonene i samarbeid med helsefaglige brukere. o Gjenbruk fra andre (nasjonale) informasjonsmodeller/standarder? o Lover og forskrifter som rammebetingelser Verktøy o UML + dokumentasjon o XML Standard o Uavhengig av standard Resultatet av dette rammeverket er en informasjonsmodell som er beskrevet i både grafisk og tekstlig form. Informasjonsmodellene publiseres som en integrert del av de standardene modellene inngår i. Dersom informasjonsmodeller gjenbrukes i en annen standard, gjentas vanligvis også informasjonsmodellen og beskrives på nytt i den nye standarden Svakheter/utfordringer ved dagens rammeverk UML kan være vanskelig å forstå for klinikere og andre brukere Det er lite hensiktsmessig metode for gjenbruk (dårlig verktøystøtte, kopiering i stedet for å referere) Sterk kobling til konkrete anvendelser og utvekslingsformat Mangler prosess og verktøy for utvikling av kravspesifikasjoner. Mangler støtte for overgang fra krav til informasjonsmodell. Mangler rutiner for avsjekk av informasjonsmodeller mot internasjonale standarder. Flere kilder til informasjon fører til avvik (PDF-dokumenter, Volven) Ikke verktøystøtte for review på modell-nivå eller XSD-nivå, vanskelig å kommunisere innspill til endringer Spesialisthelsetjenestens arbeid med arketyper Spesialisthelsetjenesten har gjennom Nasjonal IKT siden 2008 utredet og siden 2014 arbeidet aktivt med å utvikle en katalog av felles kliniske informasjonsmodeller, ved hjelp av metodikk, verktøy og standarder fra openehr. Informasjonsmodellene brukes i dag i DIPS Arena, og i flere registre og primærhelsesystemer som er under testing. Arketypeprinsippet baserer seg på å standardisere mange relativt små modeller for kliniske konsepter, som settes sammen og tilpasses til konkrete bruksområder. Disse kan benyttes direkte som implementasjonsartefakter i modelldrevet utvikling, eller som referanse for andre utviklingsmetodikker. På den måten er innholdsdefinisjonene frikoblet fra både teknologi og brukerhistorier. 14

15 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Informasjonsmodellene publiseres som openehr arketyper på og gjennomgås av klinikere under oppsyn av et redaksjonsutvalg. Figur 5 Rammeverk for detaljerte kliniske modeller i spesialisthelsetjenesten Rammeverksbeskrivelse Informasjonsmodellene publiseres som frittstående detaljerte kliniske informasjonsmodeller i form av openehr arketyper, på Arketyper inneholder dokumentasjon og potensielt oversettelser som en del av modellspesifikasjonen. Ved utvikling kartlegges behov i samarbeid med initiativtakere og relevant helsepersonell og dokumenteres som tankekart. På dette nivået omfatter behovet som regel et informasjonsbehov som går over flere enn én arketype, og i mange tilfeller er en eller flere nødvendige arketyper allerede modellert og kan gjenbrukes direkte. Modeller fra internasjonalt arbeid gjenbrukes i stor grad, de oversettes da til norsk. I de tilfellene der arketyper må utvikles fra bunnen gjøres dette av helseinformatikere, før arketypen gjennomgår en iterativ høringsprosess og godkjenning, der høringskravene for den enkelte arketype defineres av et redaksjonsutvalg. De viktigste verktøyene i rammeverket er openehr-spesifikasjonene, Xmind, Archetype Editor, og Clinical Knowledge Manager Svakheter/utfordringer ved dagens rammeverk De mer komplekse informasjonsmodellene kan være vanskelig å forstå for klinikere og andre, spesielt når de er fristilt fra en konkret brukerhistorie Mangler verktøystøtte for overgang fra tankekart til arketype Mangler rutiner for avsjekk av informasjonsmodeller mot internasjonale standarder utover openehr. Det er utfordrende å rekruttere klinikere til høringer 15

16 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Det kan være mer utfordrende å utvikle generiske informasjonsmodeller enn modeller for en spesifikk brukerhistorie 3.3 Anvendelse av felles informasjonsmodeller For å oppnå semantisk interoperabilitet mellom systemer er det nødvendig å standardisere informasjonen. For å kunne forenkle prosessen og sørge for at aktørene samarbeider godt for å bidra til økt grad av semantisk interoperabilitet, er det avgjørende at man tilrettelegger for gjenbruk og sikrer et felles utgangspunkt gjennom felles informasjonsmodeller. Et rammeverk for informasjonsmodellering vil være nyttig for dem som utvikler informasjonsmodeller og standarder, men også leverandører og utviklere av nasjonale løsninger. Det vil også gjøre det enklere for flere aktører å bidra til dette arbeidet. Dette prosjektet vil vurdere å bruke et konkret case som testgrunnlag for arbeidet med verifisering av rammeverket. I arbeidet med å identifisere et case vil det bli lagt vekt på å finne pågående prosjekter som vil kunne ha nytte av et samarbeid for å få definert informasjonsmodeller med utgangspunkt i anbefalt rammeverk. Det er ikke tatt endelig stilling til om verifikasjon av rammeverket vil være en del av dette prosjektet eller gjøres i en senere fase/prosjekt. Prosjektet har også beskrevet en rekke brukerscenarier og -historier rundt behovet for informasjonsmodeller som kan bidra til å utarbeide vurderingskriteriene for rammeverkene 3.4 Rammeverk for vurdering Det er identifisert en liste med aktuelle rammeverk som skal vurderes. Noen av disse er rene standarder, andre kommer med verktøy og metode for å utvikle informasjonsmodeller. Listen under har derfor ikke direkte sammenlignbare elementer, men det må gjøres en vurdering i gjennomføringen av prosjektet hvordan man best skal dele inn og sammenligne ulike rammeverk for felles informasjonsmodeller til vurdering. Så langt er det identifisert følgende rammeverk/standarder/metoder for videre arbeid: Direktoratets standarder dagens modellering (UML) Clinical Information Modelling Initiative (CIMI) Detailed Clinical Models (DCM) openehr arketyper CEN/ISO HL7 FHIR profiler og Logical models HL7 CDA Clinical Statements HL7 version 3 16

17 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 3.5 Dialogmøter med nasjonale fagfora Prosjektet har blitt presentert i ulike fagfora i Nasjonal IKT (NIKT) og Fagnettverk for informasjonsarkitektur for å få innspill om deres tanker om nytte, gevinster og behov NIKT Fagforum arkitektur og Klinisk IKT fagforum Prosjektet drøftet arbeidet i et felles møte for NIKT Fagforum arkitektur og Klinisk IKT fagforum Nasjonal IKT mener at den praktiske anvendelsen av resultatene må synliggjøres bedre. Hvordan skal klinikerne få nytte av dette i hverdagen? Det ble foreslått å se på case som setter pasient/innbygger i fokus. Det ble stilt spørsmål om behovene kommer fra brukerne eller fra myndighetene. Det var diskusjon om scope omfatter både utveksling og lagring av informasjon. Prosjektet vil ikke avgrense scopet til bare å omfatte utveksling. NIKT Fagforum arkitektur og Klinisk IKT fagforum foreslår at arbeid med dette blir en del av utviklingsprosjekter, slik at det ikke er ett stort prosjekt som skal gjøre dette, men at utviklingen skjer gjennom mindre deler hvor hvert prosjekt bidrar Fagnettverk for informasjonsarkitektur Prosjektet presenterte arbeidet i fagnettverk for informasjonsarkitektur (Nasjonal IKT) Det er blitt gjennomført et arbeid med informasjonsmodeller i Østfold for Helse SørØst som tidligere har blitt presentert i fagnettverket. Dette kan være interessant å få mer informasjon om. Fagnettverket anbefaler å benytte standarder som er holdbare over tid når det gjelder informasjonen, uavhengig av bytte av leverandør eller system. De mener også at det er viktig å involvere ulike aktører som helsepersonell, leverandører og helsedirektoratet når innholdet i informasjonsmodellene skal defineres. Det blir poengtert at det er viktig med et godt begrepsapparat mellom klinikere og teknikere. 17

18 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 4 Dagens situasjon internasjonalt Det er gjennomført dialogmøter med flere internasjonale fageksperter i konseptfasen. Møtene har vært med både representanter for spesifikke standarder/ standardiseringsorganisasjoner og representanter for myndigheter i ulike land. Det har derfor vært spissede agendaer og tema for hvert møte. Hensikten har vært å få et første overblikk over de viktigste kjente standarder, metoder og verktøy i et utvalg land. Oversikten tar ikke mål av seg å være en komplett status for alle land og rammeverk, men vil brukes i det videre arbeidet til å avklare prioriteringer og fokusområder. Situasjonsbeskrivelsen er basert på den informasjonen som kom frem i møtene med de representantene vi snakket med. Det vil derfor kunne være alternative oppfatninger hvis man hadde snakket med andre personer. Navn: Nasjonalitet: Representant for: Møtedato Ian McNicoll Storbritannia openehr Foundation Richard Kavanagh Storbritannia NHS (Det engelske helsevesenet) Graham Grieve Australia HL7 FHIR Ewout Kramer Nederland Furore Michael van der Zel Nederland University Medical Center Groningen Tabell 1 Oversikt over dialogmøter 4.1 Standarder og verktøy FHIR HL7 FHIR (Fast Healthcare Interoperability Resources) er en standard fra HL7 for integrasjon/kommunikasjon av helseopplysninger mellom EPJ-systemer. FHIR er basert på gjenbrukbare modulære komponenter, kalt ressurser, som er basis for alle anvendelser av FHIR. Det er gjennom disse ressursene man i hovedsak kan benytte FHIR til informasjonsmodellering. FHIR inneholder definisjoner av informasjon for de vanligste bruksområdene, men kan utvides og begrenses for å møte spesifikke behov i det enkelte bruksscenario. Det er tilgjengelig verktøy for å lage og dele profiler av FHIR ressurser, både kommersielle og gratis (åpen kildekode). FHIR kan også benytte en generell ressurs til å uttrykke logiske modeller, som senere kan oversettes eller transformeres til ressurser. Dette kan være spesielt hensiktsmessig for å kunne spesifisere logiske krav til innhold uten å ta stilling til hvordan disse skal uttrykkes gjennom eksisterende ressurser. Det er lite spesifikk verktøystøtte for dette og det er heller ikke nærmere beskrevet i FHIR. 18

19 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller openehr openehr tilbyr et sett med spesifikasjoner for implementasjon av grensesnitt i journalsystemer. I denne sammenhengen er det imidlertid først og fremst verktøy for modellering av klinisk informasjon og definisjon av slike modeller som er relevante. openehr baserer seg på en tonivåmodellering der klinisk informasjon kan modelleres som arketyper og templater basert på en referansemodell uten inngående kjennskap til underliggende realisering. Det kan være gode grunner til å bruke openehr som modelleringsverktøy selv om en bruker andre standarder som utvekslingsformat: openehr er bra til klinisk modellering og har verktøy og støtte for dette openehr definerer klinisk innhold og er en god kilde for dette, og det vil være uhensiktsmessig å ignorere dette i et utviklingsperspektiv DCM Detailed Clinical Models Detailed Clinical Models (DCM) beskriver et sett med krav og prosesser til modellering av logiske informasjonsmodeller som representerer klinisk informasjon. DCM skal være uavhengig av teknologien som benyttes for implementasjon og kan også beskrives med bruk av ulike notasjoner. Det sentrale poenget med DCM er å beskrive kliniske begreper med attributter, datatyper og bindinger til kodeverk på en slik måte at det er tilstrekkelig for at både utviklere, klinikere og andre interessenter skal kunne forstå innholdet og konteksten. DCM angir i seg selv ikke noen spesifikke verktøy, men i praksis benyttes ofte UML og tilhørende verktøy for å definere informasjonsmodeller. I motsetning til flere andre standarder omfatter imidlertid ikke DCM hvordan modellene skal realiseres for lagring eller utveksling til det må det velges andre standarder som for eksempel HL7 FHIR, openehr eller HL7 CDA HL7 CDA HL7 CDA R2 (Clinical Document Architecture) er en internasjonal standard fra HL7. CDA er et rammeverk/dokumentstandard som beskriver struktur og semantikk for kliniske dokumenter, ment for utveksling mellom ulike helseaktører. Eksempler på slike kliniske dokumenter er henvisninger, epikriser og laboratoriesvar. CDA er en generisk dokumentstandard som består av en header-del og en body-del. Innholdet i headeren er stort sett likt for alle anvendelser av CDA og inneholder blant annet pasient, dokumenttype, forfatter og mottaker av dokumentet. Body-delen inneholder den kliniske informasjonen, og den kan enten være i form av et fil-vedlegg (NonXMLBody) eller en xml-struktur som kan ha ulike nivå av strukturert informasjon (StructuredBody). 4.2 Metode for informasjonsmodeller I dette kapitlet beskrives metoder for utvikling av informasjonsmodeller i de enkelte land som er undersøkt. De enkelte stegene i metoden er nærmere beskrevet i tabellform. 19

20 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Australia Australia har spesifisert og dokumentert en rekke informasjonsmodeller for bruk i nasjonale løsninger. Det er definert et rammeverk for en prosess som bruker flere ulike standarder for stegene fra kliniske krav og konsept til tekniske modeller som kan implementeres. Steg Beskrivelse 1 Involvering av klinikere for å definere krav til dokumentasjon og definisjon av kliniske konsept gjennom bruk av openehr CKM. 2 Spesifisere teknologiuavhengig informasjonsmodell med bruk av DCM. Hensikt Definere brukernes krav og behov til dokumentasjon av konsepter Formalisere krav og definisjon til entydig beskrivelse. 3 Structured Document Definition Formalisere sammensatte logiske dokumentstrukturer basert på en eller flere teknologiuavhengige informasjonsmodeller 4 Spesifisere teknisk informasjon for utveksling av dokumenter gjennom HL7 CDA profiler. Formalisere teknisk (teknologiavhengig) regelsett for utveksling av de logiske dokumentstrukturene Tabell 2 Metodesteg Australia Australia har tatt utgangspunkt i det kliniske behov og forsøkt å bruke dette til å styre implementasjonene hos leverandører. Utviklingen i Australia har vært sterkt drevet av myndigheter med involvering hovedsakelig fra klinikere og brukerrepresentanter. Leverandører har i liten grad vært involvert i arbeidet. Det er brukt til dels store ressurser på å utarbeide informasjonsmodeller og spesifikasjoner, men som i liten grad har blitt implementert av leverandørene og dermed i liten grad har blitt tatt i bruk. Noe av årsaken tilskrives manglende involvering av leverandører slik at avstanden mellom ønsket informasjonsmodell og det leverandørene er i stand til å implementere har blitt for stor. Kilde: [11] USA I USA har leverandørene hatt stor påvirkning og vært en aktiv «driver» i arbeidet med standardisering og det har vært fokus på å skape engasjement blant flere aktører. Leverandørsektoren valgte selv standard, men erfaringene tilsier at det bare er mulig å standardisere til et visst nivå. Myndighetssiden har ikke hatt en like sentral rolle som f.eks. i Australia. Fokus har vært på å standardisere representasjonen av informasjon som allerede finnes strukturert i systemer, og mindre på å strukturere journalsystemer. Steg Beskrivelse Hensikt 20

21 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 1 Kartlegge tilgjengelig struktur hos leverandørene 2 Identifisere og formelt spesifisere struktur som er felles og prioritert gjennom bruk av HL7 FHIR profiler. 3 Avstemme med kliniske behov og prioriteringer Identifisere mengden informasjon som kan standardiseres Formalisere krav og definisjon til entydig beskrivelse gjennom HL7 FHIR profiler Sikre at FHIR profilene dekker formålet tilstrekkelig. Tabell 3 Metodesteg USA Argonautprosjektet, et initiativ fra privat sektor for å fremme bruk av standarder for interoperabilitet, har hatt ansvar for krav og test. Gjennom felles interesse for å oppnå et resultat skaper man en drivkraft som gjør det enklere å nå målet. Det ble fokusert på «community» av brukere, leverandører og utviklere. Argonautprosjektet fokuserer på hva som er realistisk å kunne levere med utgangspunkt i prioriterte behov. Kilder: [5][11] Storbritannia INTEROPen ble etablert for å fremme nasjonal interoperabilitet. Det er et åpent samarbeid mellom enkeltpersoner, industri, standardiseringsorganisasjoner og helsepersonell som utvikler åpne standarder for interoperabilitet i helse- og sosialsektoren. Arbeidet inkluderer datautveksling, datavalidering, API er og styring og har fokus på informasjonsnivået. Steg Beskrivelse Hensikt 1 Skisse til kliniske konsepter Få etablert brukernes krav til dokumentasjon av konsepter 2 Identifisere og formelt spesifisere struktur som er felles og prioritert gjennom bruk av HL7 FHIR profiler. Formalisere krav og definisjon til entydig beskrivelse gjennom HL7 FHIR profiler Tabell 4 Metodesteg Storbritannia Det er gjort forsøk på bruk av flere forskjellige standarder, men målet er nå å ta i bruk HL7 FHIR og bygge et bibliotek av profiler som kan implementeres for å forenkle integrasjon og interoperabilitet. Leverandørene har selv valgt å benytte FHIR og for industrien dekker informasjonsmodelleringen i FHIR behovene. Det er utarbeidet felles informasjonsmodeller (profiler) basert på FHIR gjennom INTEROPen. Man fokuserer kun på utveksling, ikke lagring, da det er ansett som det eneste man kan ha påvirkning på. Arbeidet tar utgangspunkt i modelleringsteknisk enkle skisser utarbeidet av den kliniske ekspertisen, som så danner grunnlaget for arbeidet med å etablere FHIR profiler. Klinikerne er også involvert og dedikert til arbeidet. Kilder: [6] [10] 21

22 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Nederland I Nederland bidrar programmet «Clinical documentation at the point of care» til strukturert forbedring av dokumentasjon og gjenbruk av pasientinformasjon mellom ulike brukere i helsesektoren. Steg Beskrivelse 1 Identifisere og definere informasjonsmodeller med bruk av DCM. Verktøyene inkluderer UML og tekstlig beskrivelse. 2 Vurdere informasjonsmodellene mot eksisterende strukturert informasjon i relevante systemer («sanity check») Hensikt Få etablert brukernes krav til dokumentasjon av konsepter og relasjonen mellom disse. Sikre at informasjonsmodellene kan realiseres i systemer. Dersom det er for stor avstand mellom hva systemene kan levere og hva informasjonsmodellen krever, må modellen revideres. Tabell 5 Metodesteg Nederland Sentralt i dette programmet står utarbeidelsen av ZIB s (Eng. HCIM), «byggesteiner» av helseinformasjon i DCM format, i den hensikt å etablere en felles modell for helseinformasjon. ZIB s modelleres i UML hvor datatypedefinisjonene i modellene er logiske typer og ikke direkte implementerbare, som f.eks. «PQ - Physical quantity.» I arbeidet ønsker man ikke å være koblet til en standard, eksempelvis HL7 v3 eller openehr, da disse standardene vil være for tett koblet til implementasjon. Målet er å lage den logiske modellen (felles informasjonsmodell). Det har vært utført «sanity checks» innenfor noen sykehussystemer hvor målet har vært å identifisere gap mellom DCM/ZIB og implementasjon. Der hvor gapet har vært for stort har man revurdert ZIB ene. MedMij er en pasientportal som har definerte FHIR profiler basert på logiske modeller for utveksling av informasjon, og her skal det gjøres compliance test knyttet til ZIB ene. Kilder: [7] [12] Sverige Socialstyrelsen i Sverige har tatt et nasjonalt koordineringsansvar for den semantiske interoperabiliteten gjennom å utvikle og kvalitetssikre en felles Nasjonal Informasjonsstruktur (NI). Dette gjøres i samarbeid med informatikere, jurister og terminologer ved en systematisk gjennomgang av begrepsområder. Metoden baseres på en internasjonal standard for informasjonsarkitektur ISO/IEC/IEEE Steg Beskrivelse 1 Identifisere og beskrive overordnet klinisk prosessmodell og de stegene som inngår. Hensikt Etablere rammer for området som skal defineres. 22

23 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller Modellen inneholder beskrivelse av input og output for hvert steg. 2 Identifisere begreper og strukturere disse i en overordnet begrepsmodell. Benytter UML klassediagram for å dokumentere begreper med assosiasjoner mellom disse. 3 Utarbeide informasjonsmodell med utgangspunkt i de definerte begrepene. Dette inkluderer å spesifisere attributter og datatyper. UML klassediagram og tekstlig beskrivelse benyttes for dokumentasjon. 4 Spesifisere gyldige kodeverk og/eller kodeverdier for alle attributter av den datatype. Dokumenteres som tekst. Identifisere det overordnede informasjonsbehovet i den beskrevne prosessmodellen. Beskrive krav til dokumentasjon på en entydig måte uavhengig av implementasjon Sikre at relevante kodeverk benyttes for informasjonsmodellene. Tabell 6 Metodesteg Sverige Fokuset for NI er overordnede og generelle informasjonsmodeller som en basis eller minimumssett for interoperabilitet. Utgangspunktet i NI er krav til dokumentasjon i EPJsystemer, men kan også benyttes som grunnlag for dokumenter og meldinger. Metoden skiller seg fra andre aktører ved at man fokuserer på hele datasett og ikke små gjenbrukbare komponenter. Rammeverk: Nasjonalt fagspråk (terminologi) Nasjonal informasjonsstruktur o o o Prosessmodeller Begrepsmodeller Informasjonsmodeller Metode (internasjonal standard for informasjonsarkitektur SS-ISO/IEC/IEEE 42010) Modelleringsverktøy (UML+dokumentasjon) Kilde:[8] 4.3 Oppsummering rammeverk Felles modeller og oversettelse mellom standarder Erfaringene viser at det er vanskelig å lage generelle informasjonsmodeller som skal dekke hele helsetjenesten fordi registrering og bruk er så forskjellig for de ulike aktørene. Det er også vanskelig å lage informasjonsmodeller som kan realiseres i ulike standarder fordi standardene har grader av semantikk som er så ulik, og som gjør at modellene må tilpasses de konkrete standardene som f.eks. brukes til utveksling. 23

24 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller De siste årene har det sannsynligvis vært for stor tro på at man skal kunne klare å standardisere klinisk informasjon i modeller som løser alle problemer knyttet til semantisk interoperabilitet («the pure semantic problem»). HL7 versjon 3 er et eksempel på at modellering av hele helsetjenesten blir for omfattende og komplekst for videre benyttelse. Dersom felles modeller skal fungere må man ta hensyn til de standardene man skal benytte når modellene spesifiseres. I tillegg må detaljnivået og bruk av metadata justeres slik at det også harmonerer med de standardene det er aktuelt å benytte Utvalg av standarder Flere av fagekspertene peker på HL7 FHIR som en viktig standard for grensesnitt og utveksling mellom systemer og SNOMED CT for terminologi og kodeverk. I møtet med openehr ble det også påpekt at openehr vil være viktig fremover når det gjelder å modellere klinisk informasjon. Dette ble begrunnet med at rundt disse tre rammeverkene er det stor aktivitet, bra prosesser og rammeverkene brukes i praksis. De ulike standardiseringsmiljøene ser at rammeverkene er forskjellige, men også komplementære og at alle parter vil tjene på å samarbeide Myndighetsstyrt, brukerstyrt eller leverandørstyrt standardisering Det er forskjeller mellom initiativene når det gjelder hvem som har styringen. I Australia har noe av utfordringen vært at det har vært for sterk styring fra myndigheter og brukere/klinikere, slik at man har endt opp med informasjonsmodeller som leverandører ikke klarer å realisere. I USA har det i stor grad vært leverandørstyrt standardisering i med liten påvirkning fra myndigheter og brukere, noe som kan ha gjort at man ikke har oppnådd det potensialet som faktisk er tilstede. I Nederland har man innført kontroller av informasjonsmodellene for å sjekke om de lar seg implementere av de ulike leverandørene, for å sikre at de kan og vil realiseres. Man bør derfor være bevisst hvorvidt informasjonsmodeller skal være deskriptiv (beskrive det som finnes) eller preskriptiv (beskrive det som burde være) og vurdere dette med bakgrunn i aktuelle leverandører og klinikeres prioriteringer av innhold Små modeller eller store modeller Det kan være hensiktsmessig å lage modeller for mindre, utvalgte områder hvor det er stort behov for at informasjonen er mest mulig likt beskrevet. Slik modellering bør skje basert på kliniske behov og reelle bruksscenario. Dette er imidlertid avhengig av hva hensikten med modelleringen skal være. Fremgangsmåten til Socialstyrelsen i Sverige er den eneste som forsøker å definere større områder overordnet nivå, som kan være et utgangspunkt for mindre og mer spesifikke modeller innen enkeltområder Arenaer for samarbeid Det er enighet om at engasjement og aktivitet blant utviklere og klinikere er en viktig forutsetning for å lykkes med standardisering og bruk av standarder. Etablering av arenaer for samarbeid blir derfor viktig. 24

25 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 5 Oppsummering og videre arbeid Arbeidet med å lage gode, felles informasjonsmodeller som er teknologisk uavhengige og forberedt for gjenbruk, ansees generelt å være vanskelig. For å komme til en situasjon hvor standardiseringsorganer, systemutviklere og leverandører har felles modeller å ta utgangspunkt i er det behov for å evaluere hvilke rammeverk som best kan brukes for å uttrykke slike modeller. Gjennom konseptfasen er det avdekket at dette er en utfordring som det arbeides med i mange land, men at det i flere tilfeller er gjort valg som ser ut til å gå i riktig retning. Samtidig er det gjort erfaringer fra andre land som er viktig å ta med seg i det videre arbeidet slik at man unngår å oppleve samme problemer. I første omgang foreslås det derfor å gjøre en vurdering av de mest aktuelle rammeverkene som er fremkommet i arbeidet så langt. Det må utarbeides vurderingskriterier som gjør det mulig å sammenligne rammeverkene som blir valgt ut for videre vurdering. Basert på vurderingskriteriene skal det gjøres vurderinger innenfor nasjonal kontekst og behov. Som del av dette arbeidet anbefales det å fortsette dialogmøter med de ekspertene som så langt er konsultert, og samtidig utvide utvalget til også å vurdere andre lands metoder, blant annet Sverige og Canada (Alberta). Hensikten med vurderingene vil være å gi anbefalinger for bruk av rammeverk for felles informasjonsmodeller. Dette vil være et steg på veien til å kunne definere felles informasjonsmodeller som vil sikre gjenbruk og forenkling i utvikling av nye løsninger for helsesektoren. Tabellen under viser en sammenstilling av kontakter og mulig oppfølging. Navn: Eventuell oppfølging: Tid: Ian McNicoll Richard Kavanagh Graham Grieve Ewout Kramer Oppfølging rundt erfaringer gjort med openehr, samt også samvirke med FHIR og de diskusjoner som holdes rundt dette. Her kan vi også bruke det norske arketypemiljøet og eventuelt andre openehr eksperter internasjonalt Oppfølging rundt governance i arbeidet med informasjonsmodellering. Eventuelt også involvere andre representanter (eksempelvis Amir Mehrkar som det også var planlagt å møte) Oppfølging rundt samvirke mellom FHIR og openehr. Se mer på Argonaut-prosjektet. Kontakte andre Avklares som del av prosjektplanleggingen Avklares som del av prosjektplanleggingen Avklares som del av prosjektplanleggingen 25

26 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller kjente prosjektdeltakere i Argonaut. Michael van der Zel Socialstyrelsen i Sverige NIKT Det er flere tema her som er interessante å diskutere videre med Michael, blant annet governance. Vi må ta en runde internt og identifisere videre arbeid her og om vi eventuelt skal prøve å sette av lengre tid (en dag) hvor enten vi får han hit eller vi reiser til Nederland. Det kan være interessant å få vite mere om prosessen rundt informasjonsmodelleringen og i hvilken grad informasjonsmodellene er tatt i bruk. I første omgang ta kontakt med Socialstyrelsen i Sverige. Hvis aktuelt, avtale en studietur til Socialstyrelsen i Sverige. Videre deltakelse i prosjektet. Avtale ny presentasjon for Fagforum arkitektur/klinisk IKT. Avklares som del av prosjektplanleggingen Avklares som del av prosjektplanleggingen Avklares som del av prosjektplanleggingen Fagforum for informasjonsarkitektur Tabell 7 Oppfølging dialogmøter Presentasjon av prosjektstatus Dialog/gjennomgang av prosjektet for informasjonsmodeller i HSØ Fagnettverket har møter annenhver måned. Nytt møte avtalt

27 Internasjonale standarder Vurdering av rammeverk for felles informasjonsmodeller 6 Kilder [1]. «Fra begrep til datamodell», Torbjørn Nystadnes, Avdeling standardisering, Direktoratet for e-helse: ame.aspx?sourcedoc=/styring/standardisering/internasjonalestandarder/delte%20doku menter/08%20bakgrunnsdokumenter/fra%20begrep%20til%20datamodell%20tony% pptx&action=default&DefaultItemOpen=1 [2]. Felles informasjonsmodeller-prinsipper og føringer, Difi [3]. Nasjonal e-helsestrategi og handlingsplan [4]. Vurdering av internasjonale standarder ernasjonale%20standarder.pdf [5]. Argonaut Project [6]. INTEROPen [7]. The basic principles of health and care information models (HCIMs) and how they can be used [8]. Socialstyrelsen [9]. Referat fra møte med Ian McNicoll [10]. Referat fra møte med Richard Kavanagh (NHS) [11]. Referat fra møte med Graham Grieve og Ewout Kramer [12]. Referat fra møte med Michael van der Zel Feltkode endret 27

28 Konseptvalgutredning Helseanalyseplattformen Problembeskrivelse Norske helsedata omtales som en gullgruve for forskning og medisinsk kvalitetsforbedring. Norge har helseregistre i verdensklasse, men et komplisert lovverk, ansvar fordelt mellom flere registerforvaltere og tungvint datatilgang gjør det vanskelig å få tilgang til helsedata gjennom en lang og kostbar søknadsprosess. Det å koble data fra flere ulike kilder er spesielt krevende. Dagens krav om forhåndsgodkjenning fra REK og Datatilsynet og praksisen med å måtte få dispensasjon fra taushetsplikten fra ulike instanser bidrar til unødvendig kompleksitet og uforutsigbarhet for de som søker tilgang til helsedataene. Når dataene først er utlevert, er det få muligheter for gjenbruk ettersom det settes begrensninger på hvor lenge data kan brukes før de må anonymiseres eller slettes. Statistikkloven begrenser i tillegg mulighetene for sammenstilling av helsedata med demografiske og sosioøkonomiske data, både til forskningsformål og andre analyseformål. Som en oppfølging av nasjonal helseregisterstrategi er Direktoratet for e-helse som nasjonal koordinator og pådriver på e-helseområdet gitt i oppdrag å etablere Helsedataprogrammet. For å tilrettelegge for enklere tilgang til og utnyttelse av helsedata utredes det i regi av programmet en nasjonal plattform for tilgjengeliggjøring og analyse av helsedata: Helseanalyseplattformen. Nedenfor presenteres utfordringsbildet for gruppene som berøres av dagens system for tilgang til helsedata. 1.1 Forskere Rapporten Enklere tilgang mer forskning 1, som ble utarbeidet av Agenda Kaupang på oppdrag fra Forskningsrådet i 2016, peker på at det er krevende for forskere å skaffe oversikt over hvilke variabler som finnes i registrene, dekningsgrad og datakvalitet på tvers av datakildene. Et gjennomgående inntrykk fra forskerens ståsted er at det distribuerte databehandleransvaret bidrar til forsinkelser og uforutsigbarhet fordi vurderinger av søknader og forvaltningsvedtak gjøres sekvensielt og per register. Siden de ulike databehandlingsansvarlige vurderer ulike aspekter ved søknaden vil fortolkningen av regelverket og skjønnsanvendelsen kunne være ulik, noe som bidrar til å komplisere en lang og kostbar søknadsprosess ytterligere. En konsekvens av dagens system er at det forskes mindre enn det forekomsten av gode registerdata og andre helsedata i utgangspunktet skulle tilsi. Samlet gir utfordringene i dagens situasjon begrensede analysemuligheter Hvordan beskrive lokal datalagring og de utfordringene det bringer med seg? 1.2 Registerforvaltere Agenda Kaupangs rapport viser også til at registerforvalternes erfaring er at det ofte er de juridiske og registerfaglige vurderingene av søknader som er krevende, og ikke nødvendigvis 1 1

29 Konseptvalgutredning av Helseanalyseplattformen tilrettelegging og overføring av data i seg selv. Registrene mottar i dag et stort antall mangelfulle søknader som enten er feil utfylt, mangler dokumentasjon på vedtak fra godkjenningsmyndighetene 2, ikke er i samsvar med forhåndsgodkjenningen fra aktuelle instanser eller mangler begrunnelse for at dataene det søkes tilgang til er relevante for formålet. Saksbehandlingstiden hos godkjenningsmyndighetene og databehandlingsansvarlige er varierende. Ifølge HelseOmsorg21 kan det koste flere millioner kroner å saksbehandle én enkelt søknad om registerkobling 3. Antall søknader om datatilgang varierer også fra register til register, men generelt er etterspørselen etter helsedata økende. Norsk pasientregister har for eksempel opplevd økt etterspørsel på ca. 15 prosent hvert år de siste tre årene, og leveringstiden per april 2017 er om lag seks måneder fra komplett søknad er mottatt betydelig lenger enn de forskriftsfestede fristene 4 for utlevering av data. Er det noen utfordringer registerforvaltere har til HAP som relaterer seg til Manuelle forvaltningsoppgaver Lite gjenbruk og datautveksling Lite standardisert Stort moderniseringsbehov (man leverer ut data på fil etc) Få fellestjenester 1.3 Næringsliv Også fra et næringsperspektiv er norske helsedata en underutnyttet ressurs. I dag er formål og hjemmel til lovbestemt innsamling av data uten reservasjonsrett knyttet til myndighetskontroll og forskning. Kommersialisering og næringsutvikling medfører imidlertid etiske utfordringer, som resulterer i krevende tilgang til helseregistre og biobanker for private aktører. I tillegg til formålsbestemmelsene og juridiske begrensinger bidrar fragmentert organisering av registerforvaltningen til å gjøre det utfordrende for norsk og internasjonalt næringsliv å skaffe seg oversikt over forskningsmulighetene i Norge. Samtidig bidrar et mangelfullt mottaksapparat hos registerforvalterne til at henvendelser fra næringslivet ikke følges opp på en profesjonell måte 5. Tidkrevende saksbehandling på søknader om personidentifiserbare data gjør at næringslivsaktører i større grad avstår fra samarbeidsprosjekter med offentlige helsedataforvaltere, noe som hindrer verdifull innovasjon og næringsutvikling. Helsedata kan være del av flere ledd i utviklingsforløpet til et legemiddel. Særlig finnes det et stort næringspotensial innen helseøkonomi og persontilpasset medisin, der helserelaterte persondata vil være en forutsetning for effektive real world evidence-studier. Helsedata vil også være viktig for programvareindustrien, blant annet i utviklingen og uttestingen av avansert analyse- og velferdsteknologi basert på maskinlæring og kunstig intelligens. 2 REK, Datatilsynet, Helsedirektoratet og personvernombud dager for statistiske opplysninger og personidentifiserbare opplysninger for bruk i uttrykkelig angitte forskningsprosjekter, og 60 dager for avidentifiserte eller sammenstilte opplysninger 5 Arbeidsgruppe under Biobank Norge (2017): Tilgang til norske helsedata hvordan ivareta næringslivets behov og bidra til innovasjon og næringsutvikling 2

30 Konseptvalgutredning av Helseanalyseplattformen 1.4 Myndigheter Sett fra et myndighetsperspektiv gir dagens helseregistre i liten grad tilgang til oppdaterte helsedata for styring, planlegging og kvalitetsforbedring i helsetjenestene. Dette handler dels om mange og fragmenterte kilder, rutiner og publiseringskanaler men også om frekvensen på rapportering og datautveksling mellom aktørene. Helsedatautvalget poengterer at tertialvis statistikk og kvalitetsindikatorer kan fungere i overvåkningen av aktivitet og kvalitet, men at dataene ofte er utdaterte når de rapporteres til helsetjenesten. Statistikkloven begrenser i tillegg muligheten for sammenstilling av demografiske og sosioøkonomiske data på individnivå med data fra helseregistrene til bruk i statistikk og helseanalyser. Samlet fører den manglende tilgangen til oppdatert helsedata til at verdifull kunnskap om pasientforløp og kvaliteten i helsetjenestene uteblir, på kommunalt, regionalt og sentralt nivå. 1.5 Helsepersonell I dag brukes det mye tid på innrapportering av helsedata, men til tross for dette ser helsepersonell få umiddelbare gevinster av innrapporteringen i behandlingen av pasienter. Det ligger et stort potensial i bruk av sanntids helsedata til forbedring av behandling og kvalitetsforbedring i helsetjenesten for øvrig. Helsedatautvalget påpeker også at dagens system ikke er tilrettelagt for bruk av real world data for å forstå sykdom, behandlingsmønstre, pasientatferd og produktytelse i klinisk praksis. 1.6 Innbyggere I dag utleveres helsedataene hovedsakelig på lagringsmedier som sendes per post, noe som resulterer i spredte personopplysninger som igjen utgjør en stor risiko for informasjonssikkerhet og personvern. Distribuerte datasett medfører risiko for at forsendelsen av data kommer bort i postgangen eller at datasettene benyttes til andre formål enn det som var forutsatt ved utleveringen. En fragmentert organisering av hele registerfeltet resulterer i at personopplysninger er spredt på tvers av mange registre og organisasjoner. Innbyggerne har i dag begrenset innsynsmulighet i egne helseopplysninger i registrene, noe som bryter med den lovfestede innsynsretten i personopplysningsloven. Distribuerte datasett vanskeliggjør kvalitetssikring, oppretting av feil og verdiøkning av datagrunnlaget Begrenset medvirkning Lite kunnskapsutnyttelse 3

31 Konseptvalgutredning Helseanalyseplattformen Behovsanalyse Behovene beskrevet i dette dokumentet er primært hentet fra følgende kilder: - Et nytt system for enklere og sikrere tilgang til helsedata - Rapport fra Helsedatautvalget ( ) - Enklere tilgang mer forskning (2016) - Referansearkitektur og fellestjenester for helseregistre (2016) - Helse og Omsorg 21 (2014) - Kartlegging av variabler i norske helseregistre (2017) - Tilgang til norske helsedata hvordan ivareta næringslivets behov og bidra til innovasjon og næringsutvikling (2017) - Menon Economics Verdiskapning i Helsenæringen (2016) I tillegg er deler av behovene knyttet til «Forskere» diskutert med Helsedataprogrammets arbeidsgruppe for forskning. 1.1 Interessentgruppebaserte behov Ulike interessentgrupper har ulike behov knyttet til sekundærbruk av helsedata (definert som personrelaterte helseopplysninger, slik dette er definert av Helsedatautvalget i deres rapport). Under følger en beskrivelse av de ulike interessentgruppenes unike behov som skal gjøre tilgang til helsedata enklere, og en beskrivelse av behov som er felles for mer enn én interessentgruppe Forskere Forskere er i denne sammenheng personer knyttet til forskningsinstitusjoner som arbeider med helseforskning. Forskere inkluderer, men er ikke begrenset til, prosjektledere og prosjektmedlemmer i forskningsprosjekter. Forskere har behov for: En felles søknadstjeneste på tvers av datakilder/dataforvaltere og aktuelle godkjenningsinstanser som gjør det enklere å søke om tilgang til helsedata for forskningsformål. En enklere og mer forutsigbar søknads- og godkjenningsprosess for å få tilgang til helsedata. En omforent veiledningshjelp rundt regelverk, prosesser og priser. Det er behov for økt opplæring og kurs for forskere som skal gjennomføre forskning basert på registerdata. Dette gjelder både kunnskap om data i registrene, men også om søknadsprosessen. I tillegg er det behov for kurs og opplæring innenfor dataanalyse, statistikk og bruk av analyseverktøy. Tilgang på syntetiske datasett for tidlig å kunne gjøre eksplorativ analyse. En selvbetjent/eksplorativ analysetjeneste for å gjøre analyser på sammenstilte data uten at utlevering av data er nødvendig. Dette vil kunne hjelpe forskere til å bli mer konkrete når de søker etter data, samt utelukke hypoteser på et tidlig tidspunkt. 1

32 Konseptvalgutredning av Helseanalyseplattformen En bedre oversikt over tilgjengelige kilder til helsedata som kan benyttes for forskningsformål. En nasjonal katalog over datavariabler, i norske helseregistre, helseundersøkelser, demografiske og sosioøkonomiske data med god søkefunksjonalitet. Tilgang til informasjon om historikk og kvalitet (oppdatering, dekning mv.) på variablene i registrene. En teknisk infrastruktur med analyseverktøy for å analysere data i et sikkert miljø. Mulighet for å ta med sine egne eller åpne datasett og kombinere disse med helsedata fra de tilgjengelige datakildene. Datatilgang på institusjonsnivå gjennom abonnementsordninger. Tjenester som forenkler internasjonalt samarbeid knyttet til større forskningsprosjekter, herunder muligheter for samarbeid og deling av analyser og forskningsresultater. Muligheter for mer dynamisk kontakt med deltakere i forskningsprosjekter, herunder digital innhenting og administrasjon av samtykker ved deltakelse i forskningsprosjekter. Forenklet regelverk å forholde seg til i bruk av helsedata for forskningsformål. Redusert samlet tidsbruk i prosessen rundt søknad om bruk av helsedata for forskning, og bedre informasjon underveis i prosessen. Mulighet for å oppdatere tidligere definerte datasett for å kunne gjøre sammenligninger over tid Myndigheter Med myndigheter menes personer og miljøer som har roller knyttet til styring, planlegging og kvalitetsforbedring av helse- og omsorgstjenester på nasjonalt, regionalt og lokalt nivå. Det vil også være slik at mulighetene for bedre utnyttelse av helsedata implisitt vil ha betydning for myndigheter som har ansvar for forskningsfeltet, næringsutvikling og innovasjon. Myndigheter har dermed behov for: Bedre beslutningsgrunnlag knyttet til styring, planlegging og kvalitetsforbedring av helse- og omsorgstjenester og til utvikling av finansieringsordninger i sektoren. Bedre data om etterspørsel, bruksmønstre, forskningsomfang, tematiske trender mv. og dermed beslutningsgrunnlag knyttet til styring, planlegging og politikkutvikling innen forskningspolitikken og innen nærings- og innovasjonspolitikken. Økt grad av selvbetjening av rapporter og analyser, og mulighet for eksplorativ analyse innenfor områder knyttet til blant annet avvikskontroll, helseøkonomi, bruksmønstre og sikkerhet og beredskap. I tillegg er det behov for nye prediksjonsløsninger knyttet til framskrivninger, beredskap og fordeling/lokalisering av tjenester. Økt grad av internasjonal benchmarking ved å hente data fra andre land. Raskere tilgang til data og rapporter for å få ny innsikt og mer effektiv rapportering nasjonalt og internasjonalt. Bedre verktøy for å måle kvalitet og sammenligne helsetjenestene, og bedre verktøystøtte for å avdekke svakheter i helsetjenestene Næringsliv Med næringsliv menes den private delen av helseverdikjeden som inkluderer privat forskning, tjenesteutvikling, produksjon, distribusjon og behandling. Næringsliv har de

33 Konseptvalgutredning av Helseanalyseplattformen samme behovene som interessentgruppen forskere har. I tillegg har næringsliv også uttrykt følgende behov: Enklere tilgang på offentlige helsedata for den private helseindustrien (gjelder spesielt legemiddelindustri, diagnostikk, helse-ikt og «MedTech»). En sterkere involvering av næringslivet knyttet til byggingen av nye IKT-plattformer rundt helsedata. Bedre rutiner og et mer profesjonelt mottaksapparat i ikke-lovbestemte helseregistre (kvalitetsregistre og biobanker) for utlevering av data og biologisk materiale. Økt fokus på innovasjon, industrisamarbeid og næringsutvikling ved bruk av helsedata Registerforvaltere Registerforvaltere i denne sammenheng er personer knyttet til en organisasjon som forvalter et eller flere helseregister (med helseregistre i denne sammenheng menes lovbestemte helseregistre, samtykkebaserte helseregistre, medisinske kvalitetsregistre og biobanker) og arbeider med innsamling, kvalitetssikring eller utlevering av data. Registerforvaltere har behov for: Hyppigere innrapportering for ferskere datagrunnlag og for å kunne drive kvalitetsarbeid av innrapporterende enhet. Harmonisert infrastruktur for meldingsutveksling/rapportering og informasjonsstruktur på tvers av alle nasjonale registre Internasjonale standarder og kodeverk som grunnlag for rammeverk i PAS/EPJ og innrapportering; nasjonale kodeverk kun der det ikke finnes internasjonale Standard klassifikasjon av organiseringen fra regionale helseforetak ned til seksjoner og poster, inkludert rapportering av adresse og geolokasjon CRM basert saksbehandling ved utleveringssøknader på tvers av registrene En felles samhandlingsplattform for nasjonale helseregistre i Norsk helsenett for meldinger knyttet til nasjonale helseregistre. Økonomiske incentiver for å øke dekningsgrad i nasjonale medisinske kvalitetsregistre. Videreutvikling av nøkkelregistre for å sikre en god infrastruktur for kunnskap. Modernisere de sentrale helseregistrene for å oppnå en mer effektiv drift, og for å kunne utnytte mulighetene i de nye tekniske løsninger. Å etablere «klynger» av registre innenfor større fagområder Innbyggere Behov knyttet til innbyggere er tett koblet opp mot å gi innbyggere bedre innsikt i egne helseopplysninger og å styrke personvernet. En positiv bieffekt av forbedret innsikt i egne helseopplysninger er forbedret datakvalitet ved at innbyggere selv kan supplere eller korrigere helsedata registrert om dem. Innbyggere har behov for: Redusert spredning av helseopplysninger. Forbedret personvern og sikring av helseopplysninger til individet. Fortsatt tillit til helse- og omsorgstjenestenes behandling av helseopplysninger. Muligheter for mer direkte dialog med forskerteamet i forskningsprosjekter de deltar i med sine opplysninger, herunder muligheter for å gi eller trekke samtykke.

34 Konseptvalgutredning av Helseanalyseplattformen Forbedret innsyn i egne helseopplysninger og bedre mulighet til å avdekke og rette feil, eventuelt komme med relevante tilleggsopplysninger. Burde vi hatt med Stortinget og portvoktere (REK/NEM, Datatilsynet) som proxy for Innbyggere, eventuelt som en egen interessent? De ønsker (som innbyggere) bedre personvern, ivaretakelse av den enkeltes rettigheter og interesser, og er de (Stortinget) de som setter lovene. Disse vil jo i hvert fall følge prosjektet med argusøyne, og er slik sett en aktør vi ikke kan ignorere Helsepersonell Med helsepersonell menes personer som arbeider med pasientbehandling og innrapportering av data til sekundærbruk i både primær- og spesialisthelsetjenesten. Helsepersonell har behov for: Å redusere sin egen dobbeltregistrering av helseopplysninger. Enklere og mer brukervennlige løsninger for innrapportering til nasjonale helseregistre og kvalitetsregistre. Rask tilbakerapportering på egne data for å se fordelene ved å rapportere inn fullstendige og korrekte data. Forbedret beslutnings- og prosesstøtte basert på data- og analysegrunnlag fra helseregistre, Tjenester for sammenligning av egen praksis mot andre, og bedre innsikt i informasjon på tvers av helsetjenestene Helseledere Med helseledere menes ledere på ulike nivåer i helsetjenesten og de lokale og regionale helseforetakene. Helseledere har overlappende behov med både myndigheter og helsepersonell, men har også behov for: Forbedret helseanalyser for planlegging, kvalitetsforbedring, prioritering og styring. Tjenester for sammenligning av egen virksomhet, avdeling eller praksis mot andre, og bedre innsikt i informasjon på tvers av helsetjenestene. Økt grad av selvbetjening av rapporter og analyser, og mulighet for eksplorativ analyse innenfor områder knyttet til blant annet styring, kvalitetsforbedring og økonomi. I tillegg er det behov for nye prediksjonsløsninger knyttet til framskrivninger. Raskere tilgang til data og rapporter for å få ny innsikt og mer effektiv rapportering lokalt og nasjonalt. Bedre beslutningsgrunnlag knyttet til styring, planlegging og kvalitetsforbedring av helse- og omsorgstjenester Felles behov I tillegg til de unike interessentbehovene knyttet til sekundærbruk av helsedata finnes det noen behov som går på tvers av interessentgruppene. Flere interessentgrupper har behov for: Å se geografiske, demografiske og sosioøkonomiske opplysninger sammen med helsedata.

35 Konseptvalgutredning av Helseanalyseplattformen Å redusere den samlede tidsbruken fra søknad til tilgjengeliggjøring av helsedata. Rammetillatelser på organisasjonsnivå for datatilgang gjennom sertifiseringsordninger. Dette gjelder både forskningsmiljøer, forvaltningsmiljøer, konsulentmiljøer, myndigheter eller andre på virksomhetsnivå. Bedre markedsføring og informasjon om de helsedata som finnes og de muligheter som foreligger for nyttig bruk og utnyttelse av de verdifulle informasjonsressursene. 1.2 Etterspørselsdrevne behov I tillegg til de konkrete behovene fra interessentgruppene er det flere etterspørselsdrevne behov. For å identifisere disse har vi identifisert noen sentrale drivere knyttet til 1. Politiske og juridiske forhold (både nasjonale og internasjonale forhold) 2. Økonomiske forhold 3. Sosiokulturelle og samfunnsmessige forhold 4. Teknologiske forhold Politiske og juridiske forhold Det er mange politiske og juridiske drivere knyttet til helsedata og bruk av helsedata for sekundærformål: Bred tverrpolitisk enighet om økt satsning på helse- og velferdsteknologi som næringsområde i Norge. Økt internasjonalt samarbeid knyttet til helseforskning hvor prosjektene er større og mer komplekse og går på tvers av landegrenser. Nytt EU-direktiv knyttet til personvern (GDPR) som etter planen innføres i Norge 25. mai Regjeringen nedsatte 9. september 2016 et lovutvalg som skal gjennomgå den norske statistikkloven. Resultatet av dette arbeidet kan medføre større endringer i hvordan helsedata kan brukes sammen med demografiske og sosioøkonomiske data. Økt risiko for dataangrep fra fremmede makter. Helselovverket blir stadig mer komplekst, blant annet på grunn av organisatorisk kompleksitet, nye behandlingsformer, ny teknologi og nye pasientrettigheter. Framveksten av en mer persontilpasset medisinsk behandling, og som vil kunne utfordre skillet mellom primær- og sekundærbruk av helseopplysninger som fordrer mer analyse av data. Dette utløser følgende etterspørselsdrevne behov Forenkle tilgang til helsedata for å tilrettelegge for næringsutvikling innen helse- og velferdsteknologi i Norge. Forenklet deling av helsedata på tvers av landegrenser for å tilrettelegge for aktiv norsk deltakelse i internasjonale forskningsprosjekter på helseområdet. Det er viktig med et fortsatt sterkt fokus på å sikre personsensitive data og redusere fysisk utlevering av helsedata for sekundærbruk. I stedet bør man etterstrebe og tilgjengeliggjøre data i sikre miljøer. Det er nødvendig med en forenkling av lovverk for å redusere den ulike tolkningen av regelverket som gjøres i dag knyttet til bruk av helsedata for sekundærbruk. Tettere samarbeid mellom offentlig sektor og private næringsinteresser for å utvikle helse- og velferdsteknologi som næringsområde i Norge. En mer aktiv markedsføring av mulighetene som ligger i norske helsedata.

36 Konseptvalgutredning av Helseanalyseplattformen Bruk av persontilpasset behandling vil på mange måter viske ut det skillet som i dag eksisterer mellom primærbruk og sekundærbruk av helsedata. Analyse og trening av modeller på store datamengder vil i dag sees på som sekundærbruk, mens bruk av modellen for diagnose i behandling er primærbruk. Det er derfor et behov for en gjennomgang av lovverket som eksisterer i dag knyttet til bruk av data Økonomiske forhold Når det gjelder økonomiske forhold er mye av dette knyttet til kostnadsbildet i helsetjenesten. Dette treffer hele verdikjeden innenfor helsenæringen, fra forskning til behandling til støttefunksjoner. Det er behov for å redusere kostnader knyttet til hele verdikjeden. Tidskostnadene knyttet til innregistrering av data av helsepersonell er betydelige. Dette medfører at mindre tid brukes i behandlingskontekst. Kostnader knyttet til søknad om bruk av data, saksbehandling og uthenting av data er høye og fører til suboptimal ressursbruk både i forskningsmiljøer, forvaltningsmiljøer og hos godkjenningsinstansene. Utvikling av nye finansieringsordninger som er basert på for eksempel kvalitet eller avtaler Dette utløser følgende etterspørselsdrevne behov: Økt digitalisering og automatisering av helsesektoren for å redusere administrativt dobbeltarbeid knyttet til f.eks. dobbeltregistrering og dobbeltrapportering av helseopplysninger. Forenkle prosessen knyttet til søknad, saksbehandling, utlevering og tilgjengeliggjøring av data. Behov for å se helsedata i sammenheng med forløpstider, kostnadsdata, kvalitetsindikatorer, uønskede hendelser og NPE saker gjennom hele behandlingsforløpet Sosiokulturelle og samfunnsmessige forhold Når det gjelder sosiokulturelle og samfunnsmessige forhold så er det flere drivere knyttet til bruk av helsedata: Eldrebølgen og økt behov for smartere helseløsninger utfordrer helsetjenesten. En viktig forutsetning er at forvaltningen blir mer analytisk og kunnskapsdrevet. Et viktig virkemiddel i arbeidet med å utvikle smartere helseløsninger og ny helseteknologi er muligheten for gode analyser på data. Demokratisering og økte krav om transparens. Innbyggerne vil i økende grad ønske å ha kontroll over egne data og påvirke hvordan opplysninger om dem benyttes. De siste fem årene har det blitt en økende bevissthet i befolkningen om de digitale fotspor vi legger igjen ved bruk av IKT-tjenester. Det vil være en større forventning om at myndigheter som håndterer helsedata vil være i stand til å peke på hvor og til hva helseopplysninger er brukt. Dette utløser følgende etterspørselsdrevne behov: Økende behov for data til analyse for utvikling av smarte helseløsninger. Tilby bedre informasjon til innbyggere rundt hvordan personlige helseopplysninger brukes og av hvem.

37 Konseptvalgutredning av Helseanalyseplattformen Økt behov for samfunnsøkonomiske analyser relatert til for eksempel innføring av nye og dyrere medikamenter Teknologiske forhold På teknologiområdet skjer det store endringer, og utviklingen går svært raskt. De viktigste teknologiske driverne vil være: Stordata, kunstig intelligens, kognitiv teknologi og maskinlæring blir tatt i bruk som teknologier på mange samfunnsområder. Da dette er teknologier som aktivt bruker data for læring, vil bedre tilgjengeliggjøring av helsedata stå helt sentralt for å kunne utnytte slik type teknologi i helsetjenesten. Person-nær teknologi, sensorer og tingenes internett. Gjennom bruk av person-nær teknologi (for eksempel puls- og glukosemålere, smarte klokker og telefoner) generer innbyggere etterhvert store mengder helsedata som i dag i svært liten grad brukes av helsepersonell og i enda mindre grad kombineres med andre personlige helseopplysninger. Nyere teknologi leveres i større grad som såkalte skytjenester fra store datasentre som ikke nødvendigvis befinner seg i Norge. Hvis man ønsker å ta disse i bruk må data dermed krysse nasjonale grenser. Nye og mer avanserte PAS/EPJ/kurvesystemer med mulighet for å integrere beslutningsstøtte basert på empiri Teknologiutviklingen preges etter hvert av større innslag av helhetlige plattformer, som kjerne for innovasjon og som utgangspunkt for to- eller flersidige markeder (med både tjenestetilbydere, applikasjonsutviklere og sluttbrukere som kunder). Det vil bli et økende behov for og etterspørsel etter slike plattformer med offentlige data som sentral komponent. Genteknologi Dette utløser følgende etterspørselsdrevne behov: Det er behov for å kunne analysere og lagre en stadig økende mengde data. En helseanalyseplattform må derfor ta hensyn til at datamengdene vokser ekstremt raskt og at også teknologiene knyttet til analyse av dataene utvikles raskt. Det er derfor behov for en arkitektur som kan håndtere en kanskje eksponentiell vekst av datamengdene som skal prosesseres, og med løpende introduksjon av nye analyseteknologier. Tilsvarende er det viktig å etablere en løsning som støtter opp rundt enkel introduksjon av nye datakilder etter hvert som disse kommer til. Bruk av stordatateknologi og sammenstilling av helsedata, data fra Internett og personnær teknologi vil kunne flytte grensene for hvilke datasett som kan regnes som anonyme og hvilke som er identifiserbare En plan for forvaltning og tilgjengeliggjøring av nye sanntids datastrømmer som tingens internett og sensorer vil gi tilgang til, og sammenkobling av disse med mer statiske helsedatakilder. En tydelig strategi på hvilke data man kan tillate å sende over landegrenser for å kunne utnytte nye tjenester, eventuelt under hvilke forutsetninger (kryptering mv.). Det er behov for oppdaterte og tydelige retningslinjer for å avgjøre hvilke datasett som kan regnes som anonyme og hvilke som er identifiserbare.

38 Vedlegg 7A Notat Til NUFA Kopi - Dato Saksnr NUFA-sak 26/17 Fra Saksbehandler Ansvarlig Inga Nordberg Espen Møller og Mona Holsve Ofigsbø Vidar Mikkelsen

39 Innhold 1 Nasjonal arkitekturstyring Bakgrunn Nasjonal arkitekturstyring på ulike nivåer Politisk nivå Nasjonal e-helsestrategi og nasjonal portefølje Fastsettelse av felleskrav Etterlevelse Videre arbeid

40 1 Nasjonal arkitekturstyring 1.1 Bakgrunn Rapport for styrket gjennomføringsevne for IKT-utvikling i helse- og omsorgssektoren (2015) peker på særlig to utfordringer med hensyn på styrket gjennomføringsevne: Lav gjennomføringsevne Lav utnyttelse av stordriftsfordeler Det anbefales virkemidler og tiltak som skal bidra til følgende resultater: Sektoren har relevante, forpliktende og realistiske IKT-strategier og mål Bedre måloppnåelse og raskere gevinstrealisering gjennom o Raskere utvikling og innføring av ny funksjonalitet og nye løsninger o Raskere realisering av endringer og tilpasninger i eksisterende løsninger Bedre utnyttelse av ressurser og ny teknologi Nasjonal e-helsestrategi og mål konkretiserer videre arkitekturstyring som et av flere virkemiddel for å oppnå nasjonal styring av e-helse og økt gjennomføringsevne. Nasjonal e-helsestrategi og handlingsplan beskriver seks strategiske områder med mål og innsatsområder for e-helseutviklingen i perioden Det overordnede målet for e-helseutviklingen er en utviklingsretning mot en felles journalløsning. I stortingsmeldingene Én innbygger én journal og Digital agenda varsler regjeringen grep som over tid vil resultere i modernisert IKT-plattform. Et av hovedmålene er å styrke nasjonal styring og koordinering av IKT-utviklingen i helse- og omsorgssektoren. Styrkingen vil være nødvendig for å kunne gjennomføre store digitaliseringsløft i sektor. Direktoratet for e-helse har mottatt et tillegg til tildelingsbrev nr. 1 for 2017 som omhandler IKT-organisering i helse- og omsorgssektoren. I oppdraget blir direktoratet bedt om å vurdere en styrkning av myndighetsrollen og utrede mulige virkemidler knyttet til dette. Anbefalinger fra dette oppdraget er relevant for utførelse av nasjonal arkitekturstyring og disse arbeidene skal sees i sammenheng. Utførelse av nasjonal arkitekturstyring vil måtte gjøres i rammen av den til enhver tid eksisterende styringsmodell for e-helse, myndighetsroller, e-helsepolitikk og nasjonal e- helsestrategi og handlingsplan. Det betyr også at evnen til å ta beslutninger og sikre etterlevelse av disse ikke kan være sterkere enn tilgjengelige styringsvirkemidler, tildelt myndighet eller inngåtte forpliktelser mellom aktørene. 3

41 2 Nasjonal arkitekturstyring på ulike nivåer I dette kapittelet beskrives ulike nivåer av nasjonal arkitekturstyring med eksempler og tilgjengelige virkemidler. I de tre øverste nivåene handler arkitekturstyring om å sette premisser, mens det på nederste nivået handler om etterlevelse av disse. Beskrivelsene er foreløpige og vi ønsker innspill fra NUFA på innholdet. 2.1 Politisk nivå På det øverste nivået kan arkitekturstyring knyttes til valg av overordnede rammer som skal gjelde for den samlede e-helseutviklingen i sektoren. Her vil fagvurderinger være ett av flere elementer som inngår i en helhetlig vurdering som grunnlag for utforming av e- helsepolitikken. Dette nivået vil vi omtale som arkitekturstyring på politisk nivå. Arkitekturstyring på politisk nivå kan blant annet bestå av politisk tilrådning av en anbefalt utviklingsretning for å realisere politiske mål, samt tilhørende økonomiske satsninger og reguleringer knyttet til dette. Operasjonaliseringen skjer gjennom styringsvirkemidler på stortings- eller regjeringsnivå. Direktoratet for e-helse har fått i oppdrag fra Helse- og omsorgsdepartementet (HOD) å utarbeide et veikart for å realisere én innbygger én journal. Oppdraget innebærer også å vurdere konsekvenser for allerede eksisterende løsninger. Myndighetspålagte utvikling av løsninger, som ikke nødvendigvis er beskrevet i den overordnede e-helsepolitikken, kan av politiske årsaker tilkomme med høy prioritet. Et eksempel på en myndighetspålagt utvikling av løsning er elektronisk helsekort for gravide. Direktoratet for e-helse fikk i 2017 oppdrag fra HOD om å starte arbeidet med etablering av elektronisk helsekort for gravide. I direktoratets fagråd til HOD vil konsekvenser av aktuelle IKT-arkitekturer være en sentral del av vurderingen. På det politiske nivået har Direktoratet for e-helse en rolle som faglig rådgiver til HOD innen e-helseområdet. 2.2 Nasjonal e-helsestrategi og nasjonal portefølje Med utgangspunkt i de valgte rammene i e-helsepolitikken kan arkitekturstyring utøves på et nivå som ligger mellom det politiske nivået og den enkelte helsevirksomhet i sektoren. På dette nivået vil arkitekturstyring skje i styringsprosesser knyttet til den nasjonale e- helsestrategien og den nasjonale porteføljen. Fagvurderinger knyttet til IKT- løsninger vil være en viktig del av beslutningsunderlagene ved start/stopp av tiltak, dvs. ved definerte beslutningspunkter. IKT-arkitekturen bør vurderes både ved beslutning om å utrede et behov, ved konseptvalg og ikke minst ved 4

42 investeringsbeslutningen. En viktig metode kan være å vurdere det foreslåtte tiltaket eller konseptet i lys av utviklingsretningen for å realisere e-helsepolitikken. Det finnes ingen utpekt myndighet for å styre aktørene på dette nivået. Investeringsbeslutninger baseres derfor på samarbeid mellom hovedaktørene i sektor. For flere av aktivitetene i den nasjonale porteføljen ligger imidlertid investeringsbeslutningen i den enkelte helsevirksomhet, altså på et lavere nivå. 2.3 Fastsettelse av felleskrav På noen områder er det behov for å fastsette generelle krav til sektorens IKT- løsninger for å sikre at ulike systemer kan virke sammen på ønsket måte. Eksempler på områder hvor det er behov for felleskrav innen sikkerhet og interoperabilitet. Det kan også stilles krav til hvordan nasjonale og sektorielle felleskomponenter skal brukes. Utover krav vil det være behov for utvikling av veiledere og prinsipper som kan hjelpe helsevirksomhetene i å utvikle IKT- løsninger som bidrar til ønsket utvikling i sektor. 2.4 Etterlevelse På laveste nivå handler nasjonal arkitekturstyring om etterlevelse av nasjonalt besluttede IKT-arkitekturer og de fastsatte felleskravene. Når det gjelder de fastsatte felleskravene vil disse kunne gjelde for IKT- løsninger innenfor alle virksomheter i sektor. For prosjekter i den nasjonale porteføljen vil etterlevelse kunne kvalitetssikres som ledd i den nasjonale porteføljestyringen. 5

43 3 Videre arbeid Prosjektet har så langt valgt å fokusere på de overordnede rammer og nivåene for arkitekturstyring. Det er ønskelig å diskutere dette med NUFA og se om det kan være en hensiktsmessig innretning. Videre arbeid i prosjektet vil fokusere på hvordan arkitekturstyring skal utføres innen disse fire nivåene. Dette vil bli gjort ved å bryte ned nivåene i ulike prosesser. Dette for å kunne se hvordan arkitekturstyring kan inngå i ulike situasjoner når helse- og omsorgssektoren skal digitaliseres. Prosjektet vil definere ulike prosesser, beskrive disse, og se nærmere på hvordan arkitekturstyring skal inngå i prosessene og hvilke virkemidler som kan benyttes. 6

44 Vedlegg 7B Notat Til NUFA Kopi - Dato Saksnr NUFA-sak 26/17 Fra Saksbehandler Ansvarlig Inga Nordberg Lars Moen, Bjarte Aksnes, Henrik Næss, Espen Møller, Erik Hedlund, Konstantin Tsilkos Vidar Mikkelsen

45 Innhold 1 Behov for målbilde og veikart Bakgrunn Leveranser fra vurderingen av målbilde og veikart Veikart og sentrale forutsetninger for realisering av dette Rammeverk brukt for beskrivelse av målbilde og veikart Overordnet beskrivelse av veikart for realisering av målbilde for Én innbygger én journal Beskrivelse av sentrale forutsetninger for gjeldende veikart Vurdering av gjeldende veikart Realiseringsmodell for realisering av utviklingsretningen Hva er en realiseringsmodell? Behov for helsepersonelltjenester som må kunne løses i perioden M0 - M Alternative realiseringsmodeller Prinsipper for valg av realiseringsmodell Videre arbeid

46 1 Behov for målbilde og veikart 1.1 Bakgrunn Regjeringen har foreløpig besluttet tre punkter med hensyn til realiseringen av mål 1 i Meld. St. 9 ( ) Én innbygger én journal: Utredningen av Én innbygger - én journal danner grunnlag for utviklingsretningen. En felles, nasjonal løsning for klinisk dokumentasjon, prosesstøtte og pasient- /brukeradministrasjon for helse- og omsorgstjenesten bør være målbilde og utviklingsretning for realisering av målene i «Én innbygger én journal». Realiseringen av «Én innbygger en journal» vil være omfattende og har et langt tidsperspektiv. Derfor ble det anbefalt en utviklingsretning mot en felles, nasjonal løsning for klinisk dokumentasjon, prosesstøtte og pasient-/brukeradministrasjon. Regjeringen har gitt sin tilslutning til anbefalingen om en utviklingsretning fremfor et konseptvalg i tradisjonell forstand. Helse- og omsorgssektoren vil de kommende årene gjennomgå mange endringer innen helsefaglig utvikling, organisering og ikke minst digitalisering. Derfor vil det være hensiktmessing at utviklingen skjer stegvis gjennom selvstendige prosjekter som styres overordnet nasjonalt. Programmet «Helseplattformen» i Helse Midt-Norge RHF skal gjennomføres som et regionalt utprøvingsprogram for det anbefalte nasjonale målbildet i «Én innbygger én journal» og et mulig startpunkt for en felles nasjonal løsning for kommunal helse- og omsorgstjeneste. Videre er det hypotesen at etableringen av nasjonal løsning for kommunal helse- og omsorgstjeneste kan være et første steg mot å realisere målbilde: Direktoratet for e-helse skal utarbeide et beslutningsunderlag for innføring av en nasjonal løsning for kommunal helse- og omsorgstjeneste. Beslutningsunderlaget skal omfatte gjennomføringsstrategi og fremdriftsplan, anbefalinger knyttet til styring, roller og ansvar, kontrakts-/anskaffelsesstrategi, kostnadsoverslag og finansieringsplan, samt plan for gevinstrealisering. Helse- og omsorgsdepartementet har behov for å etablere et tydeligere veikart for realisering av målbilde om Én innbygger én journal, som grunnlag for styring av enkelttiltak nasjonalt og i hver enkelt virksomhet. Gjennom tildelingsbrev for 2017 har derfor Direktoratet for e-helse fått i oppdrag om å: utarbeide et veikart for den samlede gjennomføringen av arbeidet med Én innbygger én journal. Veikartet må også inkludere de områder som krever nasjonale beslutninger i forbindelse med Helseplattformen. Arbeidet må gjennomføres i dialog med Helse- og omsorgsdepartementet og i samarbeid med de regionale helseforetakene og ha kommunal deltakelse. 3

47 1.2 Leveranser fra vurderingen av målbilde og veikart Vurderingen av målbilde og veikart vil utarbeide to beslutningsunderlag: 1. Beslutningsunderlag for veikart for realiseringen av målbilde for Én innbygger én journal. 2. Beslutningsunderlag for valg av realiseringsmodell for arkitekturområder Beslutningsunderlag for veikart for realiseringen av målbilde for Én innbygger én journal Beslutningsunderlaget vil danne grunnlaget for beslutning i regjerningen i 1. halvår 2018 vedrørende hvordan utviklingsretningen skal realiseres på et overordnet nivå. De sentrale spørsmålene som vil adresseres er: a. På hvilken måte vil etableringen av en nasjonal løsning for kommunal helse- og omsorgstjeneste for kommuner og fastleger utenfor Midt-Norge understøtte utviklingsretningen mot målbilde om en felles, nasjonal løsning for klinisk dokumentasjon, prosesstøtte og pasient-/brukeradministrasjon, herunder: Hvilke sentrale forutsetninger for e-helseutviklingen hos aktørene i helse- og omsorgssektoren er lagt til grunn for veikartet? Hvilken usikkerhet er knyttet til at forutsetningene holder, og hvordan bør usikkerheten håndteres? Hva er realistisk tidshorisont for realiseringen av målbilde gitt endringer i forutsetningene og hvordan påvirkes kostnadsutviklingen og realisering av effekter? Hvilke investeringer i M2 (nasjonal løsning for kommunal helse- og omsorgstjeneste) kan gjenbrukes for å realisere det endelige målbildet M3 (teknologi, systemer, løsninger, standardisering, organisasjonsutvikling, prosessmessig)? b. Hvilke alternative veikart eksisterer for å realisere målbilde om en felles, nasjonal løsning for klinisk dokumentasjon, prosesstøtte og pasient-/brukeradministrasjon gitt at sentrale forutsetninger i (a) ikke oppfylles, herunder: Hvilke sentrale forutsetninger for e-helseutviklingen hos aktørene i helse- og omsorgssektoren er lagt til grunn for de alternative veikartene? Hvilke konsekvenser for utviklingen av nasjonale e-helsekomponenter vil alternative veikart ha? Hvordan må styringen av e-helseutviklingen legges til rette for å realisere alternative veikart? 4

48 1.2.2 Beslutningsunderlag for valg av realiseringsmodell for arkitekturområder Beslutningsunderlaget vil danne grunnlaget for arkitekturstyring på nasjonalt portefølje nivå. Det sentrale spørsmålet som vil adresseres er: a. Hvordan vil utviklingen av nasjonale e-helsekomponenter påvirkes av Helseplattformen og en eventuell etablering av en nasjonal løsning for kommunale helse- og omsorgstjenester: Hvordan vil målbildet for de sentrale arkitekturområdene se ut underveis i realiseringen av Én innbygger én journal? Hva betyr valg av realiseringsmodell for eksisterende nasjonale løsninger, og behov for å videreutvikle den nasjonale grunnmuren, samt behov for midlertidige løsninger for å løse funksjonelle behov i transisjonen? 5

49 2 Veikart og sentrale forutsetninger for realisering av dette 2.1 Rammeverk brukt for beskrivelse av målbilde og veikart Følgende figur gir en oversikt over hovedleveransene som følger av arbeidet med målbilde og veikart. 1. Figur 1. Oversikt over hovedleveranser knyttet til målbilde og veikart Kjerneløsninger og sentrale milepæler Utredningen for Én innbygger én journal definerte følgende krav som prioriterte: 1. Tiltaket skal gi innbyggere og helsepersonell med tjenstlig behov en samlet tilgang til oppdaterte og nødvendige helseopplysninger, uavhengig av hvor innbyggeren har fått helsehjelp tidligere. 2. Tiltaket skal legge til rette for at planer for den enkelte pasient kan opprettes, deles og følges opp på tvers av helse- og omsorgstjenesten. Det skal tydelig fremgå hvilken aktør som til enhver tid har ansvaret for gjennomføring av aktuelle oppgaver. 3. Tiltaket skal sikre at tjenester er enhetlig definert på tvers av virksomheter og at helsepersonell og innbyggere får en samlet oversikt over kvalitet og ledig kapasitet for gjennomføring av aktuelle tjenester. 4. Tiltaket skal legge til rette for at helsepersonell får tilgang til kunnskaps- og beslutningsstøtte i tråd med gitte prioriteringer og definert beste praksis. 5. Tiltaket skal legge til rette for tilgjengeliggjøring av data til kvalitetsforbedring, ledelse og analyse, helseanalyse, forskning og beredskap. 6. Tiltaket skal ta høyde for strukturelle endringer. Som et minimum må tiltaket ta høyde for ivaretakelse av brukervalg, samt endringer i virksomhetsstrukturer og oppgavefordeling. For å realisere kravene ble det besluttet å avgrense tiltaket til det som ble definert som kjerneløsninger for helsepersonell. Kjerneløsning omfatter systemer som understøtter følgende funksjonalitetsområder: 6

50 Funksjonalitetsområde Klinisk dokumentasjon og prosess Pasient- og brukeradministrasjon Beskrivelse Området representerer i denne sammenhengen basisverktøyet for helsepersonell flest og inneholder systemer for å kunne dokumentere utførelsen av helsehjelp, vise og dokumentere helseopplysninger som funksjon av tid (Kurve), definere og følge opp behandlingsplaner, definere og administrere konkrete arbeidsoppgaver for helsepersonell, all håndtering og dokumentasjon av legemidler, samt det å kunne nyttiggjøre seg av kunnskaps- og beslutningsstøtte i arbeidet. Systemområdet omfatter standardiserte grensesnitt for integrasjon av medisinsk-teknisk utstyr og utvalgt velferdsteknologi. Pasientadministrasjonssystemer (PAS) har tradisjonelt vært egne systemer for administrasjon av pasientens avtaler, men er i mer moderne systemer en integrert del av kjerneløsningen og direkte knyttet til pasientens journal. Her finnes det blant annet informasjon om pasientens avtaler, henvisninger og søknader. I forbindelse med søknader om kommunale helse- og omsorgstjenester, benyttes saksbehandlingsfunksjonalitet. PAS-funksjonalitet benyttes hovedsakelig av helsepersonell, men innbygger skal ha innsyn og kan tilbys ulike administrative innbyggertjenester. Utredningen konkluderte med at en felles, nasjonal løsning for klinisk dokumentasjon, prosesstøtte og pasient-/brukeradministrasjon for helse- og omsorgstjenesten bør være målbilde og utviklingsretning for realisering av målene i «Én innbygger én journal». Hvordan utviklingsretningen fra dagens situasjon, der hver virksomhet bruker en egen kjerneløsning, til dette målbilde vil være det sentrale og førende for beskrivelsen av veikart. Veikartet vil på overordnet konseptuelt nivå inneholde en beskrivelse av sentrale milepæler. De sentrale milepælene beskriver tilstanden for Kjerneløsninger nasjonalt på et gitt tidspunkt. Utviklingen av øvrige arkitekturområder vil vurderes som følge av den overordnete utviklingen av kjerneløsninger Forutsetninger og tidsscenarier Knyttet til hver sentral milepæl er det knyttet en rekke forutsetninger. Noen av disse låg til grunn i forbindelse med regjeringsbeslutningen, mens andre er blitt identifisert i forbindelse med arbeidet med målbilde og veikart. Det gjennomføres en usikkerhetsvurdering av forutsetningene for veikartet. Basert på usikkerhetsvurderingen gjennomføres videre en vurdering av hvilke alternative tiltak som eksisterer for å håndtere usikkerheten. Tidsscenariene beskriver ulike realiseringstidspunkter for de sentrale milepælene, gitt forutsetningene og usikkerheten knyttet til disse. For hvert tidsscenario beskrives det også en kost/nytteprofil. Kost/nytteprofilene baserer seg på den samfunnsøkonomiske analysen fra utredningen samt oppdaterte kostnadstall der disse foreligger. 7

51 2.1.3 Arkitekturområder og realiseringsmodeller Mellom de sentrale milepælene vil ulike utviklingsfaser lede fra en milepæl til neste. Realiseringsmodellen beskriver: a. Hvordan transisjonen fra en milepæl til neste vil understøttes av utvikling av nasjonale løsninger innen viktige arkitekturområder, som samhandling og integrasjon, sikkerhet og grunndata. b. Hvordan utviklingen av innbyggertjenester, helseanalyse og velferdsintegrasjon skal harmoniseres med utviklingen innen kjernesystemene. 2.2 Overordnet beskrivelse av veikart for realisering av målbilde for Én innbygger én journal De sentrale milepælene beskrives med utgangspunkt i hvordan kjerneløsninger er realisert i helse- og omsorgstjenesten. I dagens situasjon (se følgende figur) skal hver enkelt virksomhet som yter helsehjelp sørge for å ha behandlingsrettede helseregistre for gjennomføring av helsepersonells dokumentasjonsplikt (Lovdata). Figur 2. Dagens situasjon med hensyn til kjerneløsninger I spesialisthelsetjenesten har det over tid foregått en konsolidering av kjernesystemene regionalt. Helse Midt-Norge RHF, Helse Nord RHF og Helse Vest RHF har per dags dato sluttført den tekniske konsolideringen av kjerneløsningene, mens Helse Sør-Øst RHF fortsatt er i prosess med å gjennomføre denne konsolideringen. For kommunal helse- og omsorgstjeneste er situasjonen mer fragmentert der hver kommune og fastlege har en eller flere kjerneløsninger (illustrert med en kollasj av prikker). 8

52 Utredningen for Én innbygger én journal konkluderte med at en felles, nasjonal løsning for klinisk dokumentasjon, prosesstøtte og pasient-/brukeradministrasjon skal være målbilde for den samlede nasjonale utviklingsretningen. Dette utgjør sentral milepæl 3 (M3) i det gjeldende veikartet (se følgende figur): Figur 3. Målbilde for Én innbygger én journal. Følgende bilde viser til realiseringen av målbilde for Én innbygger én journal gjennom tre overordnede milepæler. Hver milepæl representerer en tilstand: Figur 4. Veikart for realisering av Én innbygger én journal gjennom regional utprøving av målbilde i Midt-Norge og nasjonal anskaffelse, tilpasning og innføring av en felles løsning for kommunal helse- og omsorgstjeneste. Milepæl 1 (M1) Milepæl 2 (M2) Milepæl 3 (M3) Programmet «Helseplattformen» i Region Midt-Norge gjennomføres som et regionalt utprøvingsprogram for det anbefalte nasjonale målbildet i «Én innbygger én journal» der det etableres en felles løsning for klinisk dokumentasjon, prosesstøtte og pasient-/brukeradministrasjon for helseforetakene, kommunene og fastlegene i regionen Det etableres en felles nasjonal løsning for kommunal helse- og omsorgstjeneste (inkludert fastlegene) for kommunene utenfor region Midt-Norge. Det utarbeides et separat styrings- og beslutningsunderlag for dette tiltaket. Milepælen er ennå ikke besluttet. En felles, nasjonal løsning for klinisk dokumentasjon, prosesstøtte og pasient-/brukeradministrasjon for helse- og omsorgstjenesten er etablert. 9

53 2.3 Beskrivelse av sentrale forutsetninger for gjeldende veikart For milepælene M1 og M2 er forutsetningene i regjeringsbeslutning og anbefalinger fra Helsedirektoratet og Direktoratet for e-helse lagt til grunn. Felles forutsetninger: Helse Nord RHF, Helse Sør-Øst RHF og Helse Vest RHF fullfører vedtatte strategier om regional konsolidering og modernisering av kjernesystemene. Konsolideringen omfatter også at avtalespesialister tilknyttet de regionale helseforetakene bruker de samme kjernesystemene. Moderniseringen omfatter at kjernesystemene videreutvikles slik at de oppfyller kriteriene for en Generasjon 3 - løsning i henhold til Gartners generasjonsmodell. Helse Nord RHF, Helse Sør-Øst RHF og Helse Vest RHF identifiserer og realiserer potensial for skalafordeler i modernisering av kjernesystemene. De tre regionale helseforetakene har fått styringssignaler om å «sørge for en felles plan og koordinert utvikling av elektronisk pasientjournal (EPJ) og pasientadministrative system (PAS), blant annet for å danne grunnlag for felles realisering av Én innbygger én journal.» Forutsetninger for M1: Denne sentrale milepælen innebærer at Helseplattformen i region Midt-Norge gjennomføres som et regionalt utprøvingsprogram for målene i «Én innbygger én journal». Milepælen er nådd når alle helseforetak, avtalespesialister, kommuner og fastleger i regionen bruker felles kjerneløsning. Figur 5. Sentral milepæl 1 Helseplattformen som et regionalt utprøvingsprogram for målsettingen i Én innbygger én journal. I utgangspunktet innebærer Helseplattformen etablering av en regional fellesløsning for pasientadministrasjon og dokumentasjon av helsehjelp på tvers av kommunal helse- og omsorgstjeneste, inkludert fastlegene, og spesialisthelsetjenesten, inkludert avtalespesialistene. I et nasjonalt perspektiv tilsvarer dette et konseptalternativ som ble 10

54 forkastet i utredningen pga. lavere samfunnsøkonomisk nytte 1. Behovene, kravene og effektene som Midt-Norge ønsker å oppnå gjennom Helseplattformen er likevel i tråd med det anbefalte langsiktige nasjonale målbildet foreslått i utredningen. Tiltaket i Midt-Norge representerer derfor en mulighet for en begrenset geografisk utprøving av det langsiktige nasjonale målbildet og et mulig startpunkt for en nasjonal løsning for kommunale helse- og omsorgstjenester. Helseplattformen kan eventuelt også skape et nytt mulighetsrom for de andre regionale helseforetakene. Forutsetninger for realiseringen av den sentrale milepælen er: Anskaffelsesprosessen fører til at det inngås en kontrakt med leverandører som dekker de samlede behovene, også de som er gjelder kommunal helse- og omsorgstjeneste (inkludert fastleger). Kommunene (inkludert fastlegene) i Midt-Norge utløser opsjonen om å bruke løsningen som etableres av Helseplattformen. Forutsetninger for M2: I denne sentrale milepælen er det etablert en felles, nasjonal løsning for kommunale helseog omsorgstjenester (inkludert fastleger) for kommunene utenfor region Midt-Norge. Milepælen er startpunktet for utviklingsretningen mot «Én innbygger én journal». Figur 6. Sentral milepæl 2 En felles, nasjonal løsning for kommunale helse- og omsorgstjenester (inkludert fastleger) for kommunene utenfor region Midt-Norge Forutsetninger for realiseringen av den sentrale milepælen er: Spesialisthelsetjenesten deltar aktivt i utviklingen av en felles nasjonal løsning for kommunale helse- og omsorgstjenester, når det gjelder å utarbeide anskaffelsesgrunnlag, helsefaglig normering og forvalting, samt å tilpasse seg krav som styrker samhandlingen mellom aktørene. 1. Helseplattformen tilsvarer konseptalternativ 3 i utredning av «Én innbygger én journal» hvor en regional fellesløsning etableres gjennom en ny løsning (nyanskaffelse). Konseptalternativ 4 innebærer at en regional fellesløsning etableres med utgangspunkt i spesialisthelsetjenestens eksisterende løsning (gjenbruk). Den samfunnsøkonomiske analysen var knyttet til konseptalternativ 4. 11

55 Det etableres nasjonal styring som stiller tydelige krav og føringer for IKT-utviklingen i virksomhetene slik at den kollektive gjennomføringsevnen økes. Det er aktiv deltagelse fra nasjonale fagmyndigheter, kommuner, spesialisthelsetjenesten og pasient-/brukerorganisasjoner i planarbeidet med en nasjonal løsning for kommunal helse- og omsorgstjeneste. Det etableres en finansieringsmodell som sikrer finansiering i tiltakets levetid, fra anskaffelsesfasen, utviklingsfasen, implementeringsfasen og FDVU-fasen og som gir riktige insentiver for implementering, ibruktakelse og gevinstrealisering. 2.4 Vurdering av gjeldende veikart Det vil gjennomføres en vurdering av gjeldende veikart. Vurderingen av gjeldende veikart vil bli gjort langs følgende dimensjoner: 1. Vurderingen av usikkerheten knyttet til de sentrale forutsetningene for realisering av de sentrale milepælene. 2. Vurdering av tidsperioden det vil kreves før målbilde om Én innbygger én journal er realisert gitt ulike prinsipper for avskrivning av IKT-løsningene (tidsscenarier). 3. Vurderingen av finansieringsbehovet gitt ulike tidsscenarier og omfang. 4. Vurderingen av realisering av effektpotensiale gitt ulike tidsscenarier og omfang. 5. Vurderingen av hvilke alternative tiltak som foreligger for å håndtere usikkerhet i forutsetningene. Vurderingene vil danne grunnlaget for å utarbeide og presentere alternative veikart. Prosjektet vil i møtet presentere de alternativer som foreløpig synes mest realistiske. 12

56 3 Realiseringsmodell for realisering av utviklingsretningen 3.1 Hva er en realiseringsmodell? Realiseringen av de sentrale milepælene beskrevet i forrige avsnitt vil foregå over lang tid. I parallell med at Helseplattformen etablerer løsning for region Midt-Norge, og det eventuelt etableres en nasjonal løsning for kommunal helse- og omsorgstjeneste vil det være nødvendig å løse prioriterte behov for helsepersonell, innbyggere og innen helseanalyse. Realiseringsmodellen beskriver: c. Hvordan transisjonen fra en milepæl til neste vil understøttes av utvikling av nasjonale løsninger innen viktige arkitekturområder, som samhandling og integrasjon, sikkerhet og grunndata. d. Hvordan utviklingen av innbyggertjenester, helseanalyse og velferdsintegrasjon skal harmoniseres med utviklingen innen kjernesystemene. 3.2 Behov for helsepersonelltjenester som må kunne løses i perioden M0 - M2 Med helsepersonelltjenester menes her IKT-løsninger og tjenester rettet mot helsepersonell, dvs. tjenester hvor helsepersonell er sluttbrukere. IKT-løsninger som behandler informasjon om helsepersonell og deres organisasjoner, eller på annen måte påvirker funksjonalitet og utforming av løsninger indirekte regnes ikke som helsepersonelltjenester. I Nasjonal strategi og handlingsplan er behovene beskrevet i innsatsområder. For hvert innsatsområde er det uttrykt mål for strategiperioden. Behov som berører helsepersonell direkte er: #1.1 Modernisere EPJ #1.2 Digitalisere legemiddelkjeden innenfor helseforetakene og i kommunene #2.2 Sikre kontinuitet i ansvarsoverganger #2.3 Dele oppdatert legemiddelinformasjon i hele pasientforløpet #2.4 Dele viktige helseopplysninger i den akuttmedisinske kjeden #3.1 Forenkle innrapportering og uthenting av data fra helseregistre #3.2 Tilby sammenstilte helsedata og avansert analysefunksjonalitet på tvers av helsedatakilder #4.1 Legge til rette for raskere spredning og innovasjon av velferdsteknologi i helse- og omsorgstjenesten Det er også forventet at region Midt-Norge vil ha egne IKT-behov for å understøtte samhandling med øvrige deler av helsetjenesten når Helseplattformen implementeres, for 13

57 eksempel innen behandling med legemidler, håndtering av kritisk informasjon og forvaltning av beslutningsstøtte. Den valgte realiseringsmodellen skal kunne møte behovene både fra nasjonal strategi og fra Helseplattformen. 3.3 Alternative realiseringsmodeller Det er identifisert tre forskjellige hovedalternativer for realisering av M2 (nasjonal løsning for kommunal helse- og omsorgstjeneste) knyttet til nasjonale e-helsekomponenter: Modell A: Gjenbruk og tilpassing av eksisterende komponenter Modell B: Etablering av en ny plattform for tjenester for helsepersonell Modell C: Nasjonale tjenester realiseres i ny nasjonal kommunal løsning For hver av modellene er det skissert hva som er det fundamentale arkitekturvalget. Tjenester kan unntaksvis realiseres utenom den aktuelle arkitekturen i valgt modell som følge av vurderinger basert på blant annet kost, nytte, risiko, implementeringstid, realiseringstid. Hovedtyngden av tjenestene vil realiseres med valgt arkitektur for hver enkelt realiseringsmodell, og dette innebærer også at for nye løsninger så skal den valgte realiseringsmodellen benyttes Modell A: Gjenbruk og tilpasning eksisterende komponenter Modell A tar utgangspunkt i dagens arkitektur og komponenter for realisering av de nasjonale løsningene. Den eksisterende arkitekturen er i hovedsak basert på frittstående arkitekturer for de enkelte tjenestene. Noen tjenester er samlet på en felles løsning, eksempelvis Kjernejournal som har tjenester som egenregistreringer, kritisk Info, legemiddelhistorikk og besøkshistorikk på sykehus. Disse tjenestene benytter samme arkitektur (applikasjon, infrastruktur, sikkerhet), driftsmiljø- og plattform og kan dermed betraktes som en avgrenset plattform. De nevnte tjenestene har hatt felles innføring, og har felles forvaltning. Tilsvarende er også helsenorge.no en avgrenset plattform som tilbyr flere nasjonale tjenester (men rettet primært mot innbyggere). 14

58 Figur 7 Gjenbruk av dagens komponenter til å realisere M2 Nye tjenester, hvor det ofte ikke er et realiseringsalternativ å tilpasse eksisterende løsninger, må etablere nye arkitekturer, infrastruktur og forvaltning Modell B: Etablering av en ny plattform for tjenester for helsepersonell Modell B tar utgangspunkt i å samle porteføljen av nasjonale løsninger på en egen selvstendig plattform. Hensikten med denne modellen er å få synergier i forhold til en felles plattform og fellestjenester som eksempelvis tilgangsstyring, logging, utrulling, drift og forvaltning. Modellen har to hovedalternativer. Alternativ 1 er etablering av en plattform med bruk av et produkt levert av leverandør med spisskompetanse på plattformer med e-helse kapabiliteter. En slik plattform må tilfredsstille de strenge kravene som gjelder for E-helse løsninger, og gjennom åpne grensesnitt muliggjøre at ulike aktører kan levere løsninger på plattformen. For dette alternativet er det to prinsipielle tilnærminger som kan vurderes ved en anskaffelse: - Kjøp av en løsning der leverandør får betalt for sitt produkt og tilhørende tjenester. - Kjøp av tjeneste der leverandør får betalt for løpende tjenester 15

59 Alternativ 2 for modell B er å etablere en plattform for tjenester for helsepersonell med å tilpasse eksisterende løsninger og komponenter eller utvikle hele plattformen fra start av. En slik plattform vil være en unik avgrenset plattform, med stort rom for tilpasninger men hvor man er ansvarlig for alt utviklingsarbeidet, forvaltning og videreutvikling. Felles for alternativene i modell B er at man investerer i en plattform for tjenester for helsepersonell med den hensikt å oppnå skalafordeler. Figur 8 Etablering av plattform for tjenester for helsepersonell Modell C: Nasjonale tjenester realiseres i ny nasjonal kommunal løsning I modell C realiseres nasjonale tjenester i den nye nasjonale kommunale løsningen for kommunal helse- og omsorgstjeneste. Dette gjelder både for nye og eksisterende nasjonale tjenester. For denne modellen vil det være nødvendig med frittstående- og totalvurderinger om det er hensiktsmessig å flytte eksisterende løsninger, og når ut i fra kost, nytte, realiseringstid av målbildet M3, risiko m.fl. For noen løsninger kan det være aktuelt å kun flytte deler av de, eksempelvis kun datalageret eller enkelte av tjenestene i en større løsning. Det er etablert flere nasjonale løsninger som kompenserende tiltak i mangel av «Én innbygger én journal» (EIEJ). I modell C er det naturlig at disse inngår som en tjeneste i 16

60 den nye nasjonale løsningen for kommunal helse- og omsorgstjeneste, som er startpunkt for utviklingsretningen mot «Én innbygger én journal». Figur 9 Nasjonale tjenester realiseres i ny nasjonal kommunal løsning 3.4 Prinsipper for valg av realiseringsmodell Realiseringsmodellene vil vurderes opp mot hverandre basert på et sett av prinsipper som utarbeides i det videre arbeid. Kost, nytte, realiseringstid og risiko er sentrale hensyn. Det vil også være behov for vurdering av tradisjonelle arkitekturprinsipper. Eksempler kan være fleksibilitet, skalerbarhet, sikkerhet. Det vil også vurderes om det er behov for prinsipper knyttet til dokumentasjonsplikt, databehandlingsansvar og brukerfunksjonelle forhold. 17

61 4 Videre arbeid Beslutningsunderlaget for veikart for realiseringen av målbilde for Én innbygger én journal skal leveres i løpet av De viktigste aktivitetene i perioden september desember er: Å gjennomføre en usikkerhetsanalyse på de mest sentrale forutsetningene. Usikkerhetsanalysen baserer seg på en dokumentgjennomgang av strategier og planer for spesialisthelsetjenesten, gjennomføring av arbeidsmøter med sektorens aktører. Å verdsette kostnader og nytte for veikartet basert på oppdatert informasjon. Å beskrive alternative veikart med forutsetninger knyttet til disse. Beslutningsunderlaget for valg av realiseringsmodell for arkitekturområder vil utarbeides i løpet av 2017 og begynnelsen av De viktigste aktivitetene i perioden er: Å vurdere realiseringsmodellene opp mot definerte kriteria og prinsipper Å beskrive implikasjonene av valgt realiseringsmodell for utviklingen av nasjonale løsninger. 18

62 Vedlegg 7C Notat Til NUFA Kopi - Dato Saksnr NUFA-sak 26/17 Fra Saksbehandler Ansvarlig Inga Nordberg Roy Sigvartsen Vidar Mikkelsen

63 Oppsummering For at Direktoratet for e-helse skal være en premissgiver på arkitektur for elektronisk samhandling, kreves god dokumentasjon av referansearkitekturer og arkitekturprinsipper, av dagens situasjon og av et fremtidig målbilde noe som i dag mangler for samhandlingsarkitektur. På bakgrunn av dette har delprosjekt Samhandlingsarkitektur blitt startet. Hovedformålet med delprosjekt Samhandlingsarkitektur er derfor å gjøre Direktoratet for e-helse i stand til å utøve sin myndighetsrolle knyttet til arkitekturstyring av elektronisk samhandling. Delprosjektet har 4 leveranser: - Overordnet beskrivelse av samhandlingsarkitekturer som inkluderer samhandlingsmodellene, hvilke faktorer som modellene gjenkjennes på og anbefalinger på valg av modell ved utarbeidelse av løsningsarkitekturer. - Referansearkitektur for meldingsutveksling inkludert dokumentutveksling og som dokumenterer as-is arkitektur og målarkitektur - Referansearkitektur for dokumentdeling dokumentutveksling og som dokumenterer as-is arkitektur og målarkitektur - Referansearkitektur for datadeling og som dokumenterer as-is arkitektur og målarkitektur I annet halvår av dette året skal delprosjektet jobbe frem anbefalinger for målarkitekturer for elektronisk samhandling. Vi legger opp til dialog med sektoren og vi ønsker kontakt med personer som er interessert i problemstillinger rundt samhandling. Dette er en unik mulighet for å påvirke fremtidens samhandling i helse- og omsorgstjenesten. Vi ønsker oss innspill på: - Hvordan best gjøre arbeidet kjent i sektoren og i deres organisasjon. - Hvordan best å involvere sektoren i dette arbeidet. - Nytteverdi som dere ser i dette arbeidet. 2

64 Innhold 1 Samhandlingsarkitektur i helse- og omsorgstjenesten Bakgrunn Hva er en referansearkitektur? Sammenheng mellom referansearkitektur, løsningsarkitektur og standarder Samhandlingsmodeller Fremgangsmåte og leveranser Leveranser Struktur på dokumentasjon av referansearkitekturer Modelleringsspråk Resultater så langt Meldingsutveksling Dokumentdeling Datadeling Videre arbeid

65 1 Samhandlingsarkitektur i helse- og omsorgstjenesten I helse- og omsorgssektoren er det stort behov for elektronisk samhandling mellom ulike aktører og pasienter. Elektronisk samhandling er en utfordring i helsesektoren med over aktører og disse bruker igjen svært mange ulike løsninger som har behov for å samhandle med andre løsninger. 1.1 Bakgrunn Direktoratet for e-helse har blitt tildelt en myndighetsrolle for forvaltning og styring av nasjonal e-helse arkitektur, e-helsestandarder og kodeverk og terminologi. For å være en premissgiver på arkitektur for elektronisk samhandling, kreves god dokumentasjon av referansearkitekturer og arkitekturprinsipper, av dagens situasjon og av et fremtidig målbilde noe som i dag mangler for samhandlingsarkitektur. Formålet med delprosjekt Samhandlingsarkitektur er å gjøre Direktoratet for e-helse i stand til å utøve sin myndighetsrolle knyttet til arkitekturstyring av elektronisk samhandling, samt å sørge for at innspill på nye behov knyttet til elektronisk samhandling blir behandlet gjennom ordinære styringsprosesser. Vi har valgt å benytte begrepet samhandlingsarkitektur som: "en nasjonal referansearkitektur innen elektronisk samhandling" i denne konteksten. Vi har også valgt å snakke om flere samhandlingsarkitekturer siden behovene for utveksling av informasjon krever ulike typer av samhandling. En referansearkitektur kan sies å være en generisk beskrivelse av en arkitektur og vil fungere som en mal på en spesiell type arkitektur innen et gitt område. Difi definerer det som "Referansearkitekturer er beste praksis for hvordan man løser avgrensede, men gjentakende, problemstillinger." Nasjonale referansearkitekturer innen elektronisk samhandling vil dekke følgende behov: 1. Fungere som et styringsgrunnlag for arkitekturstyring 2. Danne rammer for hvilke standarder og nasjonale profiler som må etableres, gjenbrukes eller endres. 3. Etablere et målbilde for elektronisk samhandling som vil være førende når virksomheter samt nasjonale løsninger skal utveksle informasjonen. 4. Sikre at samme type informasjonsutvekslingsbehov løses på en ensartet måte. 5. Gjenbruke samhandlingsmetoder i ulike scenarioer hvor samme type utveksling av informasjon er nødvendig. 6. Bidra til forståelse av grenseoppgang mellom komponenter og fagsystemer samt deres roller og ansvar 4

66 1.2 Hva er en referansearkitektur? Referansearkitektur-begrepet benyttes i mange kontekster og det kan forekomme at de kan ha ulike formål i disse kontekstene. Det er derfor behov for å beskrive hva vi mener med referansearkitektur i vår kontekst. Difi definerer en referansearkitektur slik: Referansearkitekturer er beste praksis for hvordan man løser avgrensede, men gjentakende, problemstillinger. Et eksempel fra den analoge virkeligheten er at de fleste dører er rektangelformede. Avvik fra denne normen er kostnadsdrivende fordi en må spesialbestille, og har en tendens til å skape problemer for både de som skal bygge huset og de som skal bruke døren etterpå. En referansearkitektur beskriver både forretnings-, applikasjons-, informasjons- og teknologilag. Bruk av referansearkitekturer bidrar til et felles språk, konsistent implementering av tekniske løsninger og etterlevelse av felles standarder. Referansearkitekturer kan ha ulike detaljeringsnivå, fra overordnet til svært spesifikke. Den danske IT- og telestyrelsen definerer referansearkitektur slik: En referencearkitektur er en velovervejet måde at bygge it-løsninger indenfor et specifikt område. Referencearkitekturen beskriver de overordnede logiske strukturer og begrebsapparatet for det specifikke område, således at der er et godt grundlag at arbejde ud fra, når der skal skabes sammenhængende it-løsninger. En referencearkitektur beskriver, udover de logiske strukturer og begrebsapparatet, også de grundlæggende logiske forretningstjenester og -begreber inden for referencearkitekturens fokus. Ofte beskrives på logisk plan også de generiske forretningstjenester og -begreber, som benyttes i grænsefladen omkring referencearkitekturen. Referencearkitekturer kan beskrives på flere abstraktionsniveauer. På et meget højt abstraktionsniveau vises alene de grundlæggende strukturer og den tilgrænsende omverden. I mere detaljerede niveauer ser man ofte beskrevet logiske tjenester, kernebegreber og interaktion mellem disse. En referencearkitektur opstiller fælles pejlemærker og principper for udviklingen af området. Referencearkitekturen giver både myndigheder (bestillere) og leverandører (udbydere) fælles sigtepunkter for udviklingen af området. I vår kontekst beskriver en referansearkitektur de logiske strukturer og begrepsapparatet som gjelder innenfor ett spesifikt område på et overordnet nivå. Referansearkitekturen kan også gi eksempler på logiske tjenester, komponenter og hvordan interaksjon skal foregå mellom disse. 5

67 Figur 1 En referansearkitektur kan beskrives på mange ulike abstraksjonsnivåer og kan benyttes av ulike løsningsarkitekturer Generelt kan en referansearkitektur beskrives på mange ulike abstraksjonsnivåer, fra spesifikk til mer generelle. En løsningsarkitektur kan anvende flere referansearkitekturer da en referansearkitektur kun beskriver et avgrenset problemområde, mens en løsningsarkitektur kan dekke flere problemområder. En nasjonal referansearkitektur for helse- og omsorgstjenesten gir både virksomheter og leverandører informasjon om felles rammeverk, standarder og profiler som gjelder for utviklingen av området. En referansearkitektur har dermed et begrenset virkeområde. På øverste nivå beskriver man de forretningsmessige mål for området og beskriver ønskede egenskaper komponentene innen området skal ha. Deretter slår man fast hvilke overordnede prinsipper som må gjelde for komponenter, informasjonselementer og infrastruktur- og fellestjenester. På bakgrunn av dette identifiserer man områdene som kan standardiseres. 6

68 1.3 Sammenheng mellom referansearkitektur, løsningsarkitektur og standarder Figur 2 Nasjonal referansearkitektur i en nasjonal kontekst Det er viktig å forstå hvordan de ulike begrepene forholder seg til hverandre. Figuren over viser hvordan en referansearkitektur forholder seg til løsningsarkitekturer og standarder, samt hvilke eksterne rammevilkår som påvirker en referansearkitektur. Merk at en virksomhets kan også ha sine egne referansearkitekturer eller at et helseforetak må forholde seg til en referansearkitektur gitt av et RHF. 7

69 2 Samhandlingsmodeller Det er stort behov for å utveksle/dele informasjon med aktører i andre virksomheter. Det finnes ulike tekniske modeller for å samhandle på tvers, dette kalles samhandlingsmodeller. Samhandlingsmodellene kjennetegnes ved at de dekker ulike generiske samhandlingsbehov i helsesektoren. Aktørene som har behov for elektronisk samhandling kan være helsepersonell i en virksomhet eller innbyggere. Ulike samhandlingsmodeller kan potensielt benyttes for samme type informasjon, og de kan gjerne også kombineres. Noen av samhandlingsmodellene er veletablerte og i stor bruk, mens andre er det mindre erfaring med. I delprosjekt Samhandlingsarkitektur arbeider vi med å detaljere disse. Figur 3 Samhandlingsmodeller i helse- og omsorgstjenesten Følgende samhandlingsmodeller har vi identifisert: 1. Meldingsutveksling overføring av strukturerte data til kjent mottaker 2. Dokumentutveksling overføring av godkjent, lesbart dokument, med varierende grad av struktur 3. Dokumentdeling deling av godkjent, lesbart dokument gjennom felles infrastruktur/tjenester 4. Datadeling - deling av strukturerte data gjennom felles ressurser/tjenester 5. Direkte tilgang (innsyn) til felleskomponent eller løsning i en annen virksomhet 6. Samhandling i felles kjernesystem I delprosjekt Samhandlingsarkitektur arbeider vi med samhandlingsmodellene nr 1 til 4. Større behov for elektronisk samhandling vil kreve bruk av flere teknikker for samhandling. Valg av samhandlingsmodeller i en løsningsarkitektur bør tilpasses de behov som man har i hver kontekst. Eksempel på faktorer som kan påvirke valg av samhandlingsmodell: responstid/synkronitet 8

70 tilgjengelig infrastruktur (tilgjengelighet) behov for å bevare struktur el. kun visning informasjonssikkerhet og personvern juridiske forhold behov for samtykke fra pasient hvor mange aktører som omfattes Som en del av arbeidet i delprosjektet vil disse faktorene bli beskrevet nærmere sammen med anbefalinger av valg av samhandlingsmodeller. 9

71 3 Fremgangsmåte og leveranser Delprosjektet Samhandlingsarkitektur har samlet arkitekter fra flere miljøer innen Direktoratet for e-helse og Norsk Helsenett. Arbeidet har vært organisert i 2 ulike arbeidsgrupper. Confluence og Enterprise Architect er benyttet som arbeidsverktøy. 3.1 Leveranser Delprosjektet har 4 leveranser: - Overordnet beskrivelse av samhandlingsarkitekturer som inkluderer samhandlingsmodellene, hvilke faktorer som modellene gjenkjennes på og anbefalinger på valg av modell ved utarbeidelse av løsningsarkitekturer. - Referansearkitektur for meldingsutveksling inkludert dokumentutveksling og som dokumenterer as-is arkitektur og målarkitektur - Referansearkitektur for dokumentdeling dokumentutveksling og som dokumenterer as-is arkitektur og målarkitektur - Referansearkitektur for datadeling og som dokumenterer as-is arkitektur og målarkitektur 3.2 Struktur på dokumentasjon av referansearkitekturer Strukturen i våre leveranser er basert på beste praksis for dokumentasjon av virksomhetsarkitekturer (TOGAF). Dokumentene som beskriver referansearkitekturene har følgende oppbygning: o o o o o o Visjon og målbilde - hva man ønsker å oppnå med elektronisk samhandling ved hjelp av de enkelte samhandlingsmodellene Rammevilkårene for arkitekturen slik som lover og forskrifter og arkitekturprinsipper. Eksempler på forretningsmessige anvendelser av en samhandlingsmodell. Begrepsmodeller - som viser sammenheng mellom ulike informasjonsobjekter innen en samhandlingsmodell Referansearkitekturen- beskrivelse av hvilke byggeklosser man trenger for å realisere en samhandlingsmodell og hvordan disse byggeklossene er realisert i kjente anvendelser. Beskrivelse av "AS-IS" arkitektur - teknisk beskrivelse av implementasjonen av arkitekturen for de valgte eksempler på kjente anvendelse av en samhandlingsmodell. 10

72 Det er lagt vekt på å benytte felles begreper og generiske modeller som skal gjelde både for eksisterende anvendelser av en samhandlingsmodell, fremtidige anvendelser samt for sammenligning av ulike samhandlingsmodeller. Eksisterende anvendelser er en beskrivelse av dagens situasjon og er et viktig utgangspunkt for videreutvikling av arkitekturer. De fungerer også som eksempler på de generiske modellene. 3.3 Modelleringsspråk For "as-is" dokumentasjon har vi gjenbrukt eksisterende figurer og diagrammer. Disse er av ulik karakter og benytter derfor ulike teknikker. De arkitekturdiagrammer som er utarbeidet i denne dokumentasjonen er modellert ved hjelp av Archimate og noe i BPMN. Diagrammene er laget vha Sparx Enterprise Architect og modellene er strukturert i et felles repository for Direktoratet for e-helse. Archimate ArchiMate er et åpent og uavhengig modelleringsspråk fra The Open Group som gir arkitekter et verktøy for å beskrive, analysere og visualisere objekt og relasjoner innen forretning - og virksomhetsdomenene. Notasjoner og bruk av relasjoner er i henhold til Direktoratets modelleringshåndbok. 11

73 4 Resultater så langt 4.1 Meldingsutveksling Med meldingsutveksling menes her samhandlingsmodellen hvor en avsender overfører strukturerte data til kjent mottaker (som en del av en automatisk prosessering), og med dokumentutveksling menes samhandlingsmodellen hvor en avsender overfører et godkjent, lesbart dokument, med varierende grad av struktur til en kjent mottaker. I helse- og omsorgstjenesten har vi ofte omtalt dokumentutveksling som meldingsutveksling, og en elektronisk melding kan derfor dekke både meldingsutveksling og dokumentutveksling. Det finnes i dag flere anvendelser av meldingsutveksling i helse- og omsorgstjenesten. De viktigste av disse vil bli omtalt i dette dokumentet for å kunne koble anvendelsene mot selve referansearkitekturen for meldingsutveksling. Anvendelsene som er beskrevet er: Mange-til-mange meldingsutveksling som er den etablerte og standardiserte måten å sende og motta meldinger på mellom helsepersonell. E-resept meldingsutveksling som foregår mellom rekvirenter, Reseptformidleren, utleverere, Helfo og Statens legemiddelverk. Digital Dialog på Helsenorge.no plattformen som er knyttet til dialog mellom innbygger og helsepersonell hvor meldingsutveksling benyttes som samhandlingsmodell. Andre anvendelser, slik som meldingsutveksling med NAV, Helfo og helseregistre er holdt utenfor scopet av delprosjektet. 12

74 Figur 4 Referansearkitektur for meldingsutveksling I figuren over er en beskrivelse av byggeklossene som kreves innen meldingsutveksling. I anvendelsene beskrevet over er det i bruk tre ulike teknikker for meldingsutveksling: ebxml/ebms, AMQP og webservices. Figur 5 Totaloversikt over dagens meldingsutveksling 13

75 I figuren over er det benyttet en interoperabilitetsmodell for å vise alle aspekter med meldingsutveksling. Høyre side forklarer hva som er hvert enkelt lag består av Denne viser f.eks. at innholdsstandardene som benyttes er uavhengig av det kommunikasjonsrammeverk som benyttes og de kan i prinsippet inngå i flere prosesser. De tre kommunikasjonsrammeverk som er i bruk har ulike egenskaper og dekker derfor ulike behov. Alle anvendelsene som er vist i figuren over er styrt av ulike lover og forskrifter. Mange til mange meldingsutveksling Bruk av ebxml-rammeverket er hjemlet i forskriften for IKT-standarder i helse- og omsorgstjenesten. Dette er kun obligatorisk for aktørgrupper og fagmeldinger som er listet opp i 6 av forskriften. Dette er en begrenset gruppe fagmeldinger og i Referansekatalogen mangler man anbefalinger for andre anvendelser og aktører. E-resept Reseptformidleren i e-resept er hjemlet i egen forskrift. Ved samhandling med Reseptformidleren benyttes det to ulike kommunikasjonsrammeverk: Reseptformidleren benytter ebxml-rammeverket for å sende meldinger til Rekvirenter og Ekspedienter og for å motta applikasjonskvitteringer. Alle Rekvirenter og Ekspedienter benytter webservices hos Reseptformidleren for å sende meldinger til Reseptformidleren. Tidligere hadde Reseptformidleren støtte for mottak både via webservices og ebxml, men pga at ingen benyttet ebxml ble denne støtten fjernet. I Reseptformidleren finnes det samhandlinger som benytter annen svarmelding enn applikasjonskvittering. Dette simulerer synkron oppførsel og det kan da diskuteres om dette er meldingsutveksling eller datadeling (API-basert). Digital dialog med innbygger Digital dialog mellom innbygger og helsepersonell via Helsenorge.no er ikke hjemlet i egen lov, men følger personopplysningsloven. Anvendelsen benytter egen profil av dialogmeldingen for å støtte mange ulike dialoger med innbygger og helsepersonell. Digital dialog benytter AMQP som kommunikasjonsrammeverk. AMQP kan beskrives slik: Er en åpen standard Alle aktører som støtter Digital dialog har egne køer for mottak av meldinger på NHN sin AMQP server (MS azure basert). Hver av aktørene har: o o o En kø for asynkrone meldinger (lang svarfrist basert på manuelt generert svar) og En kø for synkrone meldinger (svært kort svarfrist basert på automatisk generert svar) for simulering av datadeling i en meldingsbasert samhandling Adresseinformasjon til køene i Adresseregisteret 14

76 Klienter av AMQP kan koble sin lokale transaksjonshåndtering med køtransaksjonene for å lese meldingen fra sin kø og legge svar på avsenders kø. Bruk av AMQP i denne anvendelsen strider ikke med anvendelsesområdet til ebxmlrammeverket, men det kan for mange oppleves kompleks å støtte flere kommunikasjonsrammeverk. Det er tilgjengelig åpen programvarekode for bruk av AMQP som Helsenorge.no prosjektet har utviklet. Sammenligning av de ulike anvendelsene Mange til mange meldingsutveksling skiller seg fra meldingsutveksling i e-resept og Digital Dialog som kan beskrives som «mange til en». For eksempel: det er ingen nasjonal, sentral løsning som er involvert i mange til mange meldingsutvekslingen slik det er i e- resept og Digital Dialog. E-resept og Digital Dialog på Helsenorge.no har flere likhetstrekk som er løst ulikt: Begge har behov for sanntidskommunikasjon og automatiske svar på forespørsler. Dette er løst forskjellig: i e-resept er det benyttet webservices for dette, mens for Digital Dialog er det benyttet AMQP med kort svarfrist. EPJ systemer har lavere oppetid enn de nasjonale løsningene i e-resept og Digital Dialog som ikke være avhengig av at EPJ systemene er oppe for samhandling. Dette er løst forskjellig: i e-resept benyttes ebxml-rammeverket mens for Digital Dialog benyttes det AMQP med lang svarfrist. Begge baserer seg på at kommunikasjon fra nasjonal løsning legges tilgjengelig slik at EPJ systemer selv kan hente meldinger utenfor sin sikre sone. Dette er løst forskjellig: i e-resept benyttes SMTP servere hos Norsk Helsenett mens for Digital Dialog benyttes det AMQP-køer hos Norsk Helsenett. 4.2 Dokumentdeling Dokumentdeling er en samhandlingsform hvor produsenter av dokumenter deler informasjon om et dokument og i tillegg kan gjøre dokumentet tilgjengelig for konsumenter. En produsent er gjerne helsepersonell, men kan også være et system. I prinsippet kan et dokument være alt fra en strukturert melding til store bildefiler. Det som kjennetegner dokumentdeling er deling av informasjon som er å anse som endelig og dermed har lite behov for endringer. Dokumentdeling vil fungere slik at en konsument kan søke etter publiserte dokumenter fra andre produsenter i et dokumentregister og laste ned dokumenter fra et dokumentlager. I motsetning til dagens meldingsutveksling hvor mottaker av informasjon må være kjent når informasjonen skal distribueres, så tilrettelegger dokumentdeling for at dokumenter kan deles til helsepersonell som har behov for informasjonen etter at den er distribuert. For konsumenter av dokumenter muliggjør dette lagring av referanser til de originale dokumentene isteden for å lagre kopier. 15

77 Dagens behov for dokumentdeling er drevet av behov knyttet til helsepersonelltjenester og da spesielt deling av klinisk dokumentasjon mellom helsepersonell, men også for innsynstjenester for pasienter. Dokumentdeling håndteres gjennom at en gruppe virksomheter (en samarbeidsgruppe) går sammen om å dele visse typer dokumenter og registrerer metadata om dokumentene i et felles dokumentregister. Publisere-, søke- og hentetjenester tilbys som grensesnitt (APIer) og som krever tilgangskontroll og høy tilgjengelighet. Man kan ha samarbeidsgrupper som baseres på nasjonale komponenter, baseres på gjenbruk av eksisterende komponenter hos en eller flere virksomheter i gruppen eller som baseres på etablering av felles komponenter innad i en gruppe. Uavhengig av valgt konsept bør etablering av samarbeidsgrupper følge nasjonale standarder og referansearkitektur for å sikre en enhetlig implementering av grensesnitt, bruk av metadata samt av lover og forskrifter. Det bør være et mål at alle samarbeidsgrupper skal kunne kobles sammen på sikt. 16

78 Konsumerende virksomhet Felles/delte tjenester Produserende virksomhet <<eksempel>> lege Bruker Dokument søk Dokumentregister Bruker <<eksempel>> Pasient Dokument konsument Dokument registrering Dokumentkilde <<eksempel>> helsepersonell Dokumentlager <<eksempel>> EPJ Dokument henting Dokument publisering <<eksempel>> Labsystem Autentiserings tjeneste Autoriserings tjeneste Logging Figur 6 Referansearkitektur for dokumentdeling Figuren over viser referansearkitekturen for dokumentdeling og hvilke API-er og byggeklosser som denne samhandlingsmodellen består av. De felles tjenestene kan tilhøre en av virksomhetene eller det kan være nasjonale løsninger. Man kan ha et eller flere dokumentlagre, men typisk kun et dokumentregister. 4.3 Datadeling Datadeling er konseptuelt en kommunikasjonsform hvor konsumenter benytter funksjoner hos en produsent og hvor konsumentene forventer respons i sanntid. Med datadeling menes her samhandlingsmodellen hvor en konsument i sanntid etterspør/oppdaterer informasjon eller benytter en tjeneste hos en produsent gjennom en felles tjeneste eller samarbeider om felles ressurser. Samhandling gjennom datadeling tilrettelegger for at innbyggere og helseaktører kan ha en mer dynamisk informasjonsutveksling med andre aktører. En slik informasjonsutveksling kan være at en aktør etterspør informasjon fra en annen aktør og får svar i sanntid. En annen dialog kan være at en aktør oppdaterer informasjon hos en annen aktør og får bekreftelse i sanntid. Dette muliggjør at flere aktører kan samarbeide om felles ressurser der ressursene lagres kun et sted (fungere som masterdata), i motsetning til meldingsutveksling hvor samme data lagres hos alle mottakere av en melding. Dagens behov for datadeling nasjonalt er spesielt drevet av behov knyttet til helsepersonelltjenester (deling av data mellom helsepersonell), deling av data mellom pasient og behandler (eksempel velferdsteknologi) og behov for å tilgjengeliggjøre 17

79 grensesnitt fra nasjonale fellesløsninger til tredjeparts programleverandører. Det er en betydelig gjenbruksgevinst i å etablere en felles referansearkitektur for de ulike behovene. Datadeling håndteres gjennom tjenester som tilbys som grensesnitt (APIer) og som krever sikker tilgangskontroll på tvers av virksomheter og høy tilgjengelighet. For å tilby en felles plattform for publisering av grensesnitt fra ulike aktører, kreves sentral, nasjonal styring for å sikre at alle lover og forskrifter overholdes og nødvendig standardisering gjøres for å sikre en enhetlig utvikling og publisering av grensesnitt. Figur 7 Referansearkitektur for datadeling Figuren over viser referansearkitektur for datadeling. Sentrale byggeklosser i denne arkitekturen: 18

80 Byggekloss Klient Beskrivelse Den programvarekomponenten som på vegne av en bruker ønsker å benytte et API. Autentiseringstjeneste Tjeneste som har som formål å identifisere brukeren sikkert. Dette vil normalt gjøres ved at brukeren ber om å logge seg inn hos en identitetstilbyder. Komponenten kan realiseres på mange måter, alt fra som en del av API-et (ikke anbefalt) til en nasjonal løsning (f.eks ID-porten). Ved delegering av ansvaret må API eier ha tillit til at brukere blir sikkert identifisert. Autoriseringstjeneste Tjenesten har som formål å bestemme hvilken tilgang klienten og brukeren av klienten skal få til API-et. Tilgang kan styres gjennom mange ulike typer regler. Noen eksempler: Finnes det sperringer om å dele pasientens data? Er bruker autorisert helsepersonell? Er klienten fra en virksomhet som API eier har en avtale med? API gateway En inngangsport for API-et som kan styre om klientforespørsler slippes igjennom eller ikke. Vil inneholde en API-proxy som normalt er identisk med API-et. Denne byggeklossen kan tillegges ulikt ansvar, f.eks. ha ansvar for at klientene er autentisert og autorisert eller f.eks. kun ha ansvar for transportsikkerheten (typisk en revers proxy). I noen tilfeller kan forespørsler gå igjennom flere API gateways. En API gateway kan også være en del av en API management løsning. Datadeling Byggeklossen som eksponerer et API og har ansvar for kontrollere at alle forespørsler er autentisering og autorisert samt logge deling av data om pasienter. Også kalt for Ressursserver. API API står for Application Programming Interface og helt generisk betegner API et grensesnitt i en programvare som lar deg aktivere (kjøre) spesifikke deler av denne fra en annen programvare. Her brukes API i en kontekst hvor en virksomhet tilgjengeliggjør et grensesnitt i en programvare for andre virksomheter eller innbyggere. Også ofte kalt for Web API. Pasientjournal lokalisator Byggeklossen er tenkt å gi informasjon om hvilke virksomheter/systemer som har helseopplysninger om en pasient. Dette kan være nyttig i noen situasjoner: Situasjon 1: I dag er lagring av informasjon om pasienter desentralisert. Normal scenario for datadeling er at de som deler, 19

81 Byggekloss Beskrivelse oftest samarbeider om en pasient på en eller annen måte. Det er da forutbestemt hvem som skal slå opp/oppdatere hvor. I de tilfellene hvor flere virksomheter har gått sammen, men det er ikke forutbestemt hvem som "eier" pasienten eller har en pasientjournal, så må de som er på "jakt" etter informasjon spørre alle for å sjekke opp hvem som har pasientinformasjonen. Med denne byggeklossen kan man redusere denne kompleksiteten ved at pasientjournallokalisator byggeklossen gir deg en liste over dette. Dette krever at alle samarbeidende virksomheter implementerer identiske API-er slik at klientene ikke trenger å forholde seg til ulike API-er. Hver virksomhet må gi informasjon til denne byggeklossen ved opprettelse av nye pasientjournaler. Situasjon 2: Hvis pasienters innsynstjenester er implementert via datadeling, så må innsynstjenestene enkelt kunne spørre de virksomheter som har pasientinformasjon. Pasientjournallokalisator kan gi en liste over systemer som har slik informasjon og som da innsynstjenestene kan benyttes. API lokalisator Logg Byggeklossen kan gi informasjon om hvordan man når et API (endepunkt) og hvilke kapabiliteter det støtter. Samme funksjon som Adresseregisteret har innenfor meldingsutveksling. Det er et lovmessig krav å logge all innsyn i en pasients journal. Denne byggeklossen dekker ansvaret for å motta hendelser om innsyn og lagre dette sikkert og slik at det er uforanderlig. 20

82 5 Videre arbeid I annet halvår av dette året skal delprosjektet jobbe frem anbefalinger for målarkitekturer for elektronisk samhandling. Eksempler på spørsmål som vi vil søke svar på: Når bør hvilken samhandlingsmodell benyttes? I dag må leverandører forholde seg til 3-4 ulike kommunikasjonsrammeverk for ulike samhandlingsmodeller. Hvordan bør dette se ut i en fremtidig arkitektur? Mange til mange meldingsutveksling vil være en aktuell samhandlingsmodell selv etter etablering av EIEJ. Eventuelt utbytting av dagens ebxml-rammeverk til et enklere rammeverk vil ta lang tid. I et slikt scenario må man tillate bruk av mer enn et kommunikasjonsrammeverk i en overgangsfase. Kan AMQP være et alternativ? For datadeling vil tilgangskontroll være en sentral del. Bør dette etableres som en nasjonal løsning eller er det tilstrekkelig med standarder og enighet om hvordan det gjøres på tvers? Personvern har høy fokus og er sentralt ved deling av sensitiv informasjon. Hva bør løses nasjonalt og hva bør løses av den enkelte virksomhet. Vi ønsker oss innspill på: - Hvordan best gjøre arbeidet kjent i sektoren og i deres organisasjon. - Hvordan best å involvere sektoren i dette arbeidet. - Nytteverdi som dere ser i dette arbeidet. 21

83 REALISERINGSSTRATEGI VELFERDSTEKNOLOGISK KNUTEPUNKT VELFERDSTEKNOLOGIPROGRAMMET PROSJEKT ARKITEKTUR OG INFRASTRUKTUR Saksnummer i 360: Versjonsnummer: 1.0 Godkjent dato: Godkjent av: Utarbeidet av: Christine Bergland Thor Steffensen 1

84 Innhold 1. Behov og mål Bakgrunn Om behov Gjennomføringsprinsipper Mål Realiseringsalternativer Alternativ A: Gjenbruke og tilpasse en eksisterende, nasjonal plattform Alternativ B1: Kjøpe spesifikk pakkeløsning fra én totalleverandør Alternativ B2: Utvikle stegvis basert på behov Oppsummering og anbefaling Gjennomføring Gjennomføringsmodell Rask oppstart Stegvis utvikling bygge erfaring, lære og evaluere Gjennomføringsplan fase Prioritert funksjonalitet i fase Tidsplan fase Finansiering av fase Kritiske suksessfaktorer Risiko Underliggende dokumenter Ordliste

85 1. BEHOV OG MÅL 1.1. Bakgrunn Velferdsteknologiprogrammet har gjennom en rekke utprøvingsprosjekter nå god dokumentasjon på at velferdsteknologi gir positive effekter for brukerne, tjenesten og på helse- og omsorgssektorens bruk av ressurser. På tross av gevinstpotensialet er likevel ikke velferdsteknologi en integrert del av det norske helse- og omsorgstilbudet i dag. Erfaringer fra de kommunene som har kommet lengst med innføringen av velferdsteknologi viser at tekniske utfordringer med skalering, informasjonssikring og sammenkobling med de kommunale fagsystemene er en sentral barriere for kommunene. Fraværet av en felles infrastruktur hemmer utbredelsen av velferdsteknologi. Med dette som bakgrunn er det identifisert et behov for et nasjonalt velferdsteknologisk knutepunkt (heretter kalt knutepunkt) som kan sørge for nødvendig informasjonsflyt mellom velferdsteknologiske løsninger og forskjellige ITsystemer som benyttes i helse- og omsorgssektoren (f.eks. EPJ) på en sikker og enhetlig måte. Oslo kommune har i samarbeid med Norsk Helsenett utviklet en proof-of-concept (PoC) som viser hvilke muligheter som ligger i å benytte eksisterende infrastruktur i helsenettet og standard skybaserte tjenester for å knytte sammen velferdsteknologi med et kommunalt EPJ-system. Dette illustrerer muligheten for å utvikle knutepunktfunksjonalitet stegvis, i tett samarbeid med kommunene som kjenner behovene, uten store investeringer eller ressursbruk. Dette dokumentet beskriver alternative måter å realisere et slikt knutepunkt på, angir en anbefalt gjennomføringsmodell og en implementeringsplan for den anbefalte modellen. Et slik knutepunkt vil i første omgang løse spesifikke behov innenfor helse- og omsorg, men vil også kunne inngå i en helhetlig digital infrastruktur med tilhørende felleskomponenter og tjenesteplattformer. Dokumentet oppsummerer innhold fra mer detaljerte, underliggende dokumenter. Dokumentene omhandler blant annet behov og arkitektur. For detaljer henvises det til disse dokumentene (se kapittel 5) Om behov Den manglende felles infrastrukturen som skal benyttes for VFT-tjenester må ivareta noen sentrale behov før velferdsteknologi kan skaleres fra utprøving i smått til spredning i stort: Trygg og forsvarlig håndtering av informasjonen som kommer inn fra VFT-løsningene. Tilgang til nødvendig og relevant informasjon om tjenestemottaker for de hos tjenesteyter som har et tjenstlig behov for denne informasjonen. Påkobling av nye VFT-løsninger skal skje enkelt, uten store kostnader og på en måte som sikrer nødvendig datautveksling med eksisterende løsninger hos tjenesteyter. Disse behovene er ikke ivaretatt på en tilfredsstillende måte i dag. Markedet for VFT- løsninger preges av at kommuner og foretak kjøper inn VFT-utstyr og forsystemer fra leverandører i separate løsningskjeder. Dette gir gode tjenester for brukerne, men når antallet løsningskjeder og utstyr øker, oppstår det en utfordring når systemene ikke er integrert og dermed ikke «snakker med» hverandre. Det skapes separate siloløsninger for ulike typer velferdsteknologi, som mangler integrasjon med kommunens fagsystemer for helse- og omsorgstjenesten. Kommunene peker på at dette gir merarbeid ved at det må dokumenteres parallelt i flere systemer, og at det etter hvert blir vanskelig å forholde seg 3

86 til mange forskjellige systemer samtidig. Dette skaper frustrasjon og motvilje blant ansatte i helse- og omsorgstjenestene for å ta nye løsninger i bruk. Mange kommuner er i gang med anskaffelser av, eller har allerede anskaffet, nye digitale VFT-løsninger. Nesten samtlige av disse har sett behovet for å få til en integrasjon mellom disse løsningene og de kommunale EPJ-ene. Noen kommuner er allerede i gang med å etablere slike integrasjoner, i samarbeid med sine leverandører. Fra et samfunnsøkonomisk perspektiv er det lite hensiktsmessig å gjøre det på denne måten, og det vil også skape utfordringer for ambisjonen om en helhetlig arkitektur for e-helse. At hver enkelt kommune etablerer slike integrasjoner uten at det gjøres på en enhetlig måte som sikrer dataflyt mellom systemer nasjonalt, er veldig kostbart når det er samme type integrasjoner mot noen få typer av EPJ-systemer det er snakk om. Det haster derfor å tilby kommuner og leverandører denne type integrasjon gjennom et nasjonalt velferdsteknologisk knutepunkt. Merverdien av et slikt knutepunkt er illustrert under: Figuren gir konkrete eksempler på effekter av et nasjonalt knutepunkt, knyttet opp til de fire samfunnsmålene for denne satsningen: Effektiv kommunal ressursbruk (bærekraftig tjenestetilbud) Bedret tjenestekvalitet i de kommunale helse- og omsorgstjenestene Opplevd tjenestekvalitet (for innbyggere) Støtte næringsutvikling og markedsinnovasjon på velferdsteknologiområdet 1.3. Gjennomføringsprinsipper Grunnleggende prinsipper og føringer for gjennomføring av offentlige digitaliseringsprosjekter er gitt gjennom stortingsmeldingen Digital agenda 1. Disse handler i hovedsak om å redusere størrelsen og kompleksiteten i de enkelte prosjektene, samt å rette oppmerksomheten mot gevinstrealisering 1 4

87 gjennom hyppige leveranser som bidrar til tydelige nytteeffekter. Stortingsmeldingen sier at «forenkling og forbedring av offentlig sektor må skje kontinuerlig, og i små steg, ikke gjennom store prosjekter». Disse prinsippene og føringene legges til grunn som rammer for gjennomføring, som bidrag til å redusere risiko og øke nytteverdien. To av de fem hovedprinsippene fra stortingsmeldingen er spesielt relevante i denne sammenheng for valg av løsningstilnærming og gjennomføringsmodell: Prinsipp Beskrivelse Relevans for realisering av knutepunkt Tenk stort start smått Lever hyppig skap nytte hele veien Sett ambisiøse mål og tenk helhetlig. Reduser prosjektstørrelse og ambisjonsnivå i det enkelte prosjekt. Del større satsinger i mindre kompliserte prosjekter med hyppige leveranser. Slik blir risikoen lavere og gevinstene kan realiseres raskere. Ta hensyn til fremtidig forvaltning av løsningen allerede i planleggingsfasen. Sørg for hyppige leveranser underveis i prosjektet. Juster løsningen basert på tilbakemeldinger fra brukerne. Realiser gevinster både i løpet av prosjektet og i etterkant. Målbildet for et knutepunkt er en felles løsning som kan brukes av alle kommuner til støtte for innføring av VFTløsninger. Løsningen skal inngå i en helhetlig nasjonal arkitektur for e-helse, samt spille sammen med øvrige tjenester i framtidens digitaliserte kommuner. Over tid vil også spesialisthelsetjenesten kunne «koble seg på» for utveksling av data på tvers av behandlingsnivåer. Dette er et landskap hvor det pågår mange initiativer i parallell, og det er betydelig usikkerhet knyttet til flere av utviklingsområdene. Det er derfor viktig å starte i det små, i form av en innledende utviklingsfase med avgrenset omfang. Slik kan man unngå store investeringer før man får mer erfaring med hvordan løsningstilnærmingen møter behovene, og holde flest mulig veivalg åpne inntil omgivelsene blir mer tydelige. Strategien baserer seg på å realisere de høyest prioriterte funksjonene først samt å innføre og teste disse ut i samarbeid med kommunene som deltar i prosjektet. Dette gir muligheter til å gjøre løpende justeringer for å treffe behovene best mulig. Flere funksjoner legges til gradvis, steg for steg. Prioriteringen av nye funksjoner gjøres etterspørselsbasert og ut fra vurderinger av kost/nytte hver ny funksjon skal være en kostnadseffektiv måte å skape merverdi for kommunene. Det er en rekke usikkerhetsfaktorer forbundet med å etablere en nasjonal løsning innen velferdsteknologi og e-helse, som er et område i rask utvikling med en del uavklarte rammebetingelser. De viktigste områdene som vil eller kan påvirke prosjektet er: Oppfølging og videreutvikling av nasjonal e-helsestrategi og handlingsplan Digitaliseringssatsinger i kommune-norge, og da særlig pågående anskaffelser og initiativer knyttet til velferdsteknologi Prosessen rundt realisering av én innbygger én journal, Helseplattformen i Region Midt-Norge Etableringen av nasjonal arkitekturstyring for e-helse, og utviklingen av felles komponenter («felles grunnmur for digitale tjenester» 2 ) 2 Ref. e-helsetrategien, 5

88 Pågående utredninger og diskusjoner om modeller for utvikling, finansiering og forvaltning av nasjonale felleskomponenter innen e-helse Utviklingen i disse prosessene kan åpne nye muligheter for videre utvikling av knutepunktet, men de kan også medføre behov for tilpasninger, justeringer og endringer etter hvert som ulike brikker faller på plass. Hvis omfattende arbeid og større investeringer legges ned i en tidlig fase av prosjektet, øker risikoen for at slike endringer vil være tunge og kostnadskrevende å gjennomføre Mål Effektmålene for et velferdsteknologisk knutepunkt er å: - Understøtte videre utbredelse og implementering av velferdsteknologi - Sikre velfungerende samhandling i kommunale helse- og omsorgstjenester som benytter velferdsteknologi - Bidra til åpne løsninger og et velfungerende marked for velferdsteknologi Knutepunktet har også som ambisjon å ivareta informasjonssikkerhet og personvern på en bedre måte enn det som er tilfelle med dagens løsninger. Effektmålene skal nås gjennom følgende resultatmål: - Lansere et knutepunkt for minst én kommune med kobling mot minst én EPJ og minst én VFTløsning - Verifisere at et nasjonalt knutepunkt kan dekke prioriterte behov hos flere kommuner - Identifisere faktorer som skal til for å skalere knutepunktet til bruk for alle landets kommuner - Bygge opp kompetanse og en gjennomføringsmodell for tilkobling til knutepunktet som kan videreføres i en linjeorganisasjon Disse resultatmålene gjelder for en første innledende fase i realiseringen av knutepunktet, se kapittel 3. 6

89 2. REALISERINGSALTERNATIVER Det er tre hovedalternativer man kan velge for å løse behovene. Nedenfor drøftes kort disse alternativene Alternativ A: Gjenbruke og tilpasse en eksisterende, nasjonal plattform Felleskomponenter er IT-komponenter som utvikles og forvaltes på vegne av minst to sektorer, og skal forhindre at flere i samme sektor utvikler den samme funksjonaliteten. Det er syv nasjonale felleskomponenter i offentlig sektor i dag; Altinn, Digital post til innbygger, ID-porten, Kontakt - og reservasjonsregisteret, Folkeregisteret (DSF), Enhetsregisteret og Matrikkelen. Innenfor helsesektoren omtaler man også e-resept, Kjernejournal, Helsenorge.no og Grunndata som felleskomponenter. I kommunesektoren er det ambisjon om å bygge opp FIKS som en felles plattform til støtte for digitalisering av kommunale tjenester. Av de nevnte felleskomponentene er det fire plattformer som kan være aktuelle som utgangspunkt for realisering av knutepunktet: Altinn, Helsenorge.no, Nasjonal Kjernejournal og FIKS 3. Ingen av disse plattformene har i dag løsninger for kommunal integrasjon mellom velferdsteknologi og fagsystemer, men de kan være aktuelle å benytte som grunnleggende utviklingsplattformer med tilhørende utviklingsmiljø og kompetanse. Gjenbruk av et eksisterende utviklings- og forvaltningsmiljø kan redusere risiko og senke oppstartskostnader. Det funksjonelle innholdet, inkludert grensesnitt mot velferdsteknologi og fagsystemer, må uansett utvikles spesifikt for velferdsteknologi i dette alternativet. Muligheten for samspill med disse nasjonale plattformene vil selvsagt være til stede selv om et av de andre realiseringsalternativene velges. Altinn I strategidokumentet for Altinn 4 vises det til at selv om transaksjonsvolumet har økt de siste årene har det vært liten vekst i antall tjenesteeiere (les: «kunder»). Det er få kommuner som benytter Altinn. Pr juni 2017 har Oslo Kommune, Fredrikstad, Bergen og Drammen pilotavtale med Altinn. Skedsmo kommune har egen samarbeidsavtale (regulær avtale). Altinn skal ikke ha noen rolle i det å samordne Altinn for en ny tid Altinnstrategi

90 kommunenes tjenester og løsninger, og skal heller ikke utvikle tjenester for kommunene. Dette må kommunene selv håndtere 5. Med den innretningen som pekes ut for utvikling av Altinn videre, ser vi det som lite realistisk å få kommunenes behov for integrasjon av VFT-løsningskjeder inn som et prioritert utviklingsområde. Det vil sannsynligvis være en ikke ubetydelig oppstartskostnad knyttet til å tilrettelegge Altinn for en type tjenester plattformen ikke har i dag, og det er grunn til å tro at det vil ta en del tid både å få besluttet og rigget en slik løsning. Prosjektet vurderer det derfor slik at Altinn ikke er aktuell som basis for utvikling av knutepunktet. Kjernejournal Kjernejournal er en løsning som samler viktige helseopplysninger og gjør dem tilgjengelig både for innbygger og helsepersonell. Det er den første digitale løsningen for deling av pasientenes helseopplysninger på tvers av virksomheter og nivåer i helsevesenet. Alle innbyggere i Norge har fått sin kjernejournal, og alle sykehus i Norge har innført kjernejournal. Legevakter og legekontor som ennå ikke har tatt kjernejournal i bruk, innfører tjenesten fortløpende i Kjernejournalløsningen er en spesifikk løsning bygget på en integrasjonsplattform. Det er plattformen som kan vurderes til gjenbruk. Kjernejournalplattformen er ikke i dag en åpen plattform for tredjepartsutviklere. Selv om prosjektet anser kjernejournal som en viktig e-helsekomponent med berøringspunkter inn mot velferdsteknologiøkosystemet, er prosjektets vurdering at selve kjernejournalplattformen ikke er aktuell å bruke for utvikling av knutepunktet. Kjernejournal vil derimot kunne tilby funksjoner og grensesnitt som det er aktuelt for knutepunktet å knytte seg opp til. FIKS FIKS-plattformen er en samling av kommunale applikasjonstjenester som benyttes i offentlige tjenester. KS har ansvaret for FIKS-plattformen. Plattformen utvikles i tett samarbeid med medlemmene og bygger opp under deres behov for gjennomføringskraft i digitaliseringen. «Plattformen skal i hovedsak levere skybaserte applikasjonstjenester som er helhetlige og modulbaserte og i størst mulig grad sektoruavhengige.» 6 Integrasjonsplattformen består av løst koblede komponenter som støtter opp under kommunesektorens digitale tjenester. Eksempel på komponenter i FIKS er SvarUt, SvarInn, edialoger og grensesnitt mot kommunale arkiv- og fagsystemer. SvarUt brukes eksempelvis av 345 kommuner, som støtte til utsendelse av kommunale saksdokumenter: «KS FIKS Meldingformidler er en sentralisert løsning som formidler dokumenter mellom avsender og mottaker via ulike kanaler.» 7 Fellesløsninger for kommunal sektor kan gjøres tilgjengelig på FIKS-plattformen, og komponenter kan endres og skiftes ut uten omfattende endringer på kommunenes etablerte tjenester. Dagens tjenestetilbud på FIKS-plattformen er i stor grad basert på den sentrale Meldingsformidleren, og er orientert mot dokumentbasert meldingsutveksling. Dette kan i tillegg til PDF-dokumenter også være dokumenter i form av strukturerte data, som kan hentes inn til videre bruk i kommunale fagsystemer/ saksbehandlingsløsninger. Et typisk løsningsmønster vil kunne være utfylling (med forhåndsinnhentede 5 Altinnstrategi 2016, kap

91 data som det offentlige allerede har) i en digital dialog med innsending av søknad som sluttpunkt hvor søknadsdata deretter plukkes opp og behandles videre i det kommunale saksbehandlingssystemet. Bruken av Meldingsformidleren i FIKS til asynkron dokumentutveksling er på mange måter en parallell til helsesektorens utveksling av elektroniske meldinger over helsenettet. Ingen av disse løsningene dekker behovet for en mer synkront orientert datautveksling, som knutepunktet har behov for ved håndtering av alarmer i responstjenesten. Prosjektet anser ikke at FIKS per nå har en innretning som gjør det til en egnet utviklingsplattform for knutepunktet, men det vil absolutt være aktuelt å ha samspill med og benytte tjenester fra FIKS i senere faser. Prosjektet anser ikke at FIKS per nå har en innretning som gjør det til en egnet utviklingsplattform for knutepunktet, men det vil absolutt være aktuelt å ha samspill med og benytte tjenester fra FIKS i senere faser. Helsenorge.no og Helsenorge-plattformen Helsenorge.no er den offentlige helseportalen for innbyggere i Norge og eies, videreutvikles og forvaltes av Direktoratet for e-helse. Helsenorge-plattformen har utviklet seg over tid fra å være en portal til å bli en plattform. Plattformen har også komponenter som kan gjenbrukes, eksempelvis personvernkomponenten, og kommer til å ha økt fokus fremover på åpning av grensesnitt som muliggjør ekstern innovasjon. Det vil derfor være gode mulighet for synergier i arbeidet rundt åpning av grensesnitt og håndtering av et eksternt økosystem av leverandører. Et av de viktigste initiativene i denne sammenhengen er innføring av en løsning som kan eksponere grensesnitt mot Helsenorge, Kjernejournal, Grunndata, eresept og andre e-helseløsninger 8. Siden Helsenorge.no ikke inneholder en integrasjonsplattform vil det være behov for å innføre en integrasjonsplattform for å kunne realisere knutepunktet som en videreutvikling av Helsenorgeplattformen. En slik integrasjonsplattform vil da kunne benyttes både til utvikling av knutepunktet og til annen videreutvikling av Helsenorge.no. På grunn av muligheten for å gjenbruke komponenter, kunnskap og prosesser fra Helsenorgeutviklingen, ser vi en samordning av knutepunktsarbeidet med den videre utviklingen av helsenorge.no som et mulig alternativ. I totalvurderingen mellom alternativene A, B1 og B2 legger vi derfor til grunn at alternativ A er gjenbruk av Helsenorge-plattformen (med nødvendig utvidelse som omtalt over), og at knutepunktet utvikles og forvaltes sammen med Helsenorge.no. En ulempe med denne modellen er at Helsenorge.no skal dekke et svært bredt spekter av tjenester og aktører i Helse-Norge. Å legge utvikling av velferdsteknologisk knutepunkt inn som en del av Helsenorge-plattformen kan medføre mindre fokusert oppmerksomhet på og prioritering av kommunenes behov. «Konkurransen» med andre gode formål, med høy prioritet for tjenesteutvikling rettet mot innbyggere, spesialisthelsetjeneste og fastleger kan medføre at man ikke klarer å holde tritt med behov og etterspørsel på velferdsteknologiområdet. En utvidelse av Helsenorge.no-plattformen, både med nye tekniske komponenter (integrasjonsplattform) og et utvidet tjenestespekter, vil også fort gi høyere kompleksitet og eskalerende kostnader knyttet til forvaltning og videreutvikling av plattformen. 8 Denne type løsninger omtales gjerne som «API Management». 9

92 2.2. Alternativ B1: Kjøpe spesifikk pakkeløsning fra én totalleverandør Med en spesifikk pakkeløsning menes en plattform eller løsning levert av nisjeaktører med spisskompetanse på velferdsteknologi og nødvendige integrasjoner. Gjennom markedsdialogen som Oslo kommune utførte i 2016 kom det frem at ingen leverandører kunne levere all ønsket funksjonalitet i form av en «ferdig pakke», og at det derfor uansett vil måtte gjennomføres en del utviklingsarbeid. Blant de leverandørene som hadde mest ferdig utviklede løsninger var det lite fokus på å tilby åpne grensesnitt til andre leverandører som del av et åpent økosystem. Valg av en totalleverandør kan derfor være et hinder for offentlig sektors ønske om et åpent marked for velferdsteknologi, selv om også denne type løsning i prinsippet bør kunne tilpasses og tilrettelegges som et åpent økosystem for velferdsteknologi. Fordelene med en mer eller mindre «nøkkelferdig» løsning er at det kan gi raskere implementering av en del integrasjonstjenester og dermed nå markedet raskere enn en egenutviklet løsning, selv om disse funksjonene muligens ikke helt treffer kommunenes høyest prioriterte behov. Implementerings- og forvaltningskostnadene antas også å være lavere for å få grunnleggende integrasjonstjenester på plass. Dette kan igjen gi lavere risiko rundt videre utvikling og tilpasning, og gi bedre kontroll over livsløpskostnadene for knutepunktet. Ved kjøp av ferdige løsninger svekkes det offentlige eierskapet og muligheten for sterk påvirkning i utviklingen av løsningene. Som følge av dette kan det være vanskeligere å få tilpasset løsningene til endrede og nye behov, samt å få løsningen til å samspille med en helhetlig e-helsearkitektur. Valg av en pakkeløsning fra en leverandør tilpasset velferdsteknologi vil kunne redusere muligheten for fleksibel tilpasning til framtidige muligheter og rammebetingelser. Det kan gjøre det vanskeligere å gjenbruke felleskomponenter, og kan derfor bidra til å bygge siloer innenfor den overordnede e-helsearkitekturen. Velferdsteknologi er foreløpig ikke en integrert del av helsetjenesten omfanget og utbredelsen er så langt ikke stor. Samtidig er den teknologiske endringstakten høy, og digitaliseringen av samfunn og næringsliv utfordrer etablerte strukturer og aktører. Dette gjør at usikkerheten rundt valg av teknologi, aktører og fremtidige verdikjeder er relativt høy. Det samme gjelder den fremtidige etterspørselen etter integrasjonstjenester fra det nasjonale knutepunktet. Det er to prinsipielle tilnærminger som er vurdert for anskaffelse av en spesifikk pakkeløsning: - Kjøp av en løsning der leverandøren får betalt for sitt produkt og tilhørende tjenester ved etablering. I dette alternativet tar kjøper (her: Staten) hovedrisikoen. - Kjøp av en tjeneste der leverandøren ikke får betalt for etableringen, men for sine løpende tjenester (f.eks fra tilknyttede kommuner eller leverandører). I dette alternativet tar leverandøren hovedrisikoen. Som nevnt over er det betydelig usikkerhet rundt teknologiutvikling og etterspørsel, noe som gjør at usikkerheten tilknyttet en anskaffelse for begge tilnærminger vurderes som for høy Alternativ B2: Utvikle stegvis basert på behov En alternativ tilnærming er å benytte en åpen, skybasert integrasjonsplattform som grunnlag for å utvikle enkle behovsrettede integrasjonstjenester. En slik plattform kan typisk leveres av store, 10

93 internasjonale aktører som tilbyr åpne og skalerbare løsninger på tvers av flere industrier. I en startfase vil velferdsteknologiske integrasjonsløsninger bli utviklet på denne plattformen som del av prosjektet, med gjenbruk av noen eksisterende komponenter fra for eksempel helsenorge.no. I dette alternativet vektlegges det å utvikle inkrementelt og bare ha fokus på de aller viktigste integrasjonsfunksjonene i tidlig fase. Denne type plattform kan tilby stor fleksibilitet og være basis for flere anskaffelser med ulike leverandører av spesifikke moduler, samt egenutviklede integrasjonsløsninger med mulighet for ulike kommunale tilpasninger (konfigurasjoner) på toppen av plattformen. Dermed kan løsningen utvikles stegvis i takt med behov og bruksvolum. Et grunnleggende premiss er at forskjellige leverandører kan bidra og levere løsninger på denne plattformen som del av den langsiktige utviklingen av økosystemet dette forutsetter da at det benyttes en plattform som mange aktører i markedet har kompetanse på. I tillegg til muligheten for en inkrementell innføring av løsninger for det velferdsteknologiske knutepunktet, antas en slik tilnærming å gjøre det enklere å bruke andre offentlige felleskomponenter og gjøre tilpasninger til nasjonale arkitekturføringer som er under utarbeidelse. Eksempler på gjenbruk av tjenester fra felleskomponenter kan være: Benytte personvernkomponenten og kommunale grensesnitt som er utviklet til Helsenorge.no. Benytte Kjernejournal som lagringskomponent for egenbehandlingsplaner for medisinsk avstandsoppfølging, og videreformidling av medisinopplysninger. Benytte Altinns samtykketjeneste for å «ta med seg» egne velferdsteknologidata som grunnlag for ulike typer elektroniske søknader o.l. Benytte tjenester fra FIKS for samspill med det øvrige kommunale tjenestetilbudet, samt hvis det skulle være aktuelt å sende ut brev til bruker eller andre berørte aktører. Ulempen med å ta mer grep om utviklingsarbeidet selv er at det offentlige tar på seg et ansvar som kan generere langsiktige utviklings-, drifts- og forvaltningskostnader som kan være vanskelig å forhåndsberegne. Det kan bli utfordrende for de aktuelle aktørene å håndtere dette på sikt. Men selv om det legges opp til offentlig styring av utviklingsarbeid og forvaltning i en startfase, vil det etter hvert være mulig å tjenesteutsette utvikling, forvaltning og/eller drift til en eller flere leverandører i markedet. Dette valget gir derfor flere opsjoner for fremtidig utvikling og låser ikke det offentlige til en spesifikk leverandørmodell. Ulempen med å ta mer grep om utviklingsarbeidet selv er at det offentlige tar på seg et ansvar som kan generere langsiktige utviklings-, drifts- og forvaltningskostnader som kan være vanskelig å forhåndsberegne. Det kan bli utfordrende for de aktuelle aktørene å håndtere dette på sikt. Men selv om det legges opp til offentlig styring av utviklingsarbeid og forvaltning i en startfase, vil det etter hvert være mulig å tjenesteutsette utvikling, forvaltning og/eller drift til en eller flere leverandører i markedet. Dette valget gir derfor flere opsjoner for fremtidig utvikling og låser ikke det offentlige til en spesifikk leverandørmodell Oppsummering og anbefaling Alternativ A (gjenbruke og tilpasse en eksisterende, nasjonal plattform) har ikke god nok dekning ift behovet, samt at forholdene for rask og enkel realisering ikke er til stede i tilstrekkelig grad. 11

94 Alternativ B1 (kjøpe spesifikk pakkeløsning fra én totalleverandør) er et godt alternativ både når det gjeder rask realisering og kostnadsbildet for implementering og forvaltning. Usikkerheten tilknyttet teknologiutvikling og etterspørsel vurderes imidlertid som for høy til at dette alternativet kan forsvares. Det er dermed alternativ B2 (utvikle stegvis basert på behov) som er det anbefalte alternativet. Alternativet ivaretar behovet for lave investeringer, lav kompleksitet og rask oppstart best. Det aktuelle tekniske løsningsalternativet er verifisert gjennom Oslo kommunes PoC, hvor de i samarbeid mellom med Norsk Helsenett har utviklet en knutepunkt-tjeneste med utgangspunkt i eksisterende infrastruktur og standard skybaserte tjenester. Alternativet ivaretar også best Digital agendas anbefaling om forenkling gjennom kontinuerlig forbedring i små steg. 3. GJENNOMFØRING 3.1. Gjennomføringsmodell Anbefalt gjennomføringsmodell baserer seg på prinsippene «Tenk stort start smått» og «Lever hyppig skap nytte hele veien». Det fokuseres på inkrementell innføring av høyt prioritert funksjonalitet styrt av reelle behov i kommunene. Det gir mulighet til å kontrollere ambisjonsnivå og funksjonalitetsomfang, og tilpasse det etter den faktiske etterspørselen fra kommunene. Dermed unngås risiko for å kjøpe en overdimensjonert løsning med mye funksjonalitet som ikke tas i bruk, og man unngår at fremtidige forvaltningskostnader blir høyere enn nødvendig i forhold til faktisk bruk av løsningen. Modellen baseres på en innledende utviklings- og etableringsfase heretter kalt «fase 1» eller «startfasen» der enkel grunnleggende funksjonalitet i knutepunktet etableres. Dette vil skje i tett samarbeid med utvalgte kommuneprosjekter som til sammen representerer et bredt spekter av velferdsteknologileverandører og EPJ-systemer. Figuren under illustrerer foreslått faseinndeling, hvor fase 1 avsluttes i et beslutningspunkt for videre veivalg. Figuren viser også hvordan det vil være gjensidig påvirkning mellom prosjektet og sentrale aktiviteter / utviklingstrekk i omgivelsene. 12

95 Det anbefalte realiseringsalternativet (B2) ivaretar rask oppstart og stegvis utvikling av knutepunktet i fase 1, men det er viktig å understreke at den valgte tilnærmingen for fase 1 ikke gir føringer for gjennomføringen av de etterfølgende fasene. Vurderingen av modell og tilnærming for videre gjennomføring vil bli utført som en del av underlaget for beslutning av veien videre høsten Rask oppstart For å støtte videre utbredelse av velferdsteknologi i kommunene er det viktig at fase 1 kan påbegynnes raskt. Det er spesielt to sentrale valg som gjør dette mulig: Norsk Helsenetts avtale for bruk av skytjenester kan benyttes. Det vil med andre ord ikke være behov for å gjennomføre anskaffelse av en skybasert integrasjonsplattform i fase 1. Løsningskonsept og erfaringer fra Oslo kommunes proof-of-concept danner grunnlaget for de første funksjonene som skal utvikles. Oslo kommune har i samarbeid med Norsk Helsenett (NHN) utviklet en proof-of-concept (PoC) som viser hvilke muligheter som ligger i å benytte eksisterende infrastruktur i helsenettet og standard skytjenester for å knytte sammen velferdsteknologi med et kommunalt EPJ-system. PoCen benytter: Skytjenester fra standard plattform 9 for mottak, omformatering, logging og videreformidling av data fra et velferdsteknologisk forsystem Helsenettet som sikker infrastruktur for tilknytning mellom skytjeneste og kommunal EPJ Eksisterende teknisk grensesnitt (API) mot Oslo kommunes EPJ for pleie- og omsorgstjenesten Løsningen er basert på standardkomponenter i den skybaserte integrasjonsplattformen, som er tilrettelagt for å være skalerbar. Tilknytning til helsenettet er basert på veileder fra Norsk Helsenett for tilknytning og sikring av skytjenester, og er gjort i samarbeid med NHN. PoCen viser at knutepunktet kan realiseres ved hjelp av denne type skyteknologi en standard verktøykasse med komponenter som kan skalere både i funksjonalitet, i antall forsystemer og i antall EPJer. For mer informasjon om PoC, henvises det til beskrivelse i eget dokument (se oversikt over relevante dokumenter i kapittel 5) Stegvis utvikling bygge erfaring, lære og evaluere Gjennom fase 1 opparbeides erfaring med utvikling, implementering og forvaltning av knutepunktet, og ikke minst med håndtering av brukere (kommuner) og løsningspartnere (velferdsteknologi- og EPJleverandører). Erfaringene vil gi et sikrere grunnlag for å vurdere framtidig etterspørsel (bruksvolum og funksjonalitetsbehov), samt for å vurdere egnede løsningstilnærminger for veien videre. Fase 1 vil også gi erfaringsbasert kunnskap som kan være nyttige innspill til andre sentrale aktiviteter slik som helhetlig digitaliseringsarbeid i kommunene, utviklingen av nasjonal e-helsearkitektur samt modeller for finansiering og forvaltning av nasjonale felleskomponenter. Deltakende kommuner i fase 1 kan sammenliknes med såkalte beta-brukere, som får anledning til å prøve ut ny funksjonalitet tidligere enn andre, og mulighet til å påvirke utvikling av tjenesten fram til lansering av ferdig produkt. Dette innebærer en forpliktelse til aktiv deltakelse, en viss toleranse for feil 9 Den aktuelle plattformen er av typen som gjerne omtales som en skybasert integrasjonsplattform (ipaas, Integration Platform as a Service). For mer informasjon om denne type løsning, henvises det til arkitekturdokumentet (se oversikt over relevante dokumenter i kapittel 5). 13

96 og mangler som oppdages underveis, men gir til gjengjeld betydelig innflytelse i utformingen av løsningene. Fase 1 planlegges å starte høsten Høsten 2018 gjøres en evaluering av erfaringene så langt, av rammer som blir gitt gjennom andre sentrale aktiviteter og modenheten til nasjonal arkitektur og felleskomponenter. Basert på dette utarbeides en revidert realiseringsstrategi og videre gjennomføringsplan for knutepunktet. Evalueringen som gjøres høsten 2018 kan eksempelvis resultere i følgende alternative veivalg: 1. Vi utvider tidsrammen for fase 1 og fortsetter en stund til med samme tilnærming, fordi erfaringer og rammer fra annet arbeid fortsatt er mangelfulle. 2. Vi tilpasser videre realisering av knutepunktet til oppdaterte prognoser for volum- og behovsutvikling, samt til nye rammer fra andre sentrale aktiviteter. 3. Vi beslutter og gjennomfører en styrt avvikling av knutepunktet fordi interessen/behovet ikke er stort nok, estimerte kostnader knyttet til utvikling, drift og forvaltning er større enn betalingsviljen for bruk og/eller markedet har løst behovet på en annen måte. 4. Man anskaffer en pakkeløsning (som omtalt i kapittel 2.2) da erfaringene fra fase 1 viser at løsningen ikke er tilpasset behovet 3.2. Gjennomføringsplan fase 1 Fase 1 gjennomføres i regi av det nasjonale velferdsteknologiprogrammet i samarbeid med Oslo kommune og Norsk Helsenett. Flere kommuner tas gradvis med i utviklingsløpet. Det vil bli lagt opp til at ca. fem kommuneprosjekter bidrar inn i fase 1. Et kommuneprosjekt kan gjerne inneholde flere kommuner som samarbeider om felles VFT-løsninger. Utvelgelse av kommuneprosjekter vil gjøres av VFT-programmet basert på følgende kriterier: Kommunen har inngått avtale med VFT-leverandør og er klare for utrulling til sine innbyggere Kommunen har identifisert klare behov for datautveksling med fagsystem/epj Kommunen kan avsette ressurser til å delta i samarbeid med VFT-prosjektet iht prosessen som er beskrevet i dette kapittelet Kommunen er villig til å finansiere tilpasninger hos sine leverandører hvis ikke de nødvendige grensesnitt allerede eksisterer Det samlede spekter av valgte kommuneprosjekter skal representere et bredest mulig spekter av VFT-leverandører og EPJ-leverandører. Gjennomføringen av kommuneprosjektene vil som nevnt gjøres i regi av det nasjonale velferdsteknologiprogrammet, og være bemannet med faste team for å ivareta gjenbruk og sikre synergier. Programmet vil sørge for styring og kontroll av arbeidet samt strategiske forankring mot andre relevante aktiviteter som nasjonal finansierings- og forvaltingsmodell. Tentativt vil følgende hovedaktiviteter følge hvert kommuneprosjekt: Behov Behovsaktiviteten vil identifisere og prioritere reelle behov for dataflyt mellom VFT-løsning og EPJ. Aktiviteten vil også inkludere juridiske og tjenestlige vurderinger knyttet til dokumentasjonsplikt. Sikkerhet og risikovurdering 14

97 Omfatter ROS-analyser knyttet til informasjonssikkerhet basert på Normen, og vil bli gjennomført med deltakelse fra aktuell kommune, Direktoratet for e-helse og representanter fra leverandør og NHN. Videreutvikling av referansearkitektur og spesifikasjon av grensesnitt og funksjonalitet inngår i arbeidet. Et sentralt punkt er også muligheter for standardisering og gjenbruk på tvers av kommuner. Utvikling Basert på spesifikasjoner fra ovennevnte aktiviteter utvikles og testet funksjonalitet og grensesnitt. Drift og forvaltning Når spesifisert funksjonalitet er verifisert i tråd med definerte krav settes tjenesten i drift og forvaltes videre. Utover løpende drift inngår aktiviteter som feilretting, forebyggende vedlikehold, endringshåndtering, brukerservice med mer. Erfaringer knyttet til utvikling, drift og forvaltning av nye tjenester i knutepunktet skal jevnlig rapporteres fra kommunen og deres leverandører. Erfaringene skal bl.a. gi grunnlag for å diskutere praktiske betalingsmodeller for videre bruk av knutepunktet etter fase 1. I figuren nedenfor er det listet opp noen punkter som viser mer i detalj hva kommunen må bidra med og hva kommunen kan forvente å få igjen Prioritert funksjonalitet i fase 1 I behovsbeskrivelsen i vedlegg 1 er det utarbeidet en bruttoliste av funksjoner for knutepunktet som er aktuelle å realisere for å imøtekomme behovene beskrevet i kapittel 1.2. Ut fra dette er det gjort en vurdering av hvilke funksjoner som bør implementeres først. Denne prioriteringen er blitt gjort ut fra følgende hovedkriterier: Etterspørsel i hvilken grad vil en gitt funksjon bidra til at det nasjonale knutepunktet tas i bruk av kommunene? Hva er estimert volum for bruk? Vil næringslivet ha insentiver for å utvikle nye tjenester som bruker knutepunktet? Kompleksitet hvor vanskelig (teknisk, juridisk mv) er det å realisere en gitt funksjon? 15

98 Gevinstpotensial hvilke gevinster vil utløses dersom vi realiserer en gitt funksjon? Får vi økt kvalitet i tjenesten for innbyggere? Forenkler vi hverdagen til helsepersonell? Sparer vi tid? Følgende funksjoner er foreløpig vurdert til å være viktigst, og er derfor prioritert som innhold i fase 1: Formidle hendelsesdata fra forsystem Automatisk journalføring av hendelser direkte fra forsystem til EPJ Automatisk journalføring av hendelser fra responsløsning til EPJ Formidle varsler/alarmer fra forsystem til responsløsning Overføre bruker- og tjenesteinformasjon fra EPJ til responsløsning Hente tjenesteinformasjon fra EPJ som støtte til vurdering av handlingsalternativer Hente helseinformasjon fra EPJ som støtte til medisinsk vurdering Formidle informasjon til hjemmetjenesten Opprette oppdrag i EPJ Denne listen vil danne utgangspunktet for arbeidet med behov i kommuneprosjektene. Tilbakemeldinger fra kommuneprosjektene kan gi justeringer i denne listen underveis Tidsplan fase 1 Realiseringen i fase 1 vil jobbe etter følgende tidsplan: Tidsplanene til de fem kommuneprosjektene er her kun vist illustrativt. Endelige tider for oppstart og idriftsettelse må avtales i hvert enkelt prosjekt. Mobilisering: Mobilisering er arbeidet med å bemanne teamene og planlegge arbeidet i hver aktivitet. Arbeidet med å identifisere aktuelle kandidater og avtale med andre kommuneprosjekter starter her. Strategi: Håndtere overordnede strategiske valg i prosjektet basert på dialog med andre strategiske aktiviteter i Direktoratet for e-helse, Helsedirektoratet, KS og kommunene. Drive 16

99 prosessen for evaluering og justering av strategien for videre realisering av knutepunktet høsten Arkitektur og standardisering: Videreutvikle nasjonal referansearkitektur for velferdsteknologi og nasjonale spesifikasjoner/standarer for grensesnitt (APIer). Sørge for at dette arbeidet er koordinert med andre relevante aktiviteter innen standardisering og arkitektur i Direktoratet for e-helse, og med utviklingen i KS og kommuneprosjektene. Kommuneprosjektene: Ved beslutning om oppstart av fase 1 vil kommuneprosjekt 1 (Oslo) starte arbeidet med å bygge basisfunksjonalitet på knutepunktet basert på erfaringene fra Oslo kommunes PoC. Planen er at en integrasjon mellom Oslo kommunes medisindispenserløsning levert av Dignio og Oslo kommunes EPJ (Gerica fra Tieto) gjennom knutepunktet skal idriftssettes senhøstes Det vil videre bli arbeidet med realisering av behov identifisert i påfølgende kommuneprosjekter i henhold til hovedprinsippene om gjenbruk. Det vil si det skal legges opp til å gjenbruke mest mulig av analyser og implementeringer fra forutgående kommuneprosjekter, og alle funksjoner som utvikles skal legges til rette for gjenbruk av andre kommuneprosjekter. Utvikle drifts- og forvaltningsfunksjonen: Her inngår løpende aktiviteter knyttet til utvikling (koding) av grensesnitt og funksjonalitet i knutepunktet, idriftsettelse av løsningene i kommuneprosjektene, løpende drift og de sentrale forvaltningsprosesser, for eksempel avtaleforvaltning, feilhåndtering og support. Utvikling (koding) av grensesnitt og funksjonalitet i knutepunktet, etter oppdrag fra teamet «Arkitektur og standardisering», vil kreve innsats (kompetanse og ressurser) både fra divisjon Utvikling i Direktoratet for e-helse og fra NHN i tillegg til nødvendige bidrag fra kommunene og deres leverandører. Forvaltningsmodell skal defineres og etableres i denne fasen. Dette betyr å definere hvem gjør hva og hvem har ansvar for hva gjennom hele verdikjeden for hele aktørbildet. Videre må kontrakter etableres, tjenestebeskrivelser og prosesser utvikles og beskrives med mer. Aktiviteten skal blant annet besvare: o Hvilke kontrakter må etableres mellom hvilke parter? o Hvordan skal kunder/brukere av knutepunktet håndteres ift brukerstøtte, feilhåndtering mv? Hvordan ser prosessene ut? Hvem gjør dette? o Hvordan skal bestillinger og tilhørende leveranser håndteres? o Hvordan håndtere økonomi for drift og videreutvikling av knutepunktet? Kan det f.eks. etableres en modell for bruksbasert betaling (per tjeneste og/eller bruksvolum)? o Hvordan følge opp inngåtte avtaler og hvem gjør dette? Gjennom fase 1 opparbeides erfaring som bidrar til utvikling av drifts- og forvaltningsfunksjonen. Denne erfaringen vil også gi grunnlag for en bedre fundert estimering av løpende drift- og forvaltningskost, og behovet for kompetanse og kapasitet i forvaltningsorganisasjonen, for å håndtere en videre oppskalering av knutepunktet med flere tjenester og flere brukere (kommuner) Finansiering av fase 1 Dette kapittelet omhandler kun finansiering av fase 1. Etter fase 1 legges det opp til at knutepunktet finansieres i henhold til modeller som etter hvert vil benyttes på andre felles e-helsekomponenter. En form for samfinansiering vil være aktuell modell. Mulige modeller for samfinansiering vil bli vurdert basert på erfaringer og dialog med kommuneprosjektene i fase 1, samt i tråd med det som skjer ift finansieringsmodeller for nasjonale e-helsetjenester i regi av Direktoratet for e-helse. Kommunene som 17

100 er med i fase 1 vil kunne bruke knutepunktet vederlagsfritt ut fase 1. Når fase 1 avsluttes (tidligst i årsskiftet 2018/2019) så vil også disse kommunene bli belastet med vederlag basert på valgt modell. Fase 1 gjennomføres og finansieres som et prosjekt i det nasjonale VFT-programmet med følgende prinsipper: Ressurser fra direktoratene (e-helse og Helsedirektoratet) og teknisk utvikling finansieres gjennom det nasjonale VFT-programmet Ressurser fra involverte kommuner finansieres av kommunene selv Ressurser fra NHN finansieres av NHN 3.6. Kritiske suksessfaktorer Kritiske suksessfaktorer for at et nasjonalt knutepunkt skal tas i bruk er definert som: Tilslutning fra kommuner at mange kommuner opplever at dette imøtekommer deres behov, og dermed ønsker å benytte løsningen At vi får etablert nødvendig integrasjon med kommunale EPJ-systemer Tilslutning fra leverandører av velferdsteknologiløsninger at mange ønsker å kople seg til løsningen At løsningen har tilstrekkelig fleksibilitet og endringsevne, slik at den kan videreutvikles i takt med utviklingen på velferdsteknologiområdet og kommunenes behov for støtte til tjenesteutvikling At løsningen oppleves som pålitelig og sikker At det blir etablert en kompetent og skalerbar forvaltningsorganisasjon som kan håndtere forholdet til kundene/kommunene og leverandørene profesjonelt og effektivt At det etableres en betalingsmodell som føles rettferdig i forhold til kommunens størrelse og at den ikke bremser viljen til å innføre nye tjenester med nye teknologier i kommunen At løsningen kan støtte seg på og samspille med helhetlige nasjonale arkitekturer for e-helse og helhetlige digitaliseringsstrategier i kommuner, utover helsesektorielle behov. 4. RISIKO For at valgt gjennomføringsmodell skal lykkes er vi avhengig av raskt å kunne opparbeide erfaring gjennom fase 1. Gjennomføringstid er derfor den mest kritiske parameteren i tillegg til sikkerhet. Det er også viktig at det blir utviklet og satt i drift et visst volum (antall tjenester/integrasjoner og antall brukere/kommuner) for at vi skal få nok erfaringsdata. For påfølgende faser, hvor fokus vil være på økt bruksvolum, er finansiering en av de største risikoene. Betalingsviljen må være stor nok til at den dekker kostnadene knyttet til videreutvikling, drift og forvaltning. I tabellen under er det listet opp potensielle risikopunkter knyttet til fase 1. Risikopunktene er vurdert ut fra sannsynlighet for at risikoen inntreffer og konsekvensen det vil ha for måloppnåelse dersom risikoen inntreffer. 18

101 Nr Risikopunkt 1 Liten interesse og etterspørsel fra kommunene 2 Det viser seg vanskelig eller tar lang tid å etablere integrasjon med kommunale EPJ-systemer 3 Liten interesse fra leverandører av velferdsteknologi få vil kople seg til knutepunktet 4 Valgt løsningstilnærming viser seg lite fleksibel, og blir etter hvert vanskelig å videreutvikle og tilpasse i takt med kommunenes prioriterte (og mulig varierte) løsningsbehov 5 Knutepunktet oppfattes ikke å ivareta krav til informasjonssikkerhet i tilstrekkelig grad 6 Mangelfull forankring hos og forpliktelse fra deltakende aktører 7 Klarer ikke å styre skalering av forvaltningsorganisasjon 8 Knutepunktløsningen som utvikles i fase 1 viser seg vanskelig å tilpasse til samspill med helhetlige nasjonale arkitekturer for e-helse og helhetlige digitaliseringsstrategier i kommuner, utover helsesektorielle behov 5. UNDERLIGGENDE DOKUMENTER Nedenfor er relevante underlagsdokumenter angitt. Disse er å anse som arbeidsdokumenter som vil oppdateres løpende. Nr Tematikk 1 Behovsbeskrivelse og tilhørende brukerhistorier 2 Arkitektur og standardisering 3 Proof-of-Concept (POC) for evik 19