Målsettinger Generelle målsettinger for arbeidsmøtene

Målsettinger

• Generelle målsettinger for arbeidsmøtene:

• Sikre lik forståelse av bruk og implementering av meldingsstandarder
• Være et forum for å diskutere praktiske problemstillinger, og oppnå nasjonal konsensus
• Ivareta en god arbeidsform med leverandører og brukere. Og motta tilbakemeldinger.

• Målsettinger for dagen:

• Synliggjøre tiltak som kan sikre en samordnet innføring av ebXML
• Oppnå nasjonal konsensus om hovedprinsipper for bruk av Service/Action/Role i ebXML
• Nasjonal konsensus om sending av vedlegg
• Motta tilbakemeldinger på en tidlig utkast til en meldingsveileder for eResept
• Nasjonal konsensus om epikrisemeldingen skal tillate formatert tekst i noen fritekstfelt
• Synliggjøre utfordringer for full bredding av epikrise- og henvisning
• Motta tilbakemeldinger på behov for nasjonale retningslinjer for nivå på adressering (spesielt for henvisning)
• Informere om pågående arbeid

Agenda med tentativ tidsplan

• 9.30 – 9.45 Velkommen og målsettingen med møtet og kort presentasjon av av deltagerne

• 9.45 – 11.30 ebXML og praktisk bruk gjennomgang av hva som må være på plass Presentasjon av Service/Action/Role kodeverk

• 11.30 – 12.15 Lunsj

• 12.15 – 13.15 Sending av vedlegg. Etablere nasjonal konsensus om sending av vedlegg

• 13.15 – 14.00 Meldingsveileder eResept

• 14.00 – 14.15 Pause

• 14.15 – 15.15 Orientering om erfaringer og bruk av XML-epikrise, og tilbakemeldinger fra sektoren

• 15.00 – 16.00 Utfordringer og erfaringer rundt bruk og implementering av henvisning

• 16.00 – 16.30 Oppsummering og frekvens og tema for påfølgende arbeidsmøter

Hvorfor ebXML og PKI

• Standardisert plattform for meldingsutveksling

• som støtter de krav til sikkerhet og pålitelighet som sektoren stiller.
• Og støtter enkel identifisering av forretningsprosessen

• Forenkling:

• ebXML sikrer entydig adressering
• ebXML forenkler sending av ulike typer vedlegg, og sikrer en entydig metode. ebXML vil bidra til god og effektiv utnyttelse av katalogtjenester, og forenkler mange-til-mange kommunikasjon

• Bedre sikkerhet og tillit:

• Bruk PKI vil gi bedret informasjonssikkerhet ved utveksling av elektroniske meldinger.
• Meldingen signeres med et elektronisk sertifikat tilhørende enten helsepersonell eller en helseinstitusjon.
• Integritet: Rammeverket og PKI fører til at meldingen kommer frem til mottakeren i samme form som den sendes.

• Beskyttelse mot innsyn:

• Kan overføre meldinger kryptert uten på forhånd å avtale hvilke nøkler man skal bruke. Krypteringsnøklene vil være tilgjengelig i en åpen katalog. (i dag benytter nesten hele Helse-Norge samme krypteringsnøkkel som ”alle” kjenner)

• Trygghet for at meldingen kommer frem til mottaker:

• ebXML er tilrettelagt for bruk av gode kvitteringsmekanismer for å sikre at meldingen kommer frem
• ebXML støtter funksjoner for å automatisk sende meldinger på nytt med mindre man ha fått kvittering for at meldingen er mottat, evt. varsle dersom meldingen ikke kommer frem til mottaker.

Nasjonal innføring av ebXML

• RTV krever ebXML og PKI

• Medisinsk fødselsregister krever ebXML og PKI

• Primærlegesystemene har implementert ebXML

• Sykehusene må ta i bruk ebXML ved elektronisk kommunikasjon med MFR i 2006

• Helse Midt-Norge piloterer ebXML sammen med mottak av henvisning

• utfordring å løfte eksisterende kommunikasjonsløsninger over på ny plattform i et samordnet løp

• Hvordan kan KITH bidra til å sikre at ebXML og PKI blir tatt i bruk som sikker kommunikasjonsplattform?

Applikasjonskvittering

• Applikasjonskvittering

• Er alltid tilbakemelding på en spesifikk melding
• sendes automatisk fra mottagerapplikasjonen
• Kan benyttes som en enkel kvittering (OK / avvist), eller med detaljerte tilbakemeldinger

