Innhold

Aktører

Bakgrunn

I prosjektet Pasientens Legemiddelliste ble kontekstinformasjon vurdert å være svært viktig som en del av samhandlingen rundt legemiddelinformasjon. Deler av denne kontekstinformasjonen er vurderinger som helsepersonell gjør i forbindelse med samstemming og legemiddelbehandling. Dette kan være vurderinger og håndteringer av interaksjoner, legemiddelreaksjoner, dobbeltforskrivninger og annen viktig informasjon om bakgrunn for medisinske vurderinger.

 Nye legemiddelbehandlinger med mulige interaksjoner, eller på legemidler som har registrerte legemiddelreaksjoner, vil stort sett være uønsket å gjøre. I enkelte situasjoner kan det likevel være faktorer som tilsier at gevinstene veier opp for eventuelle negative effekter. Denne typen behandlinger skal begrunnes i EPJ, og har i Pasientens Legemiddelliste-prosjektet vært vurdert som viktig informasjon å sende som en del av legemiddellisten.

Denne typen ekstra informasjon vil være nyttig for behandlere senere i behandlingskjeden for å skape trygghet rundt at opprinnelig behandler var bevisst på disse faktorene og tok hensyn til det, og dermed kunne spare tid på å oppsøke opprinnelig behandler for detaljer.

Vurdering og anbefaling

Pasientens Legemiddelliste vil teknisk sett realiseres gjennom M25-meldingen i e-resept. Denne består av en liste med legemiddelbehandlinger, og dekker behovene til Pasientens Legemiddelliste godt. For behovene rundt relevant meta-informasjon finnes det hovedsakelig to muligheter for realisering i dagens melding:

·         Merknadsfelt på overordnet nivå

·         «Spørsmål» knyttet til hvert enkelt LIB-element

Merknadsfelt på overordnet nivå

I M25-meldingen finnes det et tekstfelt som kalles «merknad» og som kan skrives for meldingen som en helhet. Dvs at det i praksis er et «delt fritekstfelt» som alle som sender inn meldingen kan redigere som de vil selv. Feltet kan dermed brukes til å skrive notater om innholdet i meldingen som da formidles videre i samhandlingskjeden.

Open

Spørsmålsfelt i enkeltoppføring LIB

I meldingen finnes det et informasjonselement per legemiddelbehandling som kalles «sporsmal». Dette er et valgfritt element, og det kan eksistere ubegrensede instanser av denne per legemiddelbehandling (LIB-element). Elementet ble opprinnelig implementert for å brukes til spørsmål og svar mellom lege og apotek ifbm multidosepakking.

Open

Strukturen til «sporsmal» er som følger:

Forslag til løsning

Forslag til løsning er å bruke det strukturerte feltet «sporsmal» til å angi denne typen vurderinger. Det vil si at kodeverk 7495 må utvides med nye koder. Forslaget er å opprette 4 nye koder i tillegg til dagens 5 eksisterende koder. Det vil si at nytt kodeverk vil samlet se slik ut (nye koder i fet skrift):

1. Skal varen seponeres

2. Skal varen inkluderes i Legemidler i bruk (LIB)        

3. Skal resepten fornyes           

4. Annet spørsmål         

5. Beskjed fra lege

6. Merknad om medisinsk endring

7. Merknad om legemiddelreaksjon

8. Merknad om interaksjon

9. Merknad om dobbeltforskrivning

Ettersom «sporsmal» er har en null-til-mange relasjon så kan lege legge til flere av disse på samme legemiddel. Dvs at dersom legen legger til et legemiddel som både utløser legemiddelreaksjonsvarsel, interaksjonsvarsel, dobbeltforskrivningsvarsel og det er en medisinsk endring, så skal det fra EPJ legges til 4 «sporsmal»-elementer til det legemiddelet som utløste dette. 

For merknader knyttet til dobbeltforskrivninger og interaksjoner er det viktig at systemene linker til begge elementer det er relevant for, da dette er merknader som hører til en relasjon mellom to LIB-elementer mer enn enkelt-elementene for seg selv. Dette er det ikke teknisk støtte for å gjøre strukturert i meldingen i dag, men forslaget er at EPJ automatisk kan linke dette sammen ved semi-strukturert tekst i merknadsfeltet (altså automatisk sette inn tekst om sammenhengene mellom hvilke legemidler varslene gjelder).

Ulemper ved foreslått løsning

Denne løsningen, med alle nyanser og muligheter, er potensielt komplisert å implementere på en enkel og god måte, men ettersom man nå utvikler SFM vil denne kompleksiteten i stor grad håndteres gjennom den løsningen og det prosjektet én gang. Et annet punkt som taler mot denne løsningen, er at det er noe misvisende at feltet i dag kalles «sporsmal» i meldingen (vises ikke til brukere av systemet, men kan forvirre teknisk personell og utviklere). Dette kan man vurdere å endre i fremtidige versjoner av M25.

Forslag til implementering

Forslaget til implementering og realisering av dette legger opp til en del automatikk i EPJ. Det er i dag allerede krav om varslinger for alle disse variantene, og tanken er å bygge videre på denne varslingslogikken, men også ta med merknadsfeltene inn som en del av varslingen.

Som vist i eksempelet under er dette måten man varsler interaksjoner m.m. i Forskrivingsmodulen i dag. Dette vises øverst i høyre hjørne i registreringsvinduet. Den foreslåtte løsningen legger da opp til at bruker skal kunne legge til kommentarer til varslene slik at dette kan videreformidles til neste behandlinger i samhandlingskjeden. Dette kan for eksempel løses ved at man legger inn «kommentar til XYZ» (XYZ = ulike varsler) tilsvarende som skjermbildet under lar bruker registrere «kommentar til legemiddelbehandling». 

