Status tekniske løsninger Medisinske kvalitetsregistre 8.6.2010 Per Olav Skjesol Avdelingsleder

Målsetting for 2010 Etablering av MRS 3.0 plattform Løsning for felles drift i helsenettet Ny sikkerhetsløsning internt i løsningen Følge kravene fra NIKT i henhold til tjenesteorientert arkitektur Raskere utvikling av enkelt registre Etablering av følgende registre på den nye plattformen Intensiv Diabetes Leppe / Kjeve / Gane Kols Hjerteinnfarktregister og Hjerneslagregister flyttes over på nytt plattform Oppstart av prosjekter for 4 - 6 nye registre MS – register Kosrbåndregister CP Barnediabetes Etablering av prosess for smidig utvikling av registre inklusive noder Etablering av drift og forvaltningsorganisasjon knyttet til IKT - løsning

Konsept for ny teknisk løsning Løsningen skal gjøre det raskere å utvikle nye registre være i tråd med krav EPJ – systemer generelt både nåværende og trolig nye forskrifter knyttet (vurder dette) kunne driftes fra et sted slik at man ikke er avhengig av lokal driftsorganisasjon være tilgjengelig via Norsk Helsenett integrasjon mot folkeregister mer robust i forhold til endringer og vedlikehold Integrasjon mot portalen i helseregister.no bl.a felles pålogging

Sentral fagapplikasjon Sykehus 1 Databehandler for nasjonalt helseregister og for behandlingsrettet register for sykehusene EPJ EPJ løsninger (Dips/Doculive) Nasjonalt Helseregister Fastlegen Sykehus / HF n HF 1 Fagapplikasjon (Hjerteinfarkt) Fastlegen

Nodefunksjon Målsetting å opprette en nodefunksjon pr. region Beskrivelse av den tekniske delen av nodefunksjonen er under utarbeidelse. Nodefunksjonene gjennomgår opplæring hos Hemit og samarbeider tett med Hemit i forhold til utvikling av nye registre Nodefunksjonen kan også brukes til å utvikle kvalitetsregistre som ikke er nasjonale. Før utvikling starter må dette være avklart med Hemit

Utviklingsprosess Hemit utvikler basisplattform Før utviklingsprosess kan starte må registeret være godkjent som nasjonalt register. Node funksjon samarbeider med kvalitetsregistermiljø om definisjon av kliniske variable og krav til disse Node funksjon utvikler utkast til løsning (20 – 80 % av utviklingsjobben) Hemit kvalitetssikrer og eventuelt utvikler i samarbeid med node. Hemit utvikler eventuelle nye mekanismer i standardløsningen som er påkrevd for et enkelt register Hemit ferdigstiller register, tester og får dette installert hos IT - driftsleverandør Prosessen styres av en prosjektleder fra Hemit og en fra registermiljøet. Der hvor det er hensiktsmessig etableres det felles styringsgruppe for å følge opp gjennomføringen av utviklingsprosessen til registeret Utviklingen skal foregå tett på registermiljøet

Utfordringer i utviklingsarbeidet Organisering av arbeidet – mange aktører Lang avklaringstid rundt definisjoner av kliniske variable – vanskelig ”å låse løsninger” Etablering av velfungerende node funksjoner og prosesser rundt utvikling Felles definisjoner av kliniske variable på tvers av registre Etablering av en sentral løsning for kildekode for alle registre for å sikre mest mulig gjenbruk ved utvikling av nye registre. Tilstrekkelig med ressurser

Videre planer Etablering av ny sikkerhetsløsning som gjør det mulig å integrere sikkerheten med eksisterende sikkerhetsløsninger i helseforetakene (Singel Sign On) Etablering av pseudonymiseringsløsning Strukturering av data gjennom bruk av arketyper og standard kodeverk Mer effektiv registerutvikling og høyere kapasitet Etablering av forvaltningsavtaler for feilretting og videreutvikling Etablering av driftsavtaler for teknisk drift av løsningen Integrasjon med EPJ Etablering av rapporteringsmuligheter Avklaring av framtidig driftsleverandør

