Du benytter en nettleser vi ikke støtter. Se informasjon om nettlesere

Vedlegg A - Innspill fra aktørene

Aktørene har gitt innspill på nytte og kostnader, som i dette vedlegget er kort gjengitt for hvert av alternativene.

Alternativ A - Nasjonal oversettelsestjeneste

Nytte:

  • Lite nytte
  • Vil antakelig ikke ta i bruk alternativet
  • Begrenset nytte, men muligens ta i bruk i kurveintegrasjon, avhengig av hva løsningen blir
  • Kan det bety noe for legemiddelmangel?
  • Enklere å ta ut resepter i utlandet og håndtere oversettelsen Norge/EU.

Kostnad/ulempe:

  • Lite/ingen kostnad, men unødvendig og RHF-ene burde kunne løse dette selv
  • Vil antakelig ikke ta alternativet i bruk,  så dermed lite kostnader, men viktig steg på vei til C
  • Evt. noe kostnad for ibrukstakelse i kurveintegrasjon
  • Permanent mapping kan/vil være uheldig, pasientrisiko ved feil oversettelse.
  • Må levere refusjonsdata som i dag inn til FEST. For eksempel: ny produkt- og prisliste, må levere på både FEST og ISO-IDMP. Lite/ forskjell fra nullalternativet. Men gir usikkerhet for hva som blir løsningen framover, at man låser seg enda sterkere til FEST, og at man kan bremse utviklingen på H-resept eller andre som sikter seg mot ISO-IDMP. Må bygge på gammel teknologi framfor ny som er smidigere.
  • Mapping er ofte/alltid en dårlig/midlertidig løsning. 1:1-mapping begge veier ikke mulig. Krever mye oppfølging, mappingforvaltning.
  • Redusert datakvalitet.
  • Økt vedlikeholdskostnad? Ja, feil må fanges opp et sted manuelt.
  • Virker som store forvaltningskostnader for liten gevinst.
  • Risikofylt. Fare for feil og mangler. Bør bare være i en overgangsfase.

Alternativ B: Ny nasjonal grunndatatjeneste, frivillig bruk

Nytte:

  • Kan være noen gevinster i forbindelse med produksjon og vedlikehold av grunndataene.
  • FEST kan baseres på ny grunndatatjeneste.
  • Gir for brukerne mye av samme nytte som C, bare at man ikke får direkte informasjonen fra reseptene. Må gjøre mappingen internt begge veier
  • IDMP-basert legemiddelregister gjør det lettere å ta i mot søknader om legemidler og integrasjon mot SPOR
  • Får data inn på samme format som det skal ut igjen og kan unngå oversettelses, som er feilkilde og ineffektivt.
  • Bredere datagrunnlag som støtter prosessene, unngår duplisering.
  • Legemiddelmangel kan bidra til å legge til rette for mer Virkestoffordinering og underbygge bruk av phpID.
  • Enklere tilgang til ureg. legemidler, enklere å planlegge innkjøp og logistikk. Enklere saksbehandling
  • Bivirkningsovervåkning, mulige fordeler phpID.
  • Lite nytte. Får ikke samhandlingsgevinstene siden man ikke vet at alle bruker det. Kan fort bli få som tar det i bruk.
  • Hvis man tar det i bruk vil det internt i dagens systemer gi noe gevinster i samhandlingen. Men må avveies mot eksterne kostnader for samhandling. Er regional gevinst stor nok, eller bedre å vente på obligatorisk bruk.
  • Vil antakelig ikke ta alternativet i bruk
  • Mer fleksibilitet for å ta i bruk nye grunndata til beslutningsstøtte
  • Bedre enn nullalternativet. Mulighet for EPJ-leverandøren til å tilby bedre funksjonalitet. Men kommer an på hva som blir gjort.

