Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "Status tekniske løsninger Medisinske kvalitetsregistre 8.6.2010 Per Olav Skjesol Avdelingsleder."— Utskrift av presentasjonen:

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

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

3 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

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

5

6

7

8 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

9 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

10 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

11 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

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

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

14 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

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

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

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

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

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

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

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

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

23 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

24 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

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 (1) 25

26 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

27 Hva skal arkitektur gi kunden (3) Idag Fremtidig

28 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) Arkitektur på flere nivå

29 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

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

31 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

32 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

33 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

34 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

35 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

36 Gradvis tilnærming til en tjenesteorientert portefølje

37 HMNs arkitektur - erfaringer Fiasko ? •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 HMN systemlandskap 1993: Ingen alternativer til tjenesteorientering – ett system kan ikke dekke hele virksomheten/ gi helhetlig IKT-støtte for prosessene

38 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 Innholdsstandard, prosessmodellering og klinisk arbeidsflate

39 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

40 Utfordringer for ”oss” som leverandør •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) 40

41 Oppsummering •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å ? 41 Forståelse, samarbeid og vilje


Laste ned ppt "Status tekniske løsninger Medisinske kvalitetsregistre 8.6.2010 Per Olav Skjesol Avdelingsleder."

Liknende presentasjoner


Annonser fra Google