Innhold

Aktører

Bakgrunn

Når legen sender en PLL (M25.1-melding) som inneholder resepter med CAVE, dobbeltforskrivning eller interaksjonsvarsler, skal den inneholde informasjon om “håndtering” av disse advarslene, dvs. at en lege har bekreftet at pasienten skal ha disse legemidlene til tross for advarslene.

Ved håndtering av varslene:

• Bekrefte at varsel er sett og håndtert ved å angi kode for håndtering av varsel

• Må/ kan skrive en kommentar til at en tillater å sende legemidler med Cave, interaksjon/ dobbeltforskrivning

Det finnes ikke støtte for disse feltene i dagens e-resept meldinger (v.2.5)

For å kunne bygge støtte for disse feltene uten å endre meldingsformatet foreslår vi en løsning hvor vi legger inn en json struktur i et eksisterende felt i meldingen .

Rekvirentkrav

Dette er dagens rekvirentkrav som omhandler håndtering av varsler.

3.1.26:

Ved medisinsk endring så skal det legges til en tekstlig kommentar på LIB-element i PLL. Kommentaren skal registreres med kode: «medisinsk endring» og tidspunktet endringen ble gjort på skal settes som opprettelsestidspunkt. Kommentaren skal inneholde:

1. informasjon om hva som er endret (generert av systemet).

2. begrunnelse fra lege som er angitt som grunn til endring (hvis oppgitt).

3.1.28:

Begrunnelse for overstyring av varsel om legemiddelreaksjon skal legges til som tekstlig kommentar på LIBelement i PLL. Kommentaren skal registreres med kode: «legemiddelreaksjon» og tidspunktet endringen ble gjort skal settes som opprettelsestidspunkt. Kommentaren skal inneholde begrunnelsen fra rekvirent som angitt ved forskrivning. Begrunnelsen skal ligge ved så lenge legemiddelreaksjon ikke er avkreftet.

3.1.29:

Begrunnelse for overstyring av varsel om dobbeltforskrivning skal legges til som tekstlig kommentar på LIB-element i PLL. Kommentaren skal registreres med kode: «dobbeltforskrivning» og tidspunktet dobbeltforskrivning ble opprettet skal settes som opprettelsetidpunkt. Kommentaren skal inneholde begrunnelsen som rekvirent skrev, og navnformstyrke på legemiddel som dobbeltforskrivningen gjelder.

3.1.31:

Begrunnelse for overstyring av varsel om interaksjon skal legges til som tekstlig kommentar på LIB-element i PLL. Kommentaren skal registreres med kode: «interaksjon» og tidspunktet skal settes som opprettelsestidspunkt. Kommentaren skal inneholde:

1. navnformstyrke og lib-id på legemiddel interaksjonen gjelder.

2. begrunnelse som er registrert av lege.

Vurdering og anbefaling

Den foreslåtte løsningen vil legge informasjon om varselhåndtering i Kode@OT elementet.

• Flere varsler for en LIB håndteres med flere spørsmål.

• FHIR lignende navn benyttes i json strukturen.

• Samme spørsmålsstruktur legges på hvert lib element som inngår i varselet.

Bruk av Kode@OT (OtherText) elementet til å bære denne informasjonen vil sikre kompatibilitet med systemer som ikke har støtte for strukturert håndtering av varsler. I disse systemene vil varsel teksten kunne leses av brukeren, men vil ikke kunne se hva som er gjort for å håndtere varsel (Kodeverdi for "Håndtering av medisinske varsel" ) , hvem som har håndtert det eller knytning mellom lib elementer.

Ved neste revisjon av meldingsformatet ønsker vi at denne informasjonen blir en del av M.25.1 meldingen.

Innhold i XML struktur (M25.1)

Dette er utsnitt av dagens XML struktur hvor vi utnytter et ubrukt attributt i kode elementet som bærer av informasjon om håndtering av varsler.

Innhold i OT (Json)

Dette er innholdet i json strukturen som legges inn som base64 enkodet tekst i kode/OT elementet.

Saken ble behandlet i Endringsforum 20.mai. Det ble stilt spørsmål fra en leverandør om hvorfor det ikke lages en ny meldingsversjon for en såpass stor endring. NHN svarte at det erfaringsmessig vil ta altfor lang tid å få implementert. Uten denne funksjonaliteten faller mye av poenget med PLL bort. Det er viktig å få det med nå, og derfor kan vi ikke vente på ny meldingsversjon.

Det var en del diskusjon rundt detaljeringsgrad og når varsler skal håndteres. NHN svarte at det ikke vil stilles krav vedrørende intern arbeidsflyt, men sikre at det skjer før oppdatering av RF.

Apotek stilte spørsmål om konsekvens for multidoseapotekene som bruker M25. NHN svarte at det benyttes et ubrukt element og at det dermed ikke skal ha noen betydning. Finansiering er nå på plass for å utarbeide en veileder for PLL. Apoteks rolle skal gås opp via veilederarbeidet.

Det ble også etterlyst en standard for hvilket nivå det skal varsles på. Dette skal gås opp. Det kan også komme opp behov for ytterligere endringer via erfaringer som gjøres i den piloten som skal gjennomføres for PLL.

Konsekvenser og avhengigheter

Konsekvenser for EPJ:

EPJ systemleverandør må implementere støtte for å kunne lese ut og presentere informasjon om håndtering av varsler.

Konsekvenser for apotek:

Avklares gjennom PLL prosjektet.

Konsekvenser for Reseptformidleren

Det er trolig ingen endring i Reseptformidleren, men løsningen må testes ene til ende.

Endringer i e-resept dokumentasjonen

[ x ] Arkitektur

[ x ] Funksjonelt

[ x ] Rekvirentkrav

[ ] Meldingsdefinisjoner

[ x ] Kodeverk

Forslag til ny eller endret tekst i dokumentasjonen

Funksjonell dokumentasjon

Beskrivelse av håndtering av varsler i PLL legges inn under meldingsbeskrivelsen av M25.1

Arkitekturdokumentasjon

Beskrivelse av meldingsformatet til håndtering av varsler i PLL legges inn under informasjonsarkitektur.

Rekvirentkrav

Rekvirentkrav må oppdateres med krav som omhandler håndtering av varsler i PLL.

Kodeverk

Det må legges til et nytt kodeverk på Volven.no for håndtering av varsler. Foreløpig forslag til innhold i kodeverket er:

Kodeverk: "Håndtering av medisinske varsel"

Krav til leveringstid

NHN ønsker å få tilslutning til prinsippet og at endringene implementeres så fort som mulig. Det ikke er en forutsetning at alle må ta i bruk løsningen samtidig.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering.