Arbeidsmøte Elin-k og KITH

Presentasjon om: "Arbeidsmøte Elin-k og KITH"— Utskrift av presentasjonen:

1 Arbeidsmøte Elin-k og KITH
Pleie- og omsorgsmeldinger Dialogmelding Utfordringer og avklaringer Annebeth Askevold Gardermoen 12. desember 2007

2 Innhold Målsettinger med dagens møte
Strukturert medisinering - muligheter i forhold til eResept, Fest, SUMO med mer. Rettelser i PLO-melding vedlegg: zip-fil med oppdaterte XML-schema (må benyttes for visningsfilen) Gjennomgang av spørsmål og svar Endringsforslag i PLO-melding Tjenestetilbud – overføring av andre tjenester enn iplostjenester Bruk av dialogmeldingen – svar på svar strukturerte spørsmål Hvordan skal svar på svar vises i EPJ? Timebestilling, reseptbestilling: Dialogmelding eller pasientkommunikasjon? Visningsfiler Applikasjonskvittering – bruk av Ack-feltet Retningslinjer – er retningslinjer en hjelp til å implementere meldingene korrekt? HVORDAN SIKRE FREMDRIFT Oversikt godkjenning. Hvem sender hva – oversikt – aktivitet. Eventuelt

3 Hovedfokus på fase 1, del 1 og del 2 Målsettinger for dagen:
Oppnå konsensus om hvordan medikamenter skal overføres i fase 1, del 2 (og fase 2) Avklare eventuelle endringsbehov i PLO-meldingene Avklare bruk og presentasjon av dialogmelding Oppnå konsensus om visningsfiler Oppnå konsensus om hvordan ack-feltet i applikasjonskvittering skal benyttes Kartlegge eventuelle utfordringer med kopimottakere Orientering om bruk av namespace (hvis det blir tid)

4 Strukturert overføring av legemidler
Er det mulig å pilotere strukturert overføring av medisiner i 2008? Status eResept eResept fase 1 skal piloteres vår/høst 2007 Meldingsdokumentasjon er klar Legemiddelverket har besluttet å lage en omfattende Fest (forskrivnings- og ekspederingsstøtte) KITH har sendt til eResept med forslag om omforent modell (Dosering eReept ToNy doc)

5 Legemiddelhåndtering krav fra Elin-k
Informasjon om det foreligger avtale om adm. av legemidler (boolsk) Informasjon om det foreligger avtale om adm. av multidose (boolsk) Strukturert informasjon om innhold i avtalen (iht. kodeverk 9132) Strukturert informasjon om diagnoser Strukturert informasjon om legemidler i henhold til meldingsdefinisjonen

6 Forslag til eResept – fase 1

7 Forslag til eResept – fase 2

8 Ustrukturert overføring av legemidler
Informasjonen legges i journaltekst En forekomst av journaltekst per legemiddel Ny overskriftskode LM=Legemiddel i 9142 Medisinskfaglige opplysninger Følgende informasjon skal overføres som tekst i notat Navn Legemiddel Legemiddelform Styrke Dosering Kur/Behov/Fast Varer til dato Apocillin tablett 1 g tabl. X 2 i 4 uker Kur

9 Utfordringer med ustrukturert overføring av legemidler
Ikke mulig med automatisk behandling av mottatte data Hvordan skal de ulike dataelementene skilles for å sikre god presentasjon? Vil tab håndteres av alle system? Andre skilletegn?

10 Endringer i kravspekk Generelt funksjonskrav: Sending av meldinger uten at pasientens identitet fremkommer Dette kravet er tatt ut. Det vil i liten grad være aktuelt for meldinger til og fra kommuner. Dette kravet vil i hovedsak være aktuelt i forbindelse med innrapportering av noen typer opplysninger til sentrale registre.

11 Feilrettinger i PLO-meldingene
Endret datatyper for følgende elementer: ../Infusjonshastighet/Infusjonsvolum fra decimal til PQ ../PnDose/GjentagelseIntervall fra integer til PQ ../PnDose/MaksDogndose fra double til PQ ../PnDose/MaksDosePrTidsenhet fra double til PQ ../PnDose/MinDoseIntervall fra double til PQ Fjernet følgende element: ../PlanlagtGjennomforingTiltak/Gjentakelsesintervall ../PlanlagtGjennomforingTiltak/Tidsenhet Nytt element: ../PlanlagtGjennomforingTiltak/GjentagelseIntervall med datatype PQ (Erstatter Gjentakelsesintervall og Tidsenhet)

12 Forslag til endringer Ønsker en måte å oppgi om meldingen er et svar på en forespørsel. Dette er i dag kun mulig for konsultasjon og overføring av helseopplysninger Hvis en melding skal brukes som svar på forespørsel, og forespørselen inneholder dato fra/til er det heilt nødvendig at datoene kommer med i svaret. Ellers blir svaret misvisende. Ønsker i tillegg kan å kunne sende med et notat på de meldingene som til nå ikke har det – ikke minst ved tillegg/kansellering. Et notatfragment vil kunne erstatte InnholdKonsultasjon og TypeInnholdOverforingHelseopplysninger + OpplysningForesporsel. (søknadsopplysningane kan legges ut i eget fragment). Er det forresten nødvendig med ekstra samtykke ved overføringhelseopplysninger i tillegg til opplysningen om samtykke i hodemeldingen?

13 Endringer i toppen

14 Endringer i Overføring av helseopplysninger
ny Flyttet til toppen

15 Orientering om tjenestetilbud
Må kunne sende informasjon om IPLOS-tjenester og andre tjenester IPLOS tjenestetype kan overføres strukturert som en kodet verdi med tilhørende kodetekst under XML-elementet <IPLOStjenestetype>. I tillegg til eller i stedet for kan det oppgis en tekstlig beskrivelse av tjenesten <BetegnelseTjeneste>. <BetegnelseTjeneste> er obligatorisk hvis <IPLOStjenestetype> mangler. Akseptansetesten dekker både IPLOS tjenester og tjenester som ikke er IPLOS-tjenester. Tilsvarende inneholder testcase 6 som skal gjennomføres i piloten både IPLOS-tjenester og ikke-iplos-tjenester.

16 Tilleggsopplysninger
Tilleggsopplysninger legges i samme meldingstype som opprinnelsen til opplysningene. Eksempel: Tilleggsopplysninger til en tverrfaglig epikrise skal overføres i en ny forekomst av tverrfaglig epikrise. Forsendelsesstatus = A (Tillegg) Status til forsendelsen oppgis i ../InformasjonOmForsendelsen/Forsendelsesstatus A=Tillegg Referanser til forrige melding og dialogstart oppgis i hodemeldingen. Må være med for å sikre riktig kobling

17 Timebestilling, reseptbestilling
Alternativ 1: Standardiserte spørsmål i dialogmeldingen Alternativ 2: Strukturert melding basert på pasientkommunikasjonsmeldingen.

18

19 Standardiserte spørsmål i dialogmeldingen
9152 Standardiserte spørsmål vedr. pasientsamhandling 1 Forespørsmål om utlevering av medisinske opplysninger Dette spørsmålet skal besvares med en melding av type ”Overføring av helseopplysninger PO”. Kun relevante medisinske opplysninger skal med. 2 Forespørsel om utlevering av diagnoser mv. relevant for IPLOS-rapportering Svar på dette spørsmålet skal alltid være en melding av typen ”Overføring av helseopplysninger PO” med minimum innhold: Relevante medisinske diagnoser Tidspunkt for sykdomsdebut Dato for siste konsultasjon. 3 Forespørsmål om orientering om tjenestetilbud Svar på dette spørsmålet skal alltid være en melding av typen ”Orientering om tjenestetilbud”. 4 Forespørsel om oppdaterte legemiddelopplysninger Svar på dette spørsmålet skal alltid være en melding av typen ”Legemiddelhåndtering” 5 Forespørsel om å fornye resept Skal det skilles mellom ny resept og fornying av resept (2 koder?) Skal svar være dialogmelding eller egen melding? 6 Forespørsel om time

20 Hvordan skal svar på svar på forespørsel vises i dialogmeldingen?
Dialogmelding - bruk Hvordan skal svar på svar på forespørsel vises i dialogmeldingen? Er det behov for felles retningslinjer her? Er dokumentasjonen mangelfull?

21 Dialogmelding Krav til journalføring
Hvordan er dialogmeldingenes krav om journalføring, eller slettemuligheter for type dialogmeldinger som ikke er nødvendig å journalføre? eks. "resept klar for avhenting" eller "Ok" etc Meldingsboksen kan fort "flyte over" av meldinger som egentlig ikke er nødvendig å samle på. Selv om det blir enighet om at type "OK"-meldinger ikke skal sendes, tror jeg aldri vi kommer helt til bunns med det..

22 Avvikshåndtering 3 mulige nivåer for avvikskontroller
På transportnivå – sikkerhet for at meldingen kommer frem Ivaretas av kvitteringsmeldinger i ebXML På applikasjonsnivå – trygghet for at meldingen kan leses av mottaker Ivaretas av applikasjonskvittering Manuell tilbakemelding på innhold etc Kan ivaretas med dialogmeldingen Foreløpig ikke tatt i bruk Vil bli tatt i bruk gjennom ELIN-k

23 Avvik Med ”avvik” menes i norm for informasjonssikkerhet enhver håndtering av helse- og personopplysninger som ikke utføres i henhold til gjeldende regelverk, retningslinjer og/eller prosedyrer, samt andre sikkerhetsbrudd. Avsender er ansvarlig for Avviksrapportering i forbindelse med feilsending Mottaker er ansvarlig for Avviksrapportering i forbindelse med feil, dvs. mottak av melding eller e-post som ikke er adressert til virksomheten Avviksrapportering i forbindelse med mottak av meldinger generelt

24 Avvikshåndetering i et samhandlingsperspektiv
ebXML-rammeverk (innpakking, adressering, transportkvittering, kryptering, autentisering, virksomhetssignatur) Innholdsstandard (meldinger) Hodemelding Applik.- kvitt- ering Ev. personlig signatur Norsk Helsenett Postkasse Adr. katalog PKI- Internett Automatisk avvikshåndtering på applikasjonsnivå Automatisk avvikshåndtering på transportnivå Manuell tilbakemelding Dialogmelding, telefon mm

25 Kodeverk for avvikshåndtering
Forslag: Knytter avvikskoder opp mot norm for informasjonssikkerhet 8117 Avvik ved mottak av elektronisk melding 1 Avvik i henhold til konfidensialitet 2 Avvik i henhold til tilgjengelighet 3 Avvik i henhold til integritet 4 Avvik i henhold til kvalitet

26 Nye koder (Forslag på møtet)
Feilsending Mangelfulle opplysninger Svikt i rutiner Annet Forventninger i forhold til oppfølging/svar Avtaler mellom samhandlingsparter må ligge i bunnen Må stå i header at det er en avviksmelding

27 Visningsfiler Revidert visningsfil for PLO-meldingene
Forutsetter v1.31 av XML Schema Eksempel tverrfaglig epikrise Visningsfil for dialogmelding er etablert Case 3 - mer formatering ELIN-k case 3 - Dialogmelding forespørsel ELIN-k case 3 - Dialogmelding svar ELIN-k case 4 - Dialogmelding Avviksmelding Hva er bra, hva kan bli bedre?

28 Linjeskift etc. i dataelement
Datatype string Datatype anyType

29 En prosjektleder per pilotgruppe Workshop?
Fremdrift En prosjektleder per pilotgruppe Prosjektleder i kommunen har ansvaret iht. Elin-k avtalen Workshop? Fest – kan muligens føre til forsinkelser Skal være klar 1.03

30 Hva er utforingene ved å sende vedlegg?
Teknisk? Mangler det dokumentasjon? Økonomi? Forslag til strategi for å ta dette i bruk.

31 Innføring og bruk av applikasjonskvittering
Det er viktig at alle kan motta applikasjonskvittering for å ikke bremse innføringen. I meldingene finnes det et datafelt der det er mulig å angi om kvittering skal sendes eller ikke (XML element <Ack>). Siden alle foreløpig ikke er i stand til å motta applikasjonskvittering må dette dataelementet benyttes aktivt hvis man ikke kan motta applikasjonskvittering. Ack skal ha verdi (kodeverdi N) hvis applikasjonskvittering ikke skal sendes. Hvis verdien på dette feltet har kodeverdi N indikerer dette at kvittering ikke skal sendes. Ack skal ha verdi (kodeverdi J) når applikasjonskvittering skal sendes. Siden applikasjonskvittering inngår som en obligatorisk del av samhandlingsarkitekturen skal manglende bruk av Ack-feltet tolkes som at applikasjonskvittering skal sendes. Dette skal ikke være en brukerstyrt parameter som kan bestemmes per sending, men må være satt av systemansvarlig. Ack-feltet er obligatorisk for alle meldinger som benytter Hodemeldingen.

32 Hva er utforingene ved å sende vedlegg?
Sending av vedlegg Hva er utforingene ved å sende vedlegg? Teknisk? Mangler det dokumentasjon? Økonomi? Forslag til strategi for å ta dette i bruk.

33 Maler for utskrift av epikrise- og henvisning
Prinsipper for utskrift av meldinger og skjema Prinsipper for utskrift av epikrise Prinsipper for utskrift av henvisning

34 Hvordan kan godkjenningsprosessen bli bedre?
Test- og godkjenning Hvordan kan godkjenningsprosessen bli bedre? Ris og ros Hvordan kan ny tjeneste i test- og godkjenningsordningen heve kvaliteten? Bestille/sende meldinger til testserveren Erfaringer fra forløpstesting Bør Elin-k benytte dette?

35 Spørsmål relatert til Elin-k
Kontakt Spørsmål relatert til Elin-k (prosjektledelsen) (alle pilotkommuner og prosjektledelsen) Informasjon og spørsmål om meldinger: Standarder og informasjon om KITHs arbeid med elektronisk samhandling Dokumentasjon fra KITH stilles fritt til rådighet for sektoren Råd og spørsmål vedrørende meldingsimplementering Meld deg på nyhetsliste på forsiden på og under (Nyheter)