Figur 1 – Eksempel på varsler ved registrering av ny legemiddelbehandling

Det kan òg være aktuelt å kunne legge til denne typen merknader fra oversiktsbildet i EPJ-en, slik som illustrert under. Da ved å klikke på et av symbolene som åpner vindu med mulighet for registrering av kommentar og merke dette som håndtert. Dette vil da følge meldingen videre.

Figur 2 – Eksempel på visning av varsler i LIB-vindu

Figur 3 – Eksempel på registrering av merknad knyttet til interaksjoner

Visningen av informasjonen må òg oppdateres, slik at varslene vises sammen med tilhørende kommentar. Varslene skal fremdeles vises som tidligere, men det er viktig at kontekstinformasjonen og merknaden vises sammen med varselet.

Måten dette realiseres på vil avhenge fra EPJ til EPJ, men prinsippene skal være gjeldende for alle. Målet er at systemet skal gjøre dette så enkelt som mulig for bruker, med automatiske kommentarer f.eks., samt at det skal bli tydelig sammen med informasjonen.

Saken ble behandlet i Endringsforum 14.mars. Anbefalingen var at den sendes til Endringsrådet for beslutning. For SFM sin del er det viktig å få avklart løsning. E-helse kommer tilbake med realiseringstidspunkt.

Konsekvenser og avhengigheter

Dette er i praksis «kun» en kodeverksendring, men medfører noen funksjonelle betraktninger for systemene for at dette skal fungere optimalt for brukere. Det er viktig at registreringen av disse merknadene gjøres som en naturlig del av arbeidsflyten. Det vil f.eks. si at registrering av interaksjonsvurdering bør gjøres i tilknytning til varselet og håndtering av dette, og ikke som et eget steg i etterkant for dokumentasjon (se skjermbilde-eksempelet fra Forskrivningsmodulen).

Konsekvenser for EPJ

EPJ vil som et minimum måtte utvikle støtte for nye koder, herunder visning og videresending av disse kodene. Dette skal i utgangspunktet være dekket av dagens spesifikasjoner, da kodeverksendringer ikke er å regne for nye krav. I tillegg skal EPJ støtte registrering av informasjon tilknyttet kodene. Dvs at bruker skal kunne legge til en merknad om f.eks. interaksjonsvarsel med tilhørende kommentar. Dette skal da legges til et LIB-element og sendes med M25 videre.

Deretter bør EPJ tilrettelegge for en god arbeidsflyt rundt dette. Forslaget fra Direktoratet er at merknader skal legges til i samme arbeidsflyt som visning og håndtering av varsler. Dvs at bruker skal kunne skrive en merknad/kommentar til et varsel, og så vil dette automatisk legges til LIB-elementet med korrekt kode avhengig av hvilket varsel som utløste det. Da EPJ-er har løst dette på ulike måter, er det vanskelig å komme med noen generelle krav som dekker dette godt nok.

Konsekvenser for Apotek

Apotek får ingen direkte endringer som følge av dette sett fra krav-siden, men ift hva som er implementert i Farmapro vil det bli noen endringer. Den største er vurderingen av hvorvidt M25 skal vises for alle apotekansatte ved oppslag. Denne endringen forsterker behovet for at det prioriteres ytterligere.

Kort oppsummert medfører dette følgende for apoteksystem:

• Apotek bør implementere støtte for les og vis M25 for andre enn pakkesentraler (iht opprinnelig spesifikasjon). Inkludert varsling om merknader

• I henhold til dagens spesifikasjon, men med nye koder: Håndtere mottak og visning av flere varianter av merknader i M25-meldingen, samt flere merknader per LIB-element

• I henhold til dagens spesifikasjon, men med nye koder: Håndtere videreformidling av merknader i M25.2 og M25.3

Endringer i e-resept dokumentasjonen

[ ] Arkitektur

[ ] Funksjonelt

[ ] Rekvirentkrav

[ ] Meldingsdefinisjoner

[ X ] Kodeverk

Forslag til ny eller endret tekst i dokumentasjonen

I kodeverk 7495 – Kommentarer til oppføring i LIB gjøres følgende endring:

Endringen medfører IKKE endring av spesifikasjon eller øvrig dokumentasjon, men er tvert imot nødvendig for at kravene skal kunne realiseres på en hensiktsmessig måte. De relevante kravene er angitt i tabellen under. Vær oppmerksom på at det, avhengig av hvordan helheten av legemiddelmodulen er implementert i EPJ, kan være andre krav der dette også vil være relevant. Listen under er derfor ikke å anse som uttømmende, men som et utgangspunkt for arbeid.

Krav til leveringstid

EPJ og Apoteksystem må verifisere at de håndterer kodeverksendringen ved mottak og videresending av melding. Dette er ihht tidligere spesifikasjoner og er kun å anse som en verifiserende test. Dette må være testet og/eller bekreftet innen 30.april 2019.

Følgende case er viktige:

1. Meldingsinnhold:

• Kode 6 (medisinsk endring), 7 (legemiddelreaksjon), 8 (interaksjon) og 9 (dobbeltforskrivning), og alle med tilhørende kommentar

2. Test av mottak og visning av dette i EPJ'ene.

3. Test av at dette videresendes i ny M25.1 fra EPJ (og M25.2/M25.3 fra apotek)

Implementering av registrering av merknader, kan avventes til SFM. Det vil grunnet arbeidet med SFM (Sentral Forskrivningsmodul) ikke kravstilles at leverandørene utvikler beskrevet funksjonalitet før SFM er etablert.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering.