Arbeidsmøte 5 Annebeth Askevold, Gardermoen Arbeidsmøte 5 ebXML, vedlegg, meldingsveileder mm Annebeth Askevold Gardermoen

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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

Arbeidsmøte 5 Annebeth Askevold, Gardermoen Agenda med tentativ tidsplan 9.30 – 9.45Velkommen og målsettingen med møtet og kort presentasjon av av deltagerne 9.45 – 11.30ebXML og praktisk bruk gjennomgang av hva som må være på plass Presentasjon av Service/Action/Role kodeverk – 12.15Lunsj – 13.15Sending av vedlegg. Etablere nasjonal konsensus om sending av vedlegg – 14.00Meldingsveileder eResept – 14.15Pause – 15.15Orientering om erfaringer og bruk av XML-epikrise, og tilbakemeldinger fra sektoren – 16.00Utfordringer og erfaringer rundt bruk og implementering av henvisning – 16.30Oppsummering og frekvens og tema for påfølgende arbeidsmøter

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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.

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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?

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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

Arbeidsmøte 5 Annebeth Askevold, Gardermoen Mulige resultatmål (2006) • Alle helseforetakene skal ha tatt i bruk virksomhetssertifikater for meldingskommunikasjon innen • Alle aktører skal kunne sende og motta applikasjonskvittering innen • 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.

Arbeidsmøte 5 Annebeth Askevold, Gardermoen Meldingsveileder • Spørsmål til meldingsveileder i eResept: • Hva bør beskrives mer? • Hva bør fjernes? • Hva mangler?

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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å

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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?

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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.

Arbeidsmøte 5 Annebeth Askevold, Gardermoen 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.