fremtidens samhandlingsløsninger av programleder standardiserings- og samordningsprogrammet

Standardisering og arkitektur


Fremtidens samhandlingsløsninger Av programleder Standardiserings- og samordningsprogrammet

Avdelingssjef Bjarte Aksnes, KITH


Infrastruktur & basistjenester

Kommunika-sjonstjenester

Fagsystem

Systemarkitektur(aktør A) For meldinger

SamhandlingsarkitekturSystemarkitektur(aktør B)For web-

tjenester mm



Kommunikasjon og rammeverk

Innholds-standarder

Kommunika-sjonstjenester

Fagsystem (Funk. krav, Innholdsstandard EPJ-standard)


Kommunikasjon og rammeverk

Innholds-standarder


Samhandlingsarkitektur for helsesektoren

Samhandlingsarkitektur (KITH)

Legekontor (ELIN)

NAV

Kommuner (ELIN-k)

Nasj. registre

NPR (Hdir)HF2

HF1

Konvertering?

Arkitektur HF

eResept (Hdir)

HL7?

HF2


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


Eksempel: Helsekort (for gravide)

ID-løsninger fase 2

Nettleser

Gravid

Postboks for helsekort

Presentasjonslag

Brukerinteraksjon for brukere uten integrert løsning

Tjenestelag

Sikkerhetstjenester- autentisering- rettigheter- roller- tilgangslogg

Dokument-tjenester- Hent versjon- Lagre dokument- Legg inn dokument

DatalagMetadata- Subjekt - Type dokument- Sist endret av- Aksessert av

Web

Identitetstjenester- Min ID- BankId

- … andre

NettleserHelsepersonell uten helsekortmodul

Web

Helsepersonell med helsekortmodul

Web-service


HFS – Helsesektorens FormidlingsSentral

LegekontorPostkasse

Legekontor

HF1

HF2Send ()

Motta ()

Sjekk()

WS

NAV

PKI Adr

NPR

HFS

sjekk(sertifikat)


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)


Arkitekur for eResept


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

fremtidens samhandlingsløsninger av programleder standardiserings- og samordningsprogrammet

Documents