1 / 21

Fremtidens samhandlingsløsninger Av programleder Standardiserings- og samordningsprogrammet

Fremtidens samhandlingsløsninger Av programleder Standardiserings- og samordningsprogrammet Avdelingssjef Bjarte Aksnes, KITH. Samhandlingsarkitektur. Systemarkitektur(aktør A). Systemarkitektur(aktør B). For web-tjenester mm. For meldinger.

tallys
Download Presentation

Fremtidens samhandlingsløsninger Av programleder Standardiserings- og samordningsprogrammet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fremtidens samhandlingsløsninger Av programleder Standardiserings- og samordningsprogrammet Avdelingssjef Bjarte Aksnes, KITH

  2. Samhandlingsarkitektur Systemarkitektur(aktør A) Systemarkitektur(aktør B) For web-tjenester mm For meldinger Fagsystem (Funk. krav, Innholdsstandard EPJ-standard) Innholds-standarder Innholds-standarder Fagsystem Kommunika-sjonstjenester Kommunika-sjonstjenester Kommunikasjon og rammeverk Kommunikasjon og rammeverk Infrastruktur & basistjenester Infrastruktur & basistjenester Infrastruktur & basistjenester Infrastruktur & basistjenester

  3. Samhandlingsarkitektur for helsesektoren Legekontor (ELIN) Arkitektur HF Samhandlingsarkitektur (KITH) Kommuner (ELIN-k) HF1 Konvertering? NAV HL7? HF2 HF2 NPR (Hdir) Nasj. registre eResept (Hdir)

  4. Samhandlingsarkitektur og NIKT-arkitektur • Må ta hensyn til alle aktører (kommuner, legekontor, HF, apotek, NAV, registre m.fl) • Samhandlingsarkitekturen gjelder for samhandling mellom virksomheter • Møte mellom KITH og Nasjonal-IKT arkitekturforum 12 nov: • Arkitekturen til NIKT innebærer ikke noe brudd med den gjeldende samhandlingsarkitektur når det gjelder samhandling mellom aktørene i sektoren. • Nasjonal IKT støtter fullt ut Samspill 2.0 og Meldingsløftet basert på ebXML-rammeverket. Dette er en viktig og prioritert satsning også for spesialisthelsetjenesten, og den er på ingen måte i konflikt med den vedtatte systemarkitekturen. • Satsningen på HL7 versjon 3 gjelder primært kommunikasjon mellom systemer internt i spesialisthelsetjenesten. KITH er helt enig i at HL7 versjon 3 er et riktig og viktig valg når det gjelder slik kommunikasjon og ser fram til et videre samarbeid rundt dette.

  5. Videreutvikling av samhandlingsarkitekturen • Arkitekturen er dynamisk (men endringer gjøres kun etter nøye vurdering) • De ulike nivåene er uavhengig av hverandre (innholdsstandarder, kommunikasjon og rammeverk, infrastruktur og basistjenester) • Evolusjonær arkitektur (små endringer og tilpasninger, må ta hensyn til tidligere arbeid) • Støtter tjenesteorienterte systemarkitekturer • Sektoren og leverandørene er premissgivere

  6. Standarder for samhandling • Meldingsløftet: 10 • Andre ordinære: 6 • PLO: 10 • NAV: 4 • Registre: 4 • eResept: ca 30 • TOTALT: ca 64 innholdsstandarder • Disse er enten nasjonale tilpasninger (profiler) av int. standarder eller laget fra grunnen av

  7. Utfordringer fremover elektronisk samhandling • Samhandlingsløsningene blir svært kritiske ift. helsetjenesten (tilgjengelighet, stabilitet, sikkerhet) • Behov for å involvere nye aktører (eks. tannleger, spesialistgrupper, fysioterapeuter mv) • Noen få store drifts- og utviklingsmiljø (både hos leverandører og bruker) vil være drivere, mens små miljø kan få problemer med å henge med • Nye behov og endringer i løsningene må kunne håndteres fleksibelt

  8. Løsningsstrategier • Mest mulig standardisering (og krav til bruk) • Innholdsstandarder • Kommunikasjonsstandarder (både ebXML og web-services) • Testing og sertifisering av løsninger • Test og godkjenning • Forløpstesting • Brukertesting • Felles infrastruktur • Felles komponenter eller løsninger?

  9. Grunnprinsipper – også fremover! • Informasjon om den samme pasienten kan befinne seg i ulike virksomheter • Helsepersonell må dokumentere helsehjelp hos den virksomhet som har (medisinsk) behandlingsansvar for pasienten • Det vil være behov for å utlevere/sende informasjon til andre aktører (push) • Det vil også være behov for å få tilgang til informasjon som finnes hos andre parter (pull) • Det vil være ulike fagsystemer som leveres av ulike leverandører innenfor hvert segment

  10. Skalerer dagens samhandlingsarkitektur? • Fordeler: • Bygger på åpne standarder • Frihet i valg av løsninger og leverandører • Konsensus om standardene • Ulemper • Kan være ulike tolkninger av enkeltelementer • Hver leverandør må implementere standardene i sine løsninger • I prinsippet samme løsning for alt fra legekontor til HF (med svært ulike forutsetninger) • Utrulling av endringer er krevende

  11. Finnes det noen alternativer? • Så lenge grunnprisnippene gjelder må vi kunne utveksle informasjon mellom aktører • All utveksling er i utgangspunktet ”meldingsbasert”, men med ulike teknologier (x.400, smtp, ws) • Alle ”tunge” bransjer har basert seg på en form for meldingsutveksling – eks. bank, varehandel, transport, billettbestilling (fly) • Tjenesteorientering • Sentrale kommunikasjonsløsninger • Felles tjenester og moduler

  12. Eksempler på nye løsninger/konsepter • Kjernejournal • Reseptformidleren • Helsekort for gravide

  13. Eksempel: Helsekort (for gravide)

  14. HFS – Helsesektorens FormidlingsSentral HFS Postkasse Legekontor HF1 WS HF2 Send () Legekontor Motta () NAV sjekk(sertifikat) Sjekk() NPR Adr PKI

  15. HFS – Helsesektorens FormidlingsSentral • Må kunne formidle tradisjonelle meldinger i tråd med samhandlingsarkitekturen til alle aktører (også over internett!) • Vil tilby WS for utvalgte tjenester (i første omgang kommunikasjonstjenester) • Kan fungere som en mellommann (proxy) for meldinger som formidles vha web-services • Kan også mellomlagre asynkrone meldinger (f.eks når mottaker ikke er tilknyttet) • Aktørene trenger kun å tilpasse seg grensesnittet mot HFS • Godkjenning av kommunikasjonsgrensesnitt gjøres av HFS • Innholdsstandarden må først være godkjent gjennom T&G • Vil også videreformidle kvitteringer og gi egne kvitteringer/feilmeldinger ved behov (f.eks meldinger som ikke kan formidles) • Må gjennomgå kost/nytte vurderinger

  16. Fordeler HFS • Kompatibelt med dagens løsninger (kan innføres gradvis) • Fra mange-til-mange til mange-til-en ift kommunikasjon • En aktør trenger kun å gjøre integrasjon mot HFS • Kontroll på driftsstabiliteten (oppetid, feil) helt frem til mottaker (krav til QoS) • Kan lage en felles modul for kommunikasjon med HFS • Vil forenkle sertifikathåndtering og adressering • Kan tilby kommunikasjon med aktører som ikke er på helsenett • Kan også ivareta konvertering mellom versjoner av meldinger (opsjon)

  17. Arkitekur for eResept

  18. Oppsummering • Samhandlingsarkitekturen ligger fast • Økende samhandling gir enda større behov for stabile og profesjonelt driftede løsninger • Sentrale samhandlingsløsninger bør vurderes • Det vil fremdeles være behov for standardisering av innhold (kodeverk mv.) og godkjenning • Kommunikasjonsløsningene kan ”forenkles” • KITH ønsker å være en pådriver for å videreutvikle dagens løsninger

More Related