Aksnes: Neste generasjons samhandlingsløsninger

Download Report

Transcript Aksnes: Neste generasjons samhandlingsløsninger

Standardisering og arkitektur
Fremtidens samhandlingsløsninger
Av programleder Standardiserings- og samordningsprogrammet
Avdelingssjef Bjarte Aksnes, KITH
Standardisering og arkitektur
Systemarkitektur
(aktør A)
Samhandlingsarkitektur
For meldinger
For webtjenester mm
Systemarkitektur
(aktør B)
Fagsystem
(Funk. krav,
Innholdsstandard
EPJ-standard)
Innholdsstandarder
Innholdsstandarder
Fagsystem
Kommunikasjonstjenester
Kommunikasjon
og rammeverk
Kommunikasjon
og rammeverk
Kommunikasjonstjenester
Infrastruktur &
basistjenester
Infrastruktur &
basistjenester
Infrastruktur &
basistjenester
Infrastruktur &
basistjenester
Standardisering og arkitektur
Samhandlingsarkitektur for helsesektoren
Legekontor
(ELIN)
Arkitektur HF
Samhandlingsarkitektur
(KITH)
HF1
HL7?
HF2
Kommuner
(ELIN-k)
Konver
tering?
NAV
HF2
NPR (Hdir)
Nasj. registre
eResept
(Hdir)
Standardisering og arkitektur
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å ebXMLrammeverket. 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.
Standardisering og arkitektur
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
Standardisering og arkitektur
Standardisering og arkitektur
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
Standardisering og arkitektur
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
Standardisering og arkitektur
Løsningsstrategier
•
•
•
•
Mest mulig standardisering (og krav til bruk)
•
•
Innholdsstandarder
Kommunikasjonsstandarder (både ebXML og webservices)
Testing og sertifisering av løsninger
•
•
•
Test og godkjenning
Forløpstesting
Brukertesting
Felles infrastruktur
Felles komponenter eller løsninger?
Standardisering og arkitektur
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
Standardisering og arkitektur
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
Standardisering og arkitektur
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
Standardisering og arkitektur
Eksempler på nye løsninger/konsepter
•
•
•
Kjernejournal
Reseptformidleren
Helsekort for gravide
Standardisering og arkitektur
Eksempel: Helsekort (for gravide)
Standardisering og arkitektur
HFS – Helsesektorens FormidlingsSentral
HFS
Postkasse
Legekontor
HF1
WS
HF2
NAV
Send ()
Legekontor
Motta ()
sjekk(sertifikat)
Sjekk()
NPR
PKI
Adr
Standardisering og arkitektur
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
Standardisering og arkitektur
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)
Standardisering og arkitektur
Standardisering og arkitektur
Arkitekur for eResept
Standardisering og arkitektur
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
Standardisering og arkitektur