Innhold

Aktører

Bakgrunn

Opprinnelig rekvirentspesifikasjon for e-resept ble utformet i e-reseptprogrammet med tanke på at den skulle være gjeldende for samtlige rekvirentsystemer. I utviklingsprosessen for fastlegesystemene hadde Helsedirektoratet en stor rolle som kravstiller på vegne av rekvirentene.

Rekvirentkravene ble overlevert fra e-reseptprogrammet til forvaltning. Rekvirentkravene inngår i e-reseptdokumentasjonen som NHN forvalter.

Formålet med rekvirentkravene i e-resept er å sikre kvalitet i e-reseptkjeden, slik at pasienten gis helsehjelp på en forsvarlig og effektiv måte.

Det gjennomføres en revisjon av rekvirentkravene med formål om å:

• Sikre at rekvirentkravene er absolutte e-reseptkrav og at disse er innenfor NHN/e-resept sitt ansvarsområde

• Sikre at rekvirentkravene er hjemlet i reseptformidlerforskriften eller kan utledes av forvaltningsansvaret NHN har for e-reseptløsningen

• Forbedre beskrivelsen og innholdet i kravene slik at disse blir enklere å forstå og at hensikten med kravene blir tydeliggjort

• Effektivisere godkjenningsprosessen

Arbeidet med rekvirentkrav er delt i to faser:

• Fase 1: Kategorisere rekvirentkravene i e-resept og ikke e-resept krav

• Fase 2: Forbedre utformingen, språket og tydeliggjøre hensikten med kravene

Fase 2 er planlagt behandlet i Endringsforum og Endringsråd i august/september, slik at ny versjon av rekvirentkravene vil publiseres i september 2020.

Denne saken omhandler fase 1.

Vurdering og anbefaling

Av historiske årsaker har rekvirentkravene utviklet seg til å omfatte krav til funksjonalitet som ikke er e-reseptfunksjonalitet og som ikke kan hjemles i reseptformidlerforskriften eller i NHN sitt ansvar som forvalter av e-reseptkjeden. NHN sin vurdering er at det er nødvendig å tydeliggjøre ansvarsforhold når det gjelder kravene som stilles til virksomhetene, samt tydeliggjøre hensikten med kravene for å effektivisere godkjenningsprosessen.

NHN og virksomhetens ansvar er beskrevet og konkretisert i bruksvilkår for e-resept. Bruksvilkår er publisert på nhn.no.

Saken ble behandlet i Endringsforum 20.mai. Det ble stilt spørsmål fra en leverandør om hvordan kundene og særlig medisinsk personell involveres. NHN opplyste at det er opprettet et nytt forum med alle RHF'ene hvor endringer blir diskutert. Dermed blir de involvert tidligere og kan være en bedre bestiller overfor leverandørene.

Konsekvenser og avhengigheter

Kategoriseringen av rekvirentkravene i e-resept og ikke e-reseptkrav vil medføre at omfanget av krav til funksjonalitet i rekvirentsystemene for samhandling i e-resept reduseres.

Konsekvenser for EPJ:

Kategoriseringen av rekvirentkrav medfører ikke endringsbehov for EPJ.

Konsekvenser for apotek:

Kategoriseringen av rekvirentkrav medfører ikke endringsbehov for apotek.

Endringer i e-resept dokumentasjonen

[ ] Arkitektur

[ ] Funksjonelt

[ x ] Rekvirentkrav

[ ] Meldingsdefinisjoner

[ ] Kodeverk

Forslag til ny eller endret tekst i dokumentasjonen

Denne saken omhandler kun fase 1. Etter at fase 2 er ferdigstilt vil ny versjon av rekvirentkravene behandles i EF og ER i august/september. Ny versjon av rekvirentkrav vil publiseres i september 2020.

Kategorisering av rekvirentkravene i e-resept og ikke e-resept krav er vedlagt (last ned som Excel ved å klikke på ‘sky-symbolet med pil’ oppe i høyre hjørne når du har klikket på dokumentet):

Krav til leveringstid

Ikke relevant.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering.

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.

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.