Kostnad/ulempe:

  • Risiko for inkonsistens mellom ny og gammel tjeneste
  • Kostbart å lage ny tjeneste
  • Doble vedlikeholdskostnader til evig tid
  • Mer data det ikke er behov for, kan gi økte sorteringskostnader
  • Tilsvarende kostnad som C, bortsett fra det som har med e-resept implementering å gjøre. Pluss kostnad for mapping/oversettelse
  • Samme kostnader som i C
  • Pluss at transisjonskostnadene (her inngår også kvalitetssikring av data) ikke går over
  • Mer komplekst enn C fordi det blir evig dobbelt opp
  • Mye de samme kostnadene som i A følger med
  • Risiko for at det man tar i bruk lite hensiktsmessige (kortsiktige) løsninger som blir enda mer krevende å fikse senere.

Alternativ C: Ny nasjonal grunndatatjeneste, obligatorisk bruk. 

Nytte:

  • Bedre datakvalitet. Mulighet til å kontrollere mer ved innsending til e-resept
  • Fordel at primærhelsetjeneste og spesialist er på samme grunndatatjeneste. Reduserer risiko for feil ved samhandling og oversettelse ikke nødvendig. (forutsetter at alle bruker det og bruker det likt. Og at grunndatakilden blir god og 1:1. Vanskelig i praksis.)
  • Kan være mye potensiell nytte  sett i forhold til en bedre e-reseptløsning. For eksempel gå over til ordinasjon. Helt avhengig av hvordan det løses.
  • Muliggjør større fleksibilitet og endringsevne i e-resept og andre tjenester
  • Mye bedre sekundærbruk av data (forutsatt at det ikke blir problemer mot SNOMED).
  • Redusert kompleksitet og dermed reduserte leverandørkostnader (SAFEST, PLL, H-resept) for det som allerede gjøres i dag. Og vedlikeholdskostnader
  • Utvikling, realisering av nye behov vil være enklere, mindre kostbart. I dag en del som ikke er mulig overhodet, ingen enkeltaktør kan løse det, må gjøres nasjonalt.
  • Smidigere samhandling med kommunale helsesektor forutsetter bedre/mer avanserte løsninger, som igjen krever bedre grunndata. For mye risiko per i dag, med manuelt arbeid etc. Hver gang pasient flyttes mellom tjenestenivå, manuell samstemming.
  • Dersom informasjonen i en fornyet e-reseptløsning blir enklere tilgjengelig og mer forståelig for pasient i for eksempel Helsenorge kan det gi n Nytte ved at de kan håndtere legemidler i større grad selv, og gjøre det riktig. Mye feil gjøres i dag ved administrering hos pasient.
  • Reduksjon i feil ved legemiddelbehandling i sykehus.
  • Felles grunndata gir grunnlag for rikere og enklere samhandling på legemiddelområdet.
  • Enklere innovasjon. (Forutsetter kanskje at man forlater litt dagens reseptordninger.)
  • Mer oppdatert informasjon ved overgang til API-kall. Raskere tilgang på oppdaterte resepter? Unngår dobbeltsjekk?
  • Mulig å tenke seg en bedre nytte, enklere innføring av PLL? Hvis for eksempel hvis ordinasjoner blir bærende element i e-resept, kan dette forenkle den komplekse sammenhengen mellom PLL og e-resept.
  • Bruk av internasjonal standard øker muligheten for gjenbruk av data
  • Bedre datagrunnlag generelt
  • Slipper de problemene man har med FEST i dag. At data forsvinner ut på grunn av manglende historikk. Forutsetter en kontinuitet i ny tjeneste.
  • Mindre mappingproblemer enn det man har i dag. DIPS mot Metavision. HSØ utvikler nytt grensesnitt nå.
  • Tilgang til historikk-data som ikke finnes i FEST. Grunndata som var gyldig tidligere, men ikke nå lenger. Flere aktører lagrer nå disse data selv.
  • Tilgang til alle kodeverk, også historiske.
  • Bedre kvalitet på kodeverk. Ymse kvalitet på kodeverk i FEST i dag.
  • Får data inn på samme format som det skal ut igjen. Unngår oversettelseskostnader som er feilkilde og ineffektivt.
  • Få tilgang på rikere legemiddeldata.
  • Enklere dersom alle relevante grunndata kan hentes ett sted
  • Også internt på sykehus er det forskjeller i begrepsbruk som delvis henger sammen med ulike grunndata.
  • Mer og bedre data gir bedre beslutningsgrunnlag for kliniker
  • Reduksjon i manuelt arbeid og dobbelt oppføringer i ulike systemer
  • FEST import 4 ganger i året – 900 timers arbeide i et RHF på bare dette. Oppsett i kurvesystemet etc. Kan reduseres? Gjøres sentralt alle aktører bruker direkte
  • Sparer mye kostnader i integrasjon med felles data
  • Virkestofforskrivning mot e-resept blir bedre/rikere.
  • Redusert legemiddelfeil, 2,2 % av alle behandlinger. Pasientskadeerstatning og liggedøgn kan reduseres med bedre kvalitet på data. Flere hundre mill. kr. her
  • Lukket legemiddelsløyfe. SAFEST øker kvaliteten på dette tiltaket. Mye gevinster her, men usikkert hva som kan knyttes direkte til bedre grunndata?
  • Enklere forvaltning når man slipper å forholde seg til flere grunndatakilder
  • Mindre manuell forvaltning. Må berike og tilpasse FEST for å dekke behovene i dag. Dette var den viktigste gevinsten i SAFEST opprinnelig. 3,5 (2?) årsverk bare i HSØ. Forutsetter sentral forvaltning for kvalitet og sikkerhet.
  • Generelt vil enklere samhandling kunne gi noen fordeler
  • VSO vil muligens bli tatt i bruk
  • Større leverandørmarked
  • Kan bidra til å drive andre prosjekter framover, også i transisjonsperioden.
  • At man slipper unna dobbelt forvaltning.
  • Får mye mer grunndata og bedre kvalitet enn man har i dag. Kan dekke nye behov. I hvert fall på refusjonsiden. Vil kunne dekke de fleste behov her som har dukket opp.
    • F.eks.: Strukturert informasjon om indikasjon,
    • lik informasjon på tvers av blåresept og H-resept.
    • Leger får bedre forskrivningsstøtte.
    • Bedre etterlevelse etter innkjøpsavtaler sykehus.
  • Mer pålitelig informasjon ved administrering av medisiner. At systemene snakker bedre sammen og deler data på en god, enkel måte. Noe av dette blir kanskje bedre med PLL.
  • Men sykepleiere har ikke tilgang til resept/PLL i dag, så forutsetter at de får det og at det som vises i kjernejournal blir mye bedre enn i dag. Stor kilde til feil i dag, flest feil skjer under administrasjon. Må lete mange steder etter riktig informasjon. Medikamentene må skrives inn manuelt av sykepleierne, liste i epikrise eller melding fra lege. Er også om medisiner det er meste kommunikasjon mellom hjemmesykepleie og fastlege.
  • e-reseptene er for ustrukturerte spesielt på dosering og dette gir manuell databehandlingsjobb inn i kurvesystemet.  Kunne vært bedre med rikere grunndata.
  • Kan noen av problemene knyttet til refusjon løses samtidig?
  • Muliggjør bestilling legemidler andre land.
  • Bedre og enklere rapportering på bivirkningsovervåkning.
  • Støtter forskrivninger til andre land
  • Sparer tid for klinikere. Men ikke sikkert, fordi de må gjøre mer, høyere kvalitet.
  • e-resept mot utlandet
  • Forventer lite endring for sluttbruker. Litt bedre informasjon på legemidler grunndata, men også veødig mye data. For eksempel. Får de veldig mange treff på legemidler på søk, blir det krevende å forstå. Original, parallellimport etc. Fordel hvis historiske grunndata ikke forsvinner, som i FEST.
  • (Tilgang til alle ATC-koder med historikk. Dette forventer SAFEST å ta inn i forbindelse med H-resept tilpasning.)
  • IDMP-basert legemiddelregister gjør det lettere å ta i mot søknader om legemidler og integrasjon mot SPOR
  • Bedre grunndata vil være et viktig grunnlag for bedre EPJ-systemer framover. Og rikere funksjonalitet. Samhandlingen vil bli bedre.