Prosjektorganisering Styring Referansegr AD-møte Prosjekt Sekretæriat Styringsgruppen Arbeids gruppe Deltagere NIKT Datatilsynet Andre Felles tekniske Løsninger (Hemit) SKDE / Hemit Servicemiljø Sekretæriat RHF’er NHN Prosjektstyringsgrupper for utvikling av første versjon tekn løsning Utvikling av MRS 3.0 plattform for alle register Integrasjon av registerplattform med EPJ Etablering av felles teknisk IT drift Nivå 1 Utvikling av første versjon teknisk løsning for enkelt- registre Etablering av felles teknisk IT drift Nivå 2 Node SKDE Node SKDE Hemit Node SKDE Register

Bruk av arketyper og kodeverk Arketyper gir en struktur på lagring av informasjonen basert på en internasjonal standard Sverige har jobbet en del med å ta i bruk arketyper i kvalitetsregister og mye av dette kan trolig overføres til Norge Kodeverk er med på å definere ulike parametre i arketypen Bruk av kodeverk fører til standardisering av det enkelte informasjonselement Både bruk av arketyper og kodeverk vil gjøre det enklere å sammenligne data på tvers av registre, men også på tvers av nasjoner. For å jobbe videre med dette trenger med medisinskfaglig personell og et standardiseringsorgan som jobber aktivt med dette.

Oppsumering Nå finnes det en teknisk plattform som det kan bygges nye registre på Utviklingen tar tid og det er viktig å holde fokus på mål både for det enkelt registeret og felles løsningen Utviklingen kan ikke gå raskere enn avklaringer rundt forskrifter og lovverk Regionene må få på plass noderessurser som bringer utviklingen nærmere det enkelte register

Skjemabasert innregistrering Sykehus 1..n Databehandler for Nasjonalt helseregister EPJ EPJ løsninger (Dips/Doculive) Nasjonalt Helseregister Melding Skjemabasert innregistrerings- løsning

Nasjonalt ??? for hele landet Sentral databehandler for hele helsevesenet Sykehus 1 Nasjonalt ??? for hele landet Nasjonal EPJ Sykehus 1 EPJ løsning Fastlegen Kjernejournal Fastlegen Nasjonale behandlingsrettede helseregistre Fastlegen . Sykehus n Sykehus 1 Fagapplikasjon (Hjerteinfarkt)

Datafangst fra eksisterende kilder Sykehus 1..n Databehandler for Nasjonalt helseregister EPJ PAS EPJ løsninger (Dips/Doculive) Nasjonalt Helseregister Melding

Pseudonymt nasjonalt helseregister Sykehus 1..n TPF Databehandler for Nasjonalt helseregister Nasjonalt pseudonymt helseregister Bytte ut personnummer med pseudonym Identifiserbar Melding Pseudonymisert melding

Personidentifiserbart nasjonalt helseregister Databehandler for Nasjonalt helseregister Sykehus 1..n Nasjonalt personidentifiserbart helseregister Identifiserbar Melding

Pasienten registrerer egne data Databehandler for Nasjonalt helseregister Nasjonalt Helseregister Webbasert spørreskjema Spørre-skjema fra helse-register

Databehandler for Nasjonalt helseregister Sykehus Databehandler for Nasjonalt helseregister Mtp begrepsapparat Pasientjournal EPJ EPJ løsninger (Dips/Doculive) Fagapplikasjon (Fødejournal) Nasjonalt helseregister Fagapplikasjon (Hjerteinfarkt) Melding …. Skjemabasert innregistrerings- løsning

(personidentifisert) Forsker Servicemiljø inklusiv Databehandler (e) for Nasjonale helseregister Kobling Nasjonalt Helseregister (pseudonymisert) Forskningsprosjekt Nasjonalt Helseregister (personidentifisert) Kobling (tredjepart) Kreftregister Koblede data

Fellesnevnere Sikker pasientidentifisering inklusiv nødnummer Felles tilgangskontrollmekanismer og loggemekanismer Felles innsamlingsmekanismer Håndtering av integrasjon mot EPJ Like parameterdefinisjoner – arketyper Enhetlige brukergrensesnitt – oppfattes som en del av virksomhetens EPJ Automatisk vurdering / validering av data opp mot den sentrale delen av registret

Problemstillinger knyttet til et nytt register som har betydning for teknisk løsning Er det mange brukere som skal registrere – volum Hvem registrerer dataene – intresentene – andre I hvor stor grad finnes dataen i dagens EPJ Er det forskjellige aktører (flere sykehus, flere nivå etc) Er det behov for å registrere lokale tillegg Samtykke eller ikke Personidentifiserbar eller ikke Er det et behandlingsregister – delvis eller ikke i det hele tatt Hva er det som identifiserer de tilfellene som skal registreres Tilleggsinformasjon fra pasient

Hva skal arkitektur gi kunden / bruker (1) 25 Imøtegå viktige utfordringer i dagens IKT-løsninger Viktig informasjon om pasienten er vanskelig tilgjengelig. Samme informasjon må vedlikeholdes i flere systemer, noe som kan gi dårlig kvalitet på informasjonen Samme begrep brukes forskjellig i ulike fagsystemer. Samspill mellom systemer og sammenstilling av informasjon er utfordrende. Omfattende og komplekse fagsystem- samme funksjonalitet i flere systemer Tilgang til systemene krever gjentatte på- og avlogginger IKT-systemene oppleves ofte begrensende for evnen til videreutvikling av virksomheten

Hva skal arkitektur gi kunden / bruker Løsningsprinsipper (arkitekturen oppsummert) 26 Sammenheng i pasientforløpet Støtte for arbeidsprosesser i endring Helhetlig arbeidsflate Felles begreper Deling av informasjon og funksjonalitet

Hva skal arkitektur gi kunden (3) Idag Fremtidig

Arkitektur på flere nivå Nasjonale tverrsektorielle føringer og internasjonale forpliktelser – > Felles arkitekturprinsipper for offentlig sektor (Difi) (2009) Sektorspesifikke spesialiseringer > Tjenesteorientert arkitektur for spesialisthelsetjenesten (2008) Regional arkitektur basert på virksomhetskrav > HMNs arkitektur (2004)

Arkitekturprinsipper 04/04/2017 Arkitekturprinsipper Helhetstenking heller enn suboptimalisering Interoperabilitet Forsvarlig tilgang til informasjon Endringsevne og fleksibilitet Leverandøruavhengighet Gjenbruk av informasjon gjennom tjenester Kontrollere teknologivariasjoner Kontrollere funksjonell redundans Horisontalt og vertikal konsolidering Modne standarder og teknologier I hht FAOS: områdeprinsipper for helse (på samme måte som justis har egne) FAOS prinsipper: Tjenesteorientering (IKT-tjeneste) Interoperabilitet Tilgjengelighet Sikkerhet Åpenhet Fleksibilitet Skalerbarhet Enhetlig brukergrenesesnitt Andre viktige arkitekturprinsipper: Pålitelighet, skalerbarhet og robusthet Funksjonelt drevet endringsprosess Effektiv endringshåndtering Horisontal kontra vertikal Horisontal er prosess og vertikal er fellestjenester 29

De forskjellige deler av arkitektur 04/04/2017 De forskjellige deler av arkitektur Modellere virksomhetsprosesser Arbeidsflate Arbeidsflate Arbeidsflate Identifisere tjenester/fellestjenester T T T T T Arbeidsprosesser og orkestrering Arbeidsprosesser og orkestrering Funk Funk Funk Funk Funk Arbeidsprosesser og orkestrering Definere informasjon Tjenestebuss Tilgjengeliggjøre gjennom arbeidsflate og tjenestebuss Tjenester Tjenester T T T T T T T T T Applikasjon Applikasjon Funk Funk Funk Funk Funk Funk Funk Funk Funk 30