Applikasjonskvittering

• Felles kvitteringsmelding som kan benyttes av alle meldinger

• Applikasjonskvittering bekrefter at mottagerapplikasjonen kan tolke mottatt melding

• Den sier ingen ting om logikken i innholdet såfremt dette ikke er implementert

• For å kunne nyttiggjøre seg applikasjonskvitteringen, må man ha etablert rutiner som sikrer god behandling og oppfølging på riktig nivå ved feil/avvik

• Viktig at alle kan motta applikasjonskvittering for å ikke bremse innføringen

ebXML, Apprec og fagmelding

• ebXML, applikasjonskvittering og fagmelding må kunne knyttes sammen på en entydig måte

• Krever unike ID’er
• Entydig hvilke ID’er som skal benyttes

• ebXML bestemmer forretningsprosessen (Service i ebXML).

• Applikasjonskvittering må knyttes sammen med riktig forretningsprosess og riktig fagmelding

• Entydige regler for alle forretningsprosesser må utarbeides

Mulige resultatmål (2006)

• Alle helseforetakene skal ha tatt i bruk virksomhetssertifikater for meldingskommunikasjon innen 1.8.2006

• Alle aktører skal kunne sende og motta applikasjonskvittering innen 1.8.2006

• Alle foretak må ha sett på hvilke tiltak/rutiner som må være på plass før de mener at parallell papirsending kan bortfalle på en kontrollerbar måte.

Meldingsveileder

• Spørsmål til meldingsveileder i eResept:

• Hva bør beskrives mer?

• Hva bør fjernes?

• Hva mangler?

Referansedokument - meldingsimplementering

• Samling av praktiske referansedokumentersom skal være en hjelp ved implementering

• overordnet forretningsprosess

• ebXML, applikasjonskvittering, fagmelding og tilknyttede meldinger Beskrive hva de ulike delene løser, hvordan de brukes og sammenhenger

• retningslinjer for fellesinformasjon

• identifikasjon av meldingstype, versjon, programvare/versjon osv

• generelle regler for bruk av XML

• tegnsett, bruk av datatyper osv.
• definisjon av felles kodeverk og presiseringer rundt bruken av kodeverk

• retningslinjer for håndtering av vedlegg

• Retningslinjer for adressering og identifisering av parter

• avsender, mottaker/kopimottakere, pasient, helsepersonell etc.

• retningslinjer for signering av meldinger (XMLDSIG)

• retningslinjer for krav om test og godkjenning

Revisjon i hodemeldingen

• Hodemeldingen skal benyttes i eResept

• Hodemelding er utvidet med mulighet for digital signering med XMLdsig

• Endring i kardinalitet på ID på personnivå

Formatert tekst i epikrisemeldingen

• Skal vi lage en v1.1 som tillater formatert tekst i noen utvalgte XML-element?

• Forslag til hvilke felt som skal utvides med bruk av satatypen ”anyType”

• Skal vi også utvide refDoc?

Forslag til utvidelser i epikrisemeldingen

• Følgende informasjonselement foreslås endret fra datatypen ST til datatypen anyType:

• Beskrivelsesfeltet i Annen klinisk opplysning

• /Message/ServRprt/Event/InfItem/Observation/Description

• Beskrivelsesfeltet for den aktuelle hendelsen i Kommentar til hendelsen

• /Message/ServRprt/Event/Event/Comment/TextResultValue

• Beskrivelsesfeltet i Begrunnelse for henvisningen

• /Message/ServRprt/ServReq/ReasonAsText/TextResultValue

• Tekstlig beskrivelse av undersøkelsesresultatet i Tekstlig resultat

• /Message/ServRprt/Event/InfItem/ResultItem/TextResult/Result/TextResultValue

Avklaringer

• Skal vi lage en versjon 1.1 som endrer to XML-element fra datatypen ST til datatypen anyType?

• Meldingen vil være bakoverkompatibel, men mottager må kunne håndtere XHTML

• Avsenderapplikasjonen behøver ikke å gjøre andre endringer enn å legge inn nytt namespace hvis det ikke er ønske om å benytte muligheten for å sende formatert tekst.

Påskenøtt (fra Acos)

• Det blir laga ei e-melding som skal til fire mottakarar. (mottakar + 3 kopimottakarar)

• To av mottakarane er i same kommune/same datasystem. Den tredje er i same kommune, eit anna datasystem.

• Det skal brukast hodemelding.

• Melding skal sendast via rammeverket til mottakar, applikasjonskvittering skal returnerast.