Kostnad/ulempe:

  • Utvikling i EIK og PCAene, kostnader.
  • Parallelle systemer over en periode
  • Stor omskrivning av kode
  • Muligens håndtere doble datasett i lang overgangsperiode
  • Utviklingsarbeid. Regner med SAFEST kommer til å levere dataene. Må integrere seg med dem uansett. Så på sikt ikke så mye jobb fordi dette allerede er gjort på det tidspunktet. Gitt at det blir tett opp til SAFEST.
  • Investeringskostnader for få grunndata over i ny løsning
  • I transisjon: DMP må lage den nye grunndatakilden når Athene skal bort, men i en overgangsfase fortsatt produsere FEST.
  • Utvikle DELE og SAFEST og sammenhengen mellom disse.
  • Legemidler fra SNOMED/FEST i dag har tatt mange år å innarbeide. Vil kreve omarbeiding. (Dersom internasjonal standard forblir førende for nasjonal løsning kan Epic måtte forholde seg til det og dekke kostnaden med utvikling)
  • Utviklingskostnader i mange systemer. Tilberedning, administrasjon, produktdata. Berører hele legemiddelkjeden i sykehus (og i apotek). Mange berøres
  • Etablere nye systemer for å ta imot data. Men bedre med ett grunndatasystem enn flere.
  • Legge om infrastruktur og tilpasninger mellom systemer
  • Mye rikere modell som kan dekke flere kliniske behov. (men mye kommer ikke automatisk med ISO-IDMP, krever en beslutning om at relevante data tas med)
  • Virkestoffordinering blir enklere og kan gjøres bredere når det blir PHPID basert. Kan gjøres helt uavhengig av produkt. Billigste alternativ kan velges på en enklere måte ved utlevering.
  • Samhandling internt i HSØ, DIPS og Metavision, blir enklere og tryggere. Høyt prioritert av leger og sykepleiere. Viktig for å ta i bruk PLL på en god måte.
  • Kostnader knyttet til implementering av SAFEST i systemene i HSØ den største kostnaden, og her er det 20 systemer. DIPS, Metavision, fødesystem. MKB. Akuttmottak (AMK) m.m..
  • SAFEST  må utvikles utover det som ligger i SAFEST gjennomføring idag. Data i FEST må konverteres og gjøres tilgjengelig. Refusjoner må knyttes til ISO-IDMP. Interaksjonsdatabasene. Kodeverk.
  • IDMP-overgang i DIPS til ny e-reseptløsning.
  • Opplæring av 8000 leger og 30000 sykepleiere i nye systemer. Opplæring i kurvesystemet, innleggelser etc. endres.
  • Risiko for feil i konverteringen av strukturerte data, pasientsikkerhet. Dosering etc.
  • Spesifisering- og utviklingskostnader for å tilpasse interne systemer for å ta imot nye grunndata
  • Utviklingskostnader internt i regionen
  • Forvaltningskostnader, går de opp eller ned? Antakelig ikke mindre, men vil gi mer nytte. Også hos eksterne.
  • Opplæringskostnader internt i regionen
  • Mapping til/fra FHIR kan være kostnadskrevende
  • Dobbeltforvaltning i transisjonsperioden.
  • Refusjonsdata må bygges på ny også på blåreseptdata (størst for DMP?)
  • Tilrettelegge for å sende data på riktig struktur, FHIR.
  • Vil kunne bli vesentlig opplæringskostnader. Forsøke å unngå mest mulig i utformingen av tiltaket

Siste faglige endring: 10. januar 2025