Komponering av prosesser Prosesser er utgangspunkt for design av tjenester og systemer Tjenester konsumeres av prosesser i en flyt Innenfor og på tvers av organisatoriske enheter Prosesser endres ofte Tjenester kommer til og erstattes Prosessene utvides/endres Gir endringsevne

Fellestjenester på forskjellig nivå 04/04/2017 Fellestjenester på forskjellig nivå Nasjonale Eks: Kjernejournal, Adresseregisteret, FRESH, pasient identifikasjon, felles tilgangsstyring (autentisering) felles tilgang til folkeregister og andre nasjonale registrer Regionale Eks: Felles tilgangsstyring (autentisering) for regionen Foretak Eks: Mottak/utskriving av pasienter Dette gir reduserte kostnader, konsistente data,….. Men stiller nye krav til driftsmiljø og rutiner 32

Informasjonsharmonisering og standardisering 04/04/2017 Informasjonsharmonisering og standardisering Vi vil trolig få flere IT – systemer enn det vi har i dag fordi det vil komme løsninger som er spesialisert på enkeltområder for å dekke enkelttjenester. Disse må kunne samhandle med resterende portefølje Derfor Felles nasjonal informasjonsmodell for å ha en felles forståelse av struktur og sammenheng Benytte oss av HL7 versjon 3 som standard for deling og utveksling av informasjon Enhetlig pasientidentifikasjon er nøkkelen i all utveksling og informasjonsdeling Internasjonale standarder i et internasjonalt marked Vi skal benytte HL7 fordi det er en internasjonal standard og det er en markedsstandard i mange land. Det vil muliggjøre får norske leverandører å levere systemer ut i verden og for enklere for oss å ta systemer fra det globale markedet inn i vår portefølje Mindre redundans men flere tjenesteområder. 33

Tjenestebuss Realisert gjennom åpen ESB og mellomvare Annen leverandør enn EPJ Åpner for kjøring av tjenester fra flere leverandører Realiseres på forskjellig organisatorisk nivå Nasjonalt, regionalt og foretak Gir endringsevne

Informasjonssikkerhet og teknologi Felles løsning og teknologi for autentisering Lokal og nasjonal informasjonssikkerhetstjeneste etableres IAM løsninger i alle regioner Federering Etablering av standarder Unik brukerident WS standarder Policy drevet Felles PKI infrastruktur Fokus på semantikk gjennom felles informasjonsmodell

Gradvis tilnærming til en tjenesteorientert portefølje 04/04/2017 Gradvis tilnærming til en tjenesteorientert portefølje Innpakking av eksisterende funksjonalitet i tjenester som kan gjenbrukes Fagsystemer tilbyr funksjonalitet i Web Services. Sanering av dobbelfunksjonalitet. Felles tjenester etableres Fagsystemer og andre løsninger tilbyr funksjonalitet i Webservices levert over tjenestebuss. HL7 versjon 3 etablert som standard. Informasjonssikkerhets- tjenester er etablert. Redundant funksjonalitet fjernet. All funksjonalitet leveres som autonome tjenester. 36

HMNs arkitektur - erfaringer Fiasko ? 04/04/2017 HMNs arkitektur - erfaringer Fiasko ? 1993: Utfordrende å operasjonalisere i eksisterende systemlandskap Leverandørene har ulik kunnskap om og vilje til implementering av tjenester Økt behov for integrasjonstesting on-site, helhetlig forvaltning Vanskelig å forstå/tallfeste gevinster ved arkitektur Kunden/virksomheten velger system kun ut fra funksjonalitet Utfordrende å operasjonalisere i eksisterende systemlandskap Manglende informasjonsharmonisering Retningslinjer for ikke tjenesteorienterte systemer Leverandørene har ulik kunnskap om og vilje til implementering av tjenester HMN forholdsvis tidlig ute Greit å tilby tjenester, verre å konsumere tjenester fra andre leverandører Ønsker å eie informasjon som systemet benytter, levere ”helhetlig” system Tjenesteorientering hilses velkommen av mindre leverandører Vanskelig å forstå og tallfeste gevinster ved arkitektur Lett å nedprioritere arkitekturmål i prosjektene – ulike systemer benytter ulike begreper for å representere den samme virkelighet HMN systemlandskap Ingen alternativer til tjenesteorientering – ett system kan ikke dekke hele virksomheten/ gi helhetlig IKT-støtte for prosessene 37

HMNs arkitektur - erfaringer Suksess ! Forankring, samarbeid og kravstilling Økt bruk av fellestjenester Etablere tjenestebuss med sikring av webtjenester Internasjonal standard for innhold i tjenestene - HL7 v3 Kartlegging og prosessmodellering Organisasjonsutvikling for ta ut gevinster Klinisk arbeidsflate Forankring, samarbeid og kravstilling Helseregioner, leverandører, virksomhet Økt bruk av fellestjenester Bl.a. for å sikre felles begrepsapparat Etablere flere regionale fellestjenester som gradvis tas i bruk Ta i bruk nasjonale fellestjenester Etablere en tjenestebuss med sikring av webtjenester Felles overvåkning, administrasjon, kompetanse, kontaktpunkt/katalog Internasjonale standarder for innhold i tjenestene - HL7 v3 Fra hemsko til styrke for leverandørene Gjenbruke implementasjonsguide fra HV, ”dra lasset” på nye områder HL7 v3 på nye kliniske tjenester og forretningstjenester I etablering: tjenester for pasient og hvilke pasienter kommer Kartlegging og prosessmodellering For å identifisere de ”riktige” prosjektene (med størst effekt for brukerne) Prosessmodellering for å identifisere tjenester Etablere felles språk og metodikk for prosessmodellering I tett samarbeid med helsepersonell Organisasjonsutvikling nødvendig for ta ut gevinster Av helsepersonell, støtte i arkitektur - ”To-be” prosessmodellering Viktig forutsetning for å lykkes med helhetstenkning og bedre IT-systemer Innholdsstandard, prosessmodellering og klinisk arbeidsflate

Utfordringer for kunden Forstå arkitektur og hva dette skal gi Forstå at noen løsninger går på tvers av prinsippene og derfor ikke kan innføres Preferere nasjonale og regionale løsninger i stedet for lokale Utøve ”kunden bestemmer” på en måte som passer inn i helheten Funksjonelle krav vs arkitekturkrav Forstå konsekvenser av å velge på tvers av anbefalingene Tenke langsiktig nok Finne gode nok funksjonelle løsninger som passer inn Unngå å la seg påvirke av selgere eller velge det første og beste Helhetstenkning og nye løsninger krever organisasjonsutvikling

Utfordringer for ”oss” som leverandør 40 Kunden bestemmer. Funksjonelle krav vs arkitekturkrav Helhetstenkning krever forståelse for begrensninger og at noen løsninger ikke kan innføres Synliggjøre konsekvenser av å velge på tvers av anbefalingene Stille de riktige spørsmålene tidlig nok ”Nest-best” løsninger – hvordan unngå at en går rett på disse uten å legge ned innsats i preferert løsning Stille krav til leverandører – krever oppdatert dokumentasjon av løsninger/prefererte løsninger Unngå nedprioritering av arkitektur i prosjekter Forvalte avviksliste (registrere samt sikre at det blir endret neste gang løsningen/systemet skal endres)  

Forståelse, samarbeid og vilje Oppsummering 41 Felles arkitektur, samme målbildet og gjensidig avhengighet. Arkitekturen må operasjonaliseres i prosjektene Beslutningene som tas fra dag til dag er avgjørende for om vi lykkes i å nå målbildet Skal NHN ha en arkitektur og på hvilket nivå ? Forståelse, samarbeid og vilje