210 likes | 304 Views
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.
E N D
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 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
Samhandlingsarkitektur for helsesektoren Legekontor (ELIN) Arkitektur HF Samhandlingsarkitektur (KITH) Kommuner (ELIN-k) HF1 Konvertering? NAV HL7? HF2 HF2 NPR (Hdir) Nasj. registre eResept (Hdir)
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.
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
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
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
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?
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
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
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
Eksempler på nye løsninger/konsepter • Kjernejournal • Reseptformidleren • Helsekort for gravide
HFS – Helsesektorens FormidlingsSentral HFS Postkasse Legekontor HF1 WS HF2 Send () Legekontor Motta () NAV sjekk(sertifikat) Sjekk() NPR Adr PKI
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
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)
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