Innhold

Aktører

Bakgrunn

Dagens løsning for å søke om individuell stønad (M2/M12-meldingene) er lite egnet for så hyppige endringer som det er i regelverket på dette fagområdet. Videre har mange leger praktiske utfordringer med å fylle ut dagens søknad, og de må fylle ut unødvendig informasjon da M2-meldingen består av et generisk skjema hvor alle felter må fylles ut. Løsningen er også lite egnet for automatisering i Helfos regelmotor.

Helsedirektoratet og Helfo lanserer ultimo januar 2020 ny løsning for å søke om stønad på blå resept. Denne skal erstatte dagens M2/M12. Ny søknadsløsning består av tre API-tjenester på Helsenettet, og HelseId benyttes for autentisering.

Tjenestene gjøres tilgjengelig direkte i EPJ via sentral Forskrivningsmodul (SFM). Som følge av forsinkelser i SFM, at SFM Basis API ikke inkluderer ny søknadsløsning, og at alle EPJ-leverandører ikke vil ta i bruk SFM blir løsningen også gjort tilgjengelig via følgende to kanaler:

• Som API-tjenester for EPJ-leverandører som ikke skal benytte SFM eller som skal benytte SFM Basis API

• Via sikker webbasert portaltjeneste tilgjengelig for helseaktørene

Foreløpig dokumentasjon av de tre API-tjenestene ligger tilgjengelig på Helfos nettside.

Helsedirektoratet har lagt til grunn at det vil ta tid før løsningen kan tilbys fullt integrert i EPJ.  Samfunnsgevinsten med ny søknadsløsning er vesentlig, med mer effektiv forvaltning og mindre ulempe for pasientene. Sammenlignet med dagens M2 er det en sannsynlighetsovervekt for at legene vil bruke tilsvarende eller mindre tid i samlet søknadsprosess med ny søknadsløsning. Helsedirektoratet vurderer derfor å bruke sin forskriftsfestede fullmakt til å fastsette en plikt til at legene må sende søknad via portalløsning inntil løsningen er integrert i EPJ. Spørsmål om plikt vil bli endelig avklart i månedsskifte november/desember.

Fagdirektørene i RHF er positive til ny løsning i portal, men ønsker snarlig EPJ-integrasjon. Legeforeningen er prinsipielt mot fagløsninger utenfor EPJ, og har satt opp følgende ønsker for at løsningen skal være akseptabel i portal

• Ny løsning skal være bedre enn den gamle i sum, både i enkelhet og krav til tid brukt for hele prosessen inkl. pasientinformasjon. 

• Løsning må være integrert i naturlig arbeidsflyt knyttet til skriving av resept, nødvendige pasientdata må automatisk hentes fra EPJ

• Søknad sendt må automatisk skrives tilbake til EPJ som korrespondanse/dokument

• Man må se i e-reseptbildet ved senere forskrivning/fornying at søknad er innvilget/avslått med dato

• Svar på søknad må komme rett tilbake til forskriver automatisert uten behov for manuelle rutiner.

• Data i EPJ må gjenbrukes slik at man slipper skrive inn på nytt

 Helsedirektoratet er i dialog med ulike EPJ-leverandører for å se om det er teknisk og praktisk mulig å innfri noen av Legeforeningens ønsker som en midlertidig løsning fram til løsningen tilbys fullt integrert i EPJ.

Se også vedlagte notat:

Vurdering og anbefaling

Helsedirektoratets vurdering

Ny søknadsløsning ansees som sikker, samfunnsøkonomisk viktig, og mer effektiv for legene enn dagens løsning i EPJ (M2). Dette på tross av at løsningen ikke blir integrert i legene EPJ-systemer fra start.

Leger som i dag benytter papirsøknader må benytte ny søknadsløsning via portal fra lansering ultimo januar 2020. Dersom Helsedirektoratet innfører plikt til å bruke ny søknadsløsning også for leger som i dag benytter M2, vil plikten inntre fra 1. april 2020.

Oppsummering fra behandling i Endringsforum 25.11:

Det var enighet om at en integrert søknadsløsning enten via SFM eller som API-tjeneste er ønsket. Dette er en klar forbedring fra dagens regime hvor det må gjøres meldingsendringer.

Det ble uttrykt skepsis til:

• trinn 1 (deaktivering av kode pr 1.4.20 slik at det ikke er mulig å sende søknad via M2-meldingen). Skepsisen skyldes både tidsaspektet, prioritering opp mot andre ønskede endringer som også haster, og at det kan være kostbart å utvikle, teste og rulle ut til alle installasjoner, spesielt i RHF'ene. Helse Nord hadde ikke anledning til å delta i møtet, men sendte en skriftlig tilbakemelding i forkant hvor de uttrykte: "Konsekvensene av et eventuelt pålegg synes ikke tilstrekkelig belyst og i tillegg bør tidsaspektet revurderes."

OG

• trinn 2 (midlertidig  løsning med delvis integrasjon mot portalløsningen). Skepsisen til punkt 2 er særlig en bekymring for at midlertidige løsninger blir en sovepute, og at EPJ-leverandører som ikke skal benytte SFM da ikke vil prioritere å utvikle en fullintegrert løsning.

Helsedirektoratets vurdering om å fastsette en plikt for legene til å sende søknad via portalløsning inntil løsningen er integrert i EPJ ble også diskutert.  Det ble kommentert at dette vil bli en stor utfordring for legene. Når det gjelder utfasing av M2 mener E-helse at dette må besluttes av e-resept Endringsråd og ikke av Helsedirektoratet alene siden det berører e-reseptkjeden.

Helsedirektoratet har i etterkant av Endringsforum hatt møte med DIPS og Helse Nord RHF, med Direktoratet for e-helse om FM og med HOD. Disse møtene understøtter diskusjonene i Endringsforum.

På bakgrunn av disse møtene vil Helsedirektoratet legge opp til å ikke ta imot M2-søknader fra Q3/20.

Konsekvenser og avhengigheter

Konsekvenser for EPJ:

Trinn 1

Innføres plikt til å ta i bruk ny søknadsløsning må alle EPJ-leverandørene fra tidspunktet plikten inntrer (1. april 2020) har deaktivert kode, slik at legene ikke lenger har mulighet til å sende søknad via M2-meldingen. Fortrinnsvis bør det også være en lenke til portalen i reseptforskrivningsbildet i legenes EPJ.

Trinn 2

Alle EPJ-leverandører må i samråd med RHF-ene eller Legeforeningen vurdere ønske og behov for en eventuell midlertidig løsning med delvis integrasjon mot portalløsning, fram til løsningen tilbys fullt integrert i EPJ. Helsedirektoratet står til disposisjon for å diskutere tekniske løsninger.

Trinn 3

EPJ-leverandørene som ikke skal benytte SFM eller som skal benytte SFM Basis API må legge inn implementering av ny søknadsløsning i sine planer.

Konsekvenser for apotek:

Vedtaksspørringstjenesten (en av API-tjenestene i ny søknadsløsning) vil også bli gjort tilgjengelig for apotek og bandasjist via portal fram til tjenesten blir fullt integrert i EIK og bandasjistenes løsninger.

Helsedirektoratet vil ha egen dialog med Apotekforeningen og BNU om dette.

Endringer i e-resept dokumentasjonen

[ ] Arkitektur

[ ] Funksjonelt

[ x ] Rekvirentkrav

[ ] Meldingsdefinisjoner

[ ] Kodeverk

Rekvirentspesifikasjonen er allerede oppdatert i henhold til ny søknadsløsning, og ble vedtatt i forrige møte i Endringsrådet.

Forslag til ny eller endret tekst i dokumentasjonen

Ikke relevant.

Krav til leveringstid

Gitt plikt for legene om å ta ny søknadsløsning i bruk fra 1. april 2020, så må funksjonalitet for å hindre innsending av M2-søknader (deaktivering av kode) være på plass til dette tidspunktet.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering for deaktivering av kode da det er lagt til grunn at denne endringen har lav økonomisk konsekvens.

Innhold

Aktører

Bakgrunn

Endring i FEST M30 som kan ha konsekvenser for mottaker. I februar 2019 produksjonssatte Legemiddelverket ny modul for å legge bedre til rette for virkestofforskrivning. Det oppstod noen feil utover våren som var krevende å rette. Legemiddelverket har nå funnet og rettet underliggende årsak til feilen. Rettelsen vil påvirke mottakere på samme måte som ved produksjonssetting av virkestofforskrivning i februar, men for vesentlig færre preparater.

Legemiddelverket initierer ikke full ekstern test da dette er samme endring som ble håndtert i forkant av produksjonssetting av virkestofforskrivning i februar 2019.

Konkret dreier endringen seg om at legemidler som inneholder to virkestoff og skal ha ATC-kode registrert på hvert enkelt virkestoff i noen tilfeller har manglet dette siden februar til tross for at ATC-koden er lagt inn i Legemiddelverkets database. Det samme gjelder legemidler der Legemiddelverket har registrert en alternativ styrke, så har en håndfull av disse manglet den ekstra styrken i FEST. Etter 30. januar skal alle legemidler der dette er lagt inn også ha denne ATC-koden og den ekstra styrkeverdien (alternativ styrke) med i FEST. Det er ingen endring i ordinært styrke-felt.

ATC-kode på enkeltvirkestoff brukes i sykehus-systemer.

Eksempel på legemiddel med manglende ATC-kode på enkeltvirkestoff (ATC-kombipreparat) er Laxabon.

Vurdering og anbefaling

Saken har ikke vært behandlet i E-helse.

Konsekvenser og avhengigheter

Etter denne feilrettingen vil det være en del legemidler som tidligere delte samme VirkestoffMedStyrke under oppfVirkestoff i Fest-meldingen, men som nå har fått tildelt hver sin ID for VirkestoffMedStyrke. Dette er fordi innholdet i VirkestoffMedStyrke for disse preparatene ikke skal være lik i henhold til dataene i Legemiddelverkets interne database, Athene. Data som er ulike gjelder ATC_kombipreparat og hvorvidt alternativ styrke er angitt eller ikke.

Som følge av endret ID for noen VirkestoffMedStyrke, så vil de aktuelle LegemiddelMerkevare inneholde endret referanse til ny VirkestoffMedStyrke.

Ettersom endring av ID for VirkestoffMedStyrke gjaldt alle preparater ved Legemiddelverkets produksjonssetting i februar-19, og nå vil gjelde kun en andel av preparatene, så anser Legemiddelverket at det ikke bør være nødvendig med en ny test av dette.

Konsekvenser for EPJ:

Konsekvens av feilrettingen er tilsvarende som endringen Legemiddelverket produksjonssatte for virkestofforskrivning i februar, bare i mindre skala. Dersom EPJ opplevde problemer i forbindelse med produksjonssettingen i februar bes de om å gjøre en selvstendig vurdering av om de trenger en testfil.

Konsekvenser for apotek:

Konsekvens av feilrettingen er tilsvarende som endringen Legemiddelverket produksjonssatte for virkestofforskrivning i februar, bare i mindre skala. Dersom EPJ opplevde problemer i forbindelse med produksjonssettingen i februar bes de om å gjøre en selvstendig vurdering av om de trenger en testfil.

Lagt til 21.11: Eventuell tilbakemelding om feil i test må være Legemiddelverket i hende før jul. Aktører som trenger testfil bør derfor be om dette innen 1.desember.

Endringer i e-resept dokumentasjonen

Ingen endring.

Forslag til ny eller endret tekst i dokumentasjonen

Ingen endring.

Krav til leveringstid

Produksjonssetting er planlagt 30.1.2020, dvs at det når mottakerne i publisering fra 15.januar.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering.

Innhold

Aktører

Bakgrunn

Reseptformidleren sjekker i dag på at HPR-nummer har 9 siffer, dvs at om det er 7- eller 8-sifret HPR forventes det at det er lagt til ledene nuller.

HPR kom tidligere som en string med 9 siffer fra SAFH (Statens autorisasjonskontor for helsepersonell) i den nattlige importen i Reseptformidleren. Dette er nå endret og det returneres en integer i HPR2 fra Helsepersonellregisteret (Grunndata).

Siden det opprinnelig behovet for å støtte at HPR kom som en 9-sifret string nå ikke er der lenger, og for å unngå at nye aktører må implementere støtte for ledende nuller, er det ønskelig vi å fjerne denne sjekken i Reseptformidleren.

Det vil fremdeles være sjekk mot at HPR i innkommende melding stemmer overens med de lokale HPR opplysningene i RF (HPR2).

HPR-nummer er nå også med i HelseID-tokenet (claim), og der oppgitt uten ledende nuller.

Vurdering og anbefaling

Direktoratet for e-helse anbefaler at endringen gjennomføres da behovet for ledende nuller har bortfalt.

Saken ble behandlet i Endringsforum 25.11. Det ble en del diskusjon. Det ble understreket fra E-helse sin side at forslaget ikke innebærer å innføre en endring i e-reseptkjeden, men å fjerne en sjekk i RF og dermed slutte å avvise resepter med HPR-nummer som ikke har ledende nuller. Spørsmålet er altså om andre aktører vil få problemer dersom selve kravet blir fjernet og det kommer resepter med HPR-nummer på 7 eller 8 siffer uten ledende nuller.

Aktørene ønsket å teste. E-helse bidrar med testdata, og sender ut nærmere informasjon.

Konsekvenser og avhengigheter

Konsekvenser for EPJ:

Hvis EPJ forventer ledende nuller i HPR der det er færre enn 9 siffer vil det kunne ha konsekvenser for om de klarer å lese HPR-informasjonen på resepter som kommer fra andre rekvirenter.

Konsekvenser for apotek:

Enkle tester på utlevering av resepter viser at dette ikke har konsekvenser for apotek (FarmaPro).

Bandasjist er ikke testet. Konsekvensene kan være at de ikke klarer å lese HPR-informasjonen på resepter og dermed ikke klarer å utlevere.

Endringer i e-resept dokumentasjonen

[ ] Arkitektur

[ ] Funksjonelt

[ ] Rekvirentkrav

[ ] Meldingsdefinisjoner

[ ] Kodeverk

Forslag til ny eller endret tekst i dokumentasjonen

Kravet om ledende nuller er ikke spesifisert i dokumentasjonen, og det er ikke behov for endring eller ny tekst.

Krav til leveringstid

Dersom det ikke skaper problemer for noen av aktørene vil E-helse endre i RF ved første mulige anledning, trolig Q2 2020.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering.