Ersa 21576: Behov for å inkludere årsak til seponering i M5

Ersa 21576: Behov for å inkludere årsak til seponering i M5

Dato

03.08.20

Ersa saksnr. / tittel

Ersa 21576 - Behov for å inkludere årsak til seponering i M5

Innmelder

E-resept produkt

Saksbehandler(e)

Trude Nordby-Bøe og Ole Martin Winnem

Ansvarlig

Hilde Lyngstad

Til behandling

Det foreslås å kravstille at årsak til seponering legges ved som merknad i tilbakekallingen av resept og at det innføres kodet informasjon i meldingen slik at mottaksystem kan behandle informasjonen

Anbefaling fra Endringsforum

Sendes til Endringsrådet for beslutning.

Endringsråd

23.09.2020

Beslutning Endringsråd

Foreslått løsning besluttes.

Innhold

Aktører

Saken har vært forelagt følgende grupper og vurdering:

[ x ] Apotek

[ ] Bandasjist

[ ] Legemiddelverket

[ X ] Rekvirent

[ ] RF

[ ] Helfo

[ ] Standardisering

[ ] FM

[ X ] Andre, RHF samarbeidsmøte

Bakgrunn

Vi vet at det er et stykke frem til alt helsepersonell har tilgang til Pasientens legemiddelliste (PLL) og derfor trenger vi å knytte seponeringsårsaken til resepten som blir tilbakekalt. Ved utprøvning av Pasientens legemiddelliste vil det fortsatt være en overgangsfase hvor ikke alle pasienter har en oppdatert legemiddelliste. For eksempel kan det være at en sykehuslege har seponert en legemiddelbehandling for en pasient mens det er fastlegen som skal initiere Pasientens legemiddelliste. Det er da behov for å dele seponeringsårsaken knyttet til tilbakekalling av selve resepten slik at fastlegen kjenner årsaken til seponeringen fra sykehuslegen.

Vurdering og anbefaling

Det anbefales å kravstille at årsak til seponering legges ved som merknad til årsak tilbakekalling, kodeverk 7500. Dette vil gi helsepersonell som behandler pasient uten PLL informasjon om seponeringsårsaken for tilbakekalt resept. Det anbefales også at det legges til kodet informasjon i meldingen slik at mottakersystem kan effektivisere behandlingen av informasjon for bruker.

 Eksempel på innhold i merknadsfeltet i tilbakekalling:

Årsak til seponering: Avsluttet behandling.

 Eksempel på innhold i OT feltet i årsak til tilbakekalling:

{     "Discontinuationinformation": {         "reason": {            "coding": {                 "system": "urn:oid:2.16.578.1.12.4.1.1.7494",                 "code": "A",                 "display": "Avsluttet behandling"             }         }     } }

Saken ble behandlet i Endringsforum 14.9. En leverandør spurte om forslaget ikke ville medføre dobling av informasjon. NHN svarte at for de pasientene som har M25 vil informasjonen fremkomme både i M25 og i tilbakekalling av resepten. Dette vil være nyttig for andre rekvirenter, og informasjonen vil bli sendt til den som har forskrevet resepten. Funksjonalitet for dette har blitt etterspurt av rekvirenter. I Kjernejournal er informasjonen tilgjengelig i lengre tid enn i RF, også før innføring av PLL. Det ble spurt om informasjonen skal sendes med slettetmelding. NHN svarte at M5 sendes som del av M7. Det ble spurt om ikke dette ville medføre mer arbeid og flere klikk for rekvirent. NHN svarte at det også i dag er krav om årsak skal oppgis, men det blir liggende lokalt i EPJ. Forslaget løser behov for tilleggsinfo som vi ikke har i dag.

Konsekvenser og avhengigheter

Fordeler ved å innføre endringen:

Årsak til seponering følger med som merknad på årsak tilbakekalling for resepten. Endringen sikrer at helsepersonell som ikke har tilgang til Pasientens legemiddelliste får informasjon om årsak til seponering av legemiddelet. Endringen er særlig viktig ved innføring av Pasientens legemiddelliste og i en overgangsfase mens PLL etableres for pasientene.

Avhengigheter:

Kravstiller at EPJ-systemer i e-resept kjeden implementerer støtte for å sende med merknad som beskriver seponeringsårsak (tekstlig) og koden for seponeringsårsak i tilbakekallingsårsakens OT-felt. Seponeringsårsaken deles da som strukturert informasjon i M5.

 Merk at verdien av endring øker når alle støtter løsningen, men er ingen forutsetning for ny løsning.

Konsekvenser for EPJ

Det må lages støtte for å legge ved seponeringsårsak som merknad i tilbakekallingen, samt at det må implementeres støtte for bruk av OT-felt for å kommunisere seponeringsårsak strukturert. Se beskrivelse under endring i e-resept dokumentasjonen for detaljer rundt hvordan dette løses. Det er forventet at endringen positivt vil påvirke andre aktører i e-resept kjeden gjennom at deres brukere får økt informasjon om grunn til tilbakekallingen. Kodet informasjon i OT-felt er forventet å ikke påvirke andre enn de som implementerer støtten.  

 Omfang av endringen:

Det kreves en liten utviklingsjobb for å legge inn informasjon i OT-felt og merknadsfelt. Det samme gjelder for å kunne forstå OT-felt informasjon som mottas.

 Konsekvenser for Apotek

Det krever ingen endring i apoteksystemene.


Endringer i e-resept dokumentasjonen

[ X ] Arkitektur

[ ] Funksjonelt

[ X ] Rekvirentkrav

[ ] Meldingsdefinisjoner

[ ] Kodeverk

Forslag til ny eller endret tekst i dokumentasjonen

Rekvirentkrav

Følgende endringer av rekvirentkrav foreslås:

Krav 2.7.5.5 utgår :

EPJ skal sette tilbakekallingsårsak i M5 til «seponert» når legemiddelbehandling i LIB seponeres og når reseptinformasjon fra ekstern kilde ikke inkluderes i LIB.

 Forslag nytt teknisk krav (erstatte 2.7.5.5):

Når en legemiddelbehandling seponeres og det sendes en tilbakekalling til RF, skal årsak til tilbakekalling være "Seponert" og seponeringsårsak være samme årsak som seponeringsårsak i PLL.

Forslag ny presisering:

Seponeringsårsak er i utgangspunktet knyttet til en legemiddelbehandling, men skal likevel benyttes for legemiddelresepter som ønskes tilbakekalt.

Hensikten er å kunne vise seponeringsårsak i en tilbakekalling slik at annet helsepersonell som ikke har tilgang til PLL får informasjon om seponeringsårsak/begrunnelse for seponeringen.  
Ved "annen årsak" til seponering kreves det skriftlig merknad som også tas med i merknad i M5.

Arkitekturdokumentasjon

Følgende endringer i dokumentasjonen for bruk av OT felt foreslås:

Bruk av Json i e-reseptmeldinger dokumenteres under informasjonsarkitektur.

Krav til leveringstid

Det vil grunnet arbeidet med SFM (Sentral Forskrivningsmodul) ikke kravstilles at leverandørene utvikler beskrevet funksjonalitet før SFM er etablert. For de leverandørene som utvikler all e-resept funksjonalitet selv kravstilles endringen sammen med oppdatert rekvirentspesifikasjon, V7.2 med ikrafttredelse senest innen 9 mnd fra saken besluttes i Endringsråd.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering.