29.4 SAFEST planlegging Arkitektur · 29.4 SAFEST planlegging- Arkitektur v1.0 2 Versjon Dato Endring Produsent Godkjent 0.1 01.04.16 Opprettelse av dokumentet Trond Andre Aag,

29.4 SAFEST planlegging- Arkitektur v1.0 1

29.4 SAFEST planlegging

Arkitektur

Godkjent dato: Godkjent av Prosjekteier: Utarbeidet av:

16.9.16 Jørn Hanssen

Trond Andre Aag, Jarle Nordvik, Line Sæle


Versjon Dato Endring Produsent Godkjent

0.1 01.04.16 Opprettelse av dokumentet Trond Andre Aag,

Line Sæle, Jarle

Nordvik

0.99 24.08.16 Ferdigstilt for fremlegging i

prosjektstyret

Trond Andre Aag,

Line Sæle, Jarle

Nordvik

Jørn Hanssen

1.0 16.09.16 Formelt godkjent Jørn Hanssen


Innholdsfortegnelse 1. Innledning ........................................................................................................................... 4

1.1 Bakgrunn for prosjektet ............................................................................................... 4

1.2 Hensikten med prosjektet ............................................................................................ 4

2. Forkortelser benyttet i dokumentet .................................................................................... 5

3. NIKT FA sine arkitekturprinsipper .................................................................................... 6

4. Bakgrunnsinformasjon ....................................................................................................... 7

4.1 FEST ............................................................................................................................ 7

4.2 Farmalogg .................................................................................................................... 8

4.3 M30-meldingen ........................................................................................................... 9

4.4 F5 ............................................................................................................................... 11

4.5 SPOR ......................................................................................................................... 13

4.5.1 Prosjektplan ........................................................................................................ 14

4.5.2 Arkitektur ........................................................................................................... 15

4.5.3 Nye oppføringer i SPOR .................................................................................... 16

4.5.4 Krav til aktører som produserer og dispenserer legemidler ............................... 18

4.5.5 Datamodell ......................................................................................................... 18

5. Løsningsforslag ................................................................................................................ 21

5.1 Målbilde ..................................................................................................................... 21

5.2 Generell måbilde beskrivelse ..................................................................................... 21

5.2.1 F5 som leveranseplattform ................................................................................. 22

5.2.2 SPOR .................................................................................................................. 28

5.2.3 Farmalogg ........................................................................................................... 30

5.2.4 Tjenesteleverandør ............................................................................................. 31

6. Tjenestegrensesnitt ........................................................................................................... 32

6.1 HL7 FHIR .................................................................................................................. 32

6.2 HL7 Structured Product Labeling og Common Product Model ................................ 32

6.3 Målbilde ..................................................................................................................... 34

6.4 Oppsummering tjenestegrensesnitt ............................................................................ 36

7. Konklusjon/Avslutning .................................................................................................... 37

7.1 Forslag til tiltak .......................................................................................................... 38

Appendix B .............................................................................................................................. 39


1. Innledning

1.1 Bakgrunn for prosjektet

Prosjektet 29.4 SAFEST planlegging er et oppfølgingsprosjekt til SAFEST prosjektet, NIKT-

tiltak 29.3, der målbildet er å realisere nasjonale løsninger med en kilde til oppdaterte

legemiddelregisterdata og strukturert legemiddelrelatert beslutningsstøtte, samt for relevant

logistikkinformasjon.

SAFEST prosjektet, NIKT- tiltak 29.3, var det tredje i rekken av NIKT- prosjekter som skulle

se på utvidelse og forbedring av FEST- registeret fra Statens Legemiddelverk (SLV). Det

første SAFEST prosjektet startet høsten 2008. NIKT har fra starten av påpekt at fokus må

være på nasjonale løsninger, der løsningen bør bygges opp rundt FEST som

hovedinformasjonskilde.

I tiltak 29.4 var opprinnelig logistikk og beslutningsstøtte en del av kravene i prosjektet.

Begge områdene ble tatt ut av tiltak 29.4, for å begrense prosjektets omfang og redusere

gjennomføringsrisiko.

1.2 Hensikten med prosjektet Hensikten med dette prosjektet er å foreslå planer for tilgjengeliggjøring av oppdatert

legemiddelinformasjon fra én kilde på nasjonalt nivå til bruk i spesialisthelsetjenesten, samt

utrede tilhørende forvaltningsmodeller for denne informasjonen.

Prosjektets overordnede mål er med bakgrunn i sluttrapport fra SAFEST, NIKT tiltak 29.3, at

spesialisthelsetjenesten kan benytte et felles nasjonalt legemiddelregister fremfor lokale

løsninger for å oppnå:

Sikker, effektiv og korrekt ordinering, istandgjøring og håndtering av legemidler i

spesialisthelsetjenesten.

Felles løsninger som fremmer kvalitet.

Prosjektet er et planleggingsprosjekt der det skal utarbeides underlag og planer for

tilgjengeliggjøring av legemiddelinformasjon til bruk i spesialisthelsetjenesten. Det ligger

ikke innenfor prosjektets mandat å avklare roller og ansvar for etablering av informasjon og

fremtidig forvaltning.

Prosjektet skal imidlertid komme med forslag til forvaltningsmodell. SLV forventes å være en

sentral aktør i forvalting rundt legemiddelinformasjon.

Underlaget fra prosjektet vil foruten forslag til forvaltningsmodell inneholde krav og

prioritering til legemiddelinformasjon samt forslag til tidsplan for tilgjengeliggjøring av denne

informasjonen. Underlaget skal legge grunnlaget for forslag til beslutning om etablering av et

gjennomføringsprosjekt.

Dette dokumentet er ett av produktene fra SAFEST prosjektet. Det bør ikke leses og oppfattes

som et enkeltstående dokument, men sees i helhet sammen med sluttrapport og kravliste til

legemiddelinformasjon til bruk i spesialisthelsetjenesten.


2. Forkortelser benyttet i dokumentet

Følgende forkortelser benyttes i dokumentet.

NIKT Nasjonal IKT Helseforetak

NIKT FA Nasjonal IKT Fagforum Arkitektur

FEST Forskrivings – og ekspedisjonsstøtte

SAFEST Sykehusapotekenes Forskrivings- og ekspedisjonsstøtte

F5 Femstjerners FEST (se forklaring i kapittel 4)

XML eXtended Markup Language

SPOR Substance, Product, Organization, Referentials

EMA European Medicines Agency

GSRS Gastrointestinal Symptom Rating Scale

GINAS Global Ingredient Archival System

GTIN Global Trade Item Number

FDA Food and Drug Administration (USA)

ISO International Organization for Standardization

IDMP IDentification of Medicinal Products

XEVPRM eXtended EudraVigilance Medicinal Product Dictionary

HSØ Helse Sør-Øst

HV Helse Vest

HN Helse Nord

HMN Helse Midt-Norge

HELFO Helseøkonomiforvaltningen

e-Resept Elektronisk Resept

HL7 Health Level 7

FHIR Fast Healthcare Interoperability Resources

CPM Commom Product Model

SPL Standards Product Brief


3. NIKT FA sine arkitekturprinsipper Prosjekter under Nasjonal IKT skal alltid vurderes etter arkitekturprinsippene som er

utarbeidet i Nasjonal IKT Fagforum arkitektur.

Arkitekturprinsippene omhandler:

Helhetlig tilnærming

o Helhetlig tilnærming skal benyttes ved vurdering av behov, endringer,

muligheter og løsninger. Dette innebærer å se på den totale nytteverdien for

spesialisthelsetjenesten og sektoren for øvrig.

Prosessorientering

o Virksomhetene skal gjennom prosessorientering (pasientforløp, øvrige

kjerneprosesser og støtteprosesser) realisere helhetlige og sammenhengende

helsetjenester, og sikre at IKT-løsninger utformes for å understøtte prosessene

Tjenesteorientering

o Tjenesteorientering skal legges til grunn ved utforming av virksomhetene og

deres IKT-løsninger. Dette gjelder for alle domener av virksomhetsarkitekturen

(forretning, informasjon, applikasjon, og teknologi).

Interoperabilitet (evne til samhandling)

o Organisatorisk interoperabilitet: Samhandlingen mellom aktørene må skje

gjennom omforente prosesser med tydelig definerte roller og ansvarsområder

o Teknisk interoperabilitet: Den tekniske kommunikasjonen i løsningen skal

baseres på kjente standarder

o Semantisk interoperabilitet: Utveksling av informasjon i løsningen skal skje

gjennom omforente, veldefinerte innholdsstandarder

Informasjonssikkerhet

o Virksomhetene skal sikre informasjonens kvalitet, konfidensialitet, integritet,

tilgjengelighet og sporbarhet

Tilgjengelighet

o Alle aktuelle brukergrupper skal ha tilgang til nødvendig funksjonalitet og

informasjon i rett form til rett tid og på rett sted.

Brukskvalitet

o Virksomhetenes IKT-løsninger skal utformes på en måte som sikrer effektivitet

og en god brukeropplevelse.

Endringsevne

o Virksomhetenes organisering, prosesser, IKT-løsninger, informasjon og

teknologi skal utformes på en slik måte at de kan understøtte endringer, og

ikke virke som begrensninger for endringer.

Informasjonsforvaltning

o Informasjon er en kritisk ressurs for virksomhetene og skal forvaltes deretter

Arkitektene i SAFEST prosjektet har jobbet med prinsippene under hele prosessen, og videre

i dette dokumentet tar vi for oss de viktigste områdene som virker inn på løsningen.


4. Bakgrunnsinformasjon Det følgende er en beskrivelse av hvordan legemiddelinformasjon i dag gjøres tilgjengelig gjennom FEST, utfordringer med dagens leveransemodell, og SLVs planer for å møte disse utfordringene.

4.1 FEST For å fremme trygg og effektiv legemiddelbruk har SLV utviklet datagrunnlaget Forskrivnings- og ekspedisjonsstøtte (FEST). I tillegg er FEST navnet på seksjonen i Avdeling for legemiddelinformasjon i SLV, som har ansvaret for forvaltningen av registeret. FEST er den sentrale kilden for legemiddelinformasjon i helsevesenet i Norge. Leger, apotek, sykehus og andre skal få oppdatert informasjon fra én kilde om varer du kan få på resept i Norge. FEST inneholder varer som kan forskrives/ordineres i Norge:

Legemidler med markedsføringstillatelse i Norge

Legemidler produsert i sykehusapotek

NAF-preparater

Uregistrerte legemidler

Kosttilskudd som selges på apotek

Handelsvarer med refusjon (medisinsk forbruksmateriell, næringsmidler, brystproteser)

SLV er forvaltningsorganet for legemiddelinformasjon, og behandler og produserer hovedmengden av innholdet. De skal sikre at data i FEST er oppdaterte, korrekte og tilgjengelige til enhver tid. Informasjonen som danner datagrunnlaget for FEST vedlikeholdes gjennom SLVs støttesystemet Athene, og gjøres tilgjengelig i FEST-databasen gjennom et annet system, Apollon.


FEST-Kjeden

Som figuren over også viser har SLV også samarbeidspartnere som tilbyr informasjon fra andre relevante områder tilknyttet legemidler. Farmalogg, Helsedirektoratet og HELFO er blant de viktigste av disse samarbeidspartnerne.

4.2 Farmalogg Apotekforeningen og de tre apotekgrossistene har en avtale om forvaltning av et felles vareregister for apotekbransjen. Vareregisteret omfatter med få unntak alle varer som omsettes i apotek, og det inneholder opplysninger som er nødvendig for sikker og effektiv håndtering av varen i hele verdikjeden fra produsent/leverandør, via grossist og detaljist, til sluttbruker. Farmalogg er eid av Apotekforeningen, og har ansvaret for driften av Vareregisteret. Registeret videreselges av Farmalogg til sluttbrukere i bransjen (f.eks. apotek og statistikkfirma). Varenummer opprettes i samarbeid med Nordisk nummersentral.

Vareregisteret - Farmalogg

Systemet til apotekene, FarmaPro, mottar informasjon om legemidlene sine og andre apotekvarer fra vareregisteret. Farmalogg og FEST synkroniserer opplysningene seg imellom, slik at samme informasjon om de samme legemidlene finnes i begge systemene. Standard


oppdateringer gjøres den 1. og 15. hver måned, men ekstraordinære oppdateringer kan forekomme ved kritiske feil.

4.3 M30-meldingen Distribusjon av data fra FEST skjer i dag gjennom meldingsformatet M30, i form av en XML-fil som gjøres tilgjengelig for nedlasting og import. Informasjonen er der strukturert inn i ulike kataloger, som hver inneholder et subsett av informasjonen om legemidlene, eller annen støtteinformasjon (f.eks. kodeverk). Katalogene er også delvis overlappende, og bruken av dem forutsetter utstrakt bruk av kryssreferanser mellom kataloger.

Katalogstruktur i M30-meldingen

SLV har etter hvert sett at de har problemer med å dekke kundenes behov gjennom strukturen som meldingen har i dag. Løsningen ble i utgangspunktet utformet for å dekke behovene til e-resept, men bruksområdet til informasjonen har i etterkant stadig blitt utvidet. Nye kundegrupper og bruksområder har kommet til (f.eks. kurveløsninger i spesialisthelsetjenesten), og en har forsøkt å dekke nye behov innenfor de eksisterende rammene. Dette har medført at strukturen har blitt svært kompleks og tung å vedlikeholde og endre, og en har fått problemer med å forutsi hvilke konsekvenser ulike endringer vil få for ulike kunder. Dette har i noen tilfeller ført til alvorlige feil hos kunder ved oppdateringer. En har


hatt tilfeller der en har hatt problem med å få nye legemidler til markedet, fordi oppdateringer feiler og må rulles tilbake. SLV mener selv at det ikke er mulig å drive videre utvikling på dagens format uten å enten introdusere uakseptabelt høy risiko, eller å bruke uforholdsmessig mye tid og ressurser på endringene. De har derfor besluttet at de vil satse på å gjøre informasjonen tilgjengelig på en ny plattform, og det kommer ikke til å bli gjort flere endringer eller utvidelser av datamodellen som FEST i dag leveres på.


4.4 F5 Grunnet vanskene med å levere FEST i henhold til meldte behov via dagens XML-format (M30-meldingen), har SLV startet prosessen med å endre leveransemodellen for FEST-registeret. SLV planlegger å tilby informasjonen i registeret som åpne, lenkede data. De har kalt det nye formatet «Femstjerners FEST», forkortet «F5». Fem stjerner henviser til nivå 5 i Tim Berner Lee’s klassifiseringsmodell for åpne data.

Tim Berners-Lee’s Five Star Model

På nivå 5 i modellen (åpne, lenkede data) er det lagt til rette ikke bare for å kunne dele egen informasjon, men også for at en skal kunne linke informasjonselementer til informasjon fra andre relevante kilder og at andre kilder skal kunne linke inn til informasjonen. Slik blir det mulig å bygge dynamiske informasjonsmodeller der informasjonskilder enkelt kan legges til, byttes ut, eller fjernes. SLV planlegger slik at registerinformasjonen og datagrunnlaget som forvaltes av SLV i FEST skal kunne linkes og utvides med relevant informasjon fra andre kilder, for å kunne dekke nye meldte behov. De ønsker også å kunne bruke dette til å tilby ulik informasjon til ulike kundegrupper. Overgangen til en modell basert på åpne lenkede data, og hvordan dette faktisk blir implementert av SLV, legger viktige føringer for løsningsarkitekturen i SAFEST. Dagens M30-melding skal leve videre i parallell med at nye tjenester utvikles. Dagens database i FEST vil bli videreført og skal i utgangspunktet danne basisen for begge løsningene. For F5 vil SLV implementere en ny informasjonsmodell, med en struktur tilpasset utvidelser gjennom linking til eksterne informasjonskilder. Denne informasjonsmodellen danner så grunnlaget for å tilby informasjonen for SLV sine kunder gjennom et tjenestegrensesnitt basert på en RESTful arkitektur.


Figuren under viser et overordnet bilde av løsningsarkitekturen slik SLV ser den for seg. Den grå boksen rammer inn elementene som SLV ønsker å ta på seg ansvaret for utvikling og forvaltning av.

SLVs arkitekturskisse for F5

Som det fremgår av figuren vil SLV ta fullt eierskap til, og forvaltningsansvar for, både tjenestegrensesnittene, den underliggende informasjonsmodellen, eventuelle utvidelser av denne modellen i form av informasjonsstrukturer og informasjon fra eksterne kilder, samt forvaltningen av selve registerdataene. Figuren viser også at tjenestene som utvikles, og informasjonen som leveres gjennom disse, skal dekke behovene til alle kundegrupper som benytter seg av registeret. Det foreligger i skrivende stund ikke fullstendige beskrivelser fra SLV av hvordan modellen helt konkret er tenkt implementert, hverken teknisk, funksjonelt eller organisatorisk. Dette arbeidet er pågående i SLV, blant annet basert på tilbakemeldinger fra SAFEST-prosjektet.


4.5 SPOR Som en oppfølging av EU direktiv 25/26 fra 2012 har European Medicines Agency (EMA)

etablert prosjektet SPOR for å etablere en felles legemiddeldatabase. Formålet med en felles

legemiddeldatabase er å ha en detaljert oversikt over alle legemidler som omsettes i EU/EØS

området for bruk på mennesker og veterinærmedisin. Dette skal også inkludere legemidler

under utprøving uten endelig markedsføringstillatelse. EMA skal også etablere API’er for å

understøtte en elektronisk arbeidsflyt og tilgjengeliggjøre SPOR data.

SPOR er inndelt i fire områder

1. Substance – virkestoff og hjelpestoff

2. Product – Farmasøytisk, merkevare og pakning

3. Organization – Produsenter, grossister og andre aktører

4. Referentials – Terminologi og definisjoner

Substance vil bli dekkes av GSRS/GINAS som er et samarbeid mellom FDA og EMA.

Direktivet pålegger alle produsenter av legemidler til å registrere legemiddelet i.h.h. til ISO

IDMP standarden i EMA sin database.

EU direktiv 2011/62 pålegger medlemslandene å etablere en mekanisme for å validere

gyldige legemiddelpakninger (sekundærpakning), når disse dispenseres fra apotek eller andre

utsalgsteder. Det skal også utformes mekanismer for å hindre manipulasjon av pakninger samt

standardisert merking av pakning. SPOR prosjektet har fått ansvaret for implementering av

direktivet. EU har også en målsetning om på sikt å kunne utveksle e-resepter over

landegrensene gjennom OpenMedicine initiativet, der SPOR vil være en forutsetning for å

utlevere farmasøytisk likeverdig legemidler i et annet land.

Fra 2004 til 2012 registrerte industrien legemidler i en forløper for IDMP, XEVPRM

(eXtended EudraVigilance Medicinal Product Dictionary), som i dag utgjør den såkalte

EMAs article 57 databasen. Denne inneholder i pr i dag ca 450 000 oppføringer med

varierende datakvalitet som må konverteres til IDMP. Dette forutsetter i stor grad manuell

farmasi vurdering, med leting i blant annet SPC (Summery of Product Characteristic). Det

jobber i 2016 ca 75 farmasøyter med konvertering og kvalitetssikring. For legemidler med

godkjent markedsføringstillatelse vil article 57 databasen utgjøre Products i SPOR

Det skal etableres tjenester som sikrer at industrien fortløpende kan levere produksjonsdata

slik at disse kan benyttes til validering av gyldige primærpakninger. Følgende ISO standarder

er etablert for å understøtte SPOR:

ISO 11238 – Substance (GinAs)

ISO 11239 – Drug forms, administration, packaging

ISO 11240 – Identification of medicinal products, units

ISO 11615 – Identification of Medicinal products, exchange

ISO 11616 – Pharmaceutical products,

ISO 16791 – Machine-readable coding of medicinal products

Spor prosjektet er inndelt i ulike arbeidsgrupper knyttet til ulike deler av

informasjonsmodellen. Arbeidet med standardisering og tilpassinger i.h.h. til ulike use-case er

i ulike faser i de ulike arbeidsgruppene., der enkelte deler er ferdigstilt. Se prosjektplan under.


4.5.1 Prosjektplan Innen første kvartal i 2019 skal alle legemidler og veterinærmedisin som utleveres/selges

kontrolleres. Hver pakning skal ha et unikt serienummer som utveksles fra produsent til en

sentral europeisk tjeneste. Serienummeret vil kun være gyldig for én dispensering/utlevering..

Tjenesten vil kun være en basistjeneste for validering av gyldige pakninger med

produksjonsdata fra industrien, uten resterende informasjonsmodell i SPOR. Etablereringen

av tjenester for å tilgjengeliggjøre informasjonselementer i SPOR data vil utvikles og

ferdigstilles i samme periode.

Det var planlagt at standarder og teknisk dokumentasjon skulle være ferdigstilt i første halvår

2016. Det er imidlertid noen forsinkelser med ferdigstillelsen av implementasjonsguider og

konvertering fra gammel til ny terminlogi. Disse er nå planlagt ferdigstilt innen utgangen av

Q2 i 2017 Elektroniske tjenester skal være operative Q1/Q2 2018, se milepælsplan under.


4.5.2 Arkitektur SPOR vil bestå av en sentral legemiddeldatabase med standardiserte API ’er. Man vil etablere

en egen løsning for å understøtte krav om kontroll/validering ved utlevering fra apotek og

utsalgssteder. Industrien må levere løpende produksjonsdata til en sentral europeisk

sentral/hub. Medlemslandene skal etablere nasjonale løsninger som understøtter både

søknadsprosess for markedsføringstillatelse, kvalitetssikring av registreringsinformasjon og

kontroll/validering av legemiddelpakning.

Den Europeiske sentralen vil ha grensesnitt mot industrien for å ta i mot produksjonsdata. Det

forutsettes etablert skalerbare nasjonale tjenester som apotek/konsumenter skal benytte til

dispensering av primærpakninger. Det er ikke besluttet hvor valideringen skal foregå i primær

og spesialisthelsetjenesten. Det kan være behov for ulik tilnærming for å kunne understøtte

ulike arbeidsprosesser i ulike virksomhetsområder.

SPOR/EMA utarbeider en standardløsning (“Blueprint”) som skal være en rask og

kostnadseffektiv løsning for å etablere nasjonale tjenester for kontroll/validering.

Medlemslandene står fritt til å implementere egenutviklede løsninger basert på aktuelle ISO

og HL7 standarder.


Det forventes en større konvertering av eksisterende data i dagens nasjonale løsninger for å

strukturere løsningene i henhold til IDMP datamodellen. Informasjonsmodellen i SPOR

overlapper i betydelig grad innholdet i dagens FEST. Det vil imidlertid være områder der det

er større informasjonsmangfold i ett av systemene. SPOR vil f.eks. kunne inneholde detaljer

på flere pakningsnivåer (endose, innerpakning, forbrukerpakning og eske) mens FEST har

doseringsinformasjon som kan mangle i SPOR.

4.5.3 Nye oppføringer i SPOR Det er planlagt en godkjenningsprosess for legemidler basert på at nasjonale myndigheter

mottar og vurderer søknad om markedsføringstillatelse. Innsendte søknad valideres i.h.h. til

datamodell i SPOR og godkjennes deretter, hvis forutsetningene for godkjenning foreligger.

EMA vil ha en kvalitetskontroll av innsendte data før endelig godkjenning og opprettelse i

SPOR. Nasjonal legemiddelmyndighet vil ha det overordnede ansvaret for kvaliteten på

registrerte data og at den er fullstendig.


Prosess for godkjenning av legemiddel

I Sverige vil Läkemeddelverket ha ansvaret for prosessen frem til godkjenning, mens

eHälsomyndigheten vil publisere godkjent legemiddel i nasjonale tjenester (se figur rundt

informasjonsflyt).

Verdikjede legemiddelregister i Sverige (to-be):


4.5.4 Krav til aktører som produserer og dispenserer legemidler EU direktiv 2011/62, 2012/25 og 2012/26 pålegger aktørene å registrere og merke legemidler

i henhold til vedtatte standarder. Oppfylling av kravene er en forutsetning for implementering

av SPOR.

Produsenter:

Må registrere legemidler i henhold til IDMP standarden.

Produsentene skal merke alle pakninger av legemidler. Primærpakning skal merkes med

følgende informasjon: GTIN, Batch, utløpsdato, serienummer og evnt. nasjonalt varenummer.

Merkingen skal være menneskelig og maskinell lesbar, der dataMetrix er valgt som

strekkodestandard for maskinell identifisering.

Industrien skal også levere oppdatert og korrekt produktinformasjon og produksjonsdata til

SPOR. Produsentene skal varsle myndighetene ved mistanke om forfalskning eller

manipulasjon.

Produsentene pålegges også å ha en mekanisme for å hindre manipulasjon av pakning.

Mekanisme/innretning er under utredning, der bl.a. en forsegling/merking er foreslått. . Det er

usikkerhet om dette eventuelt også er på plass innen Q1 i 2017

Industrien pålegges å ajourholde legemiddelinteraksjoner for et legemiddel.

Dispensering/utlevering av legemiddel:

Apotek og detaljistleddet skal sjekke at pakning er en gyldig pakning før de utleveres.

Dette leddet pålegges også å ta ut av sirkulasjon pakninger som oppfyller følgende kriterier:

1. Utgått på dato

2. Permanent eksportert ut av EU

3. Pakninger som merkes for kontroll av nasjonale myndigheter

4. Pakninger som har blitt returnert

5. Legemidler knyttet til person

En gyldig pakning er en pakning som har et serienummer som er bekreftet fra produsent, som

ikke er utlevert tidligere og ikke omfattes av kriteriene for å ta ut pakning av sirkulasjon.

4.5.5 Datamodell SPOR består av 4 domener

1. Legemidler Katalog for legemidler som benyttes behandling av mennesker eller dyr

2. Organisasjon Katalog over produsenter, markedsføringsrettighetshavere osv.

3. Stoffer Katalog over aktive virkestoff og hjelpestoffer

4. Referanse Katalog over terminologi og definisjon for legemidler og innhold


Legemidler består av følgende komponenter:

Legemiddelnavn

innhold/sammensetning - unik farmasøytisk nøkkel for et virkestoffkombinasjon

(virkestoff,form, styrke)

doseformer

enhet for dosering og administrering

pakning

markedsføringstillatelse

pakningsdetaljer

indikasjon for bruk.

Alle oppføringer av legemidler vil ha en unik nøkkel MPID

Alle virkestoff eller kombinasjon av virkestoff i kombinasjon med form og styrke vil ha en

unik nøkkel PHPID.

Alle legemidler (MPID) vil ha én unik markedsføringstillatelse knyttet til ett land, dvs samme

legemiddel vil ha ulike MPID der det er søkt i flere land. Eneste unntak for denne regelen kan

være legemidler som det er søkt om godkjenning for hele EU området.


1..1

1..1

1..*

1..1

1..*

1..*

1..*


5. Løsningsforslag

5.1 Målbilde Effektmål (fra mandat):

Mer presis ordinering vil gi færre feilmedisineringssituasjoner, øke kvaliteten i

pasientbehandlingen og redusere faren for pasientskader og dødsfall relatert til

feilmedisinering.

Færre feilmedisineringer vil redusere utgifter knyttet til behandling av dette samt

redusere antall liggedøgn.

Færre feilmedisineringer vil redusere utgifter knyttet til pasienterstatning.

Redusert tidsbruk knyttet til legemiddelhåndtering i spesialisthelsetjenesten, og

dermed mer effektiv pasientbehandling.

Behov for færre lokale forvaltningsressurser knyttet til legemiddelhåndtering innenfor

regionene.

Fagsystemer, i tillegg til kurveløsning, som benytter medikament informasjon i

spesialisthelsetjenesten kan nyttiggjøre seg data fra et felles nasjonalt

legemiddelregister.

5.2 Generell måbilde beskrivelse Det er et sterkt ønske om at FEST utvikles til å bli den sikre og gode kilden til informasjon

om legemidler, slik at uønskede hendelser kan i større grad unngås.

Med innføringen av kurvesystemer i de ulike regionene så fører behovene til at dersom SLV

ikke oppfyller ønskene/kravene til en kilde til informasjon om legemidler, blir regionene

tvunget til å finne alternative løsninger for å oppnå sitt målbilde for kurvesystemene.

Alternativene for kurvesystemene kan bli å opprette regionale registre som håndterer mangler

i FEST registeret. På den måten kan det oppstå forskjeller i de regionale løsningene, og vi vil

ikke ha en felles nasjonal løsning. Oppfølging og nye krav kan føre til fire ganger (fire

regioner) så stor økonomisk belastning i forhold til om FEST blir løsningen.

FEST registeret er en kritisk løsning for kurvesystemene. Det blir behov for strenge krav til

oppetid og responstid. Alternativet er lokal lagring av registeret slik det gjøres pr. i dag. Lokal

lagring kan benyttes i noe grad, men det er ønskelig at informasjonen om medisinene er mest

mulig oppdatert, samt at den kan hentes raskt og pålitelig.

Erfaringene fra M30 meldingene viser at det kommer stadig nye behov for

legemiddelinformasjon. FEST må kunne skaleres til å møte stadig nye behov.


5.2.1 F5 som leveranseplattform Som nevnt i tidligere kapittel foreligger det per i dag ikke fullstendige beskrivelser av

hvordan SLV helt konkret tenker at F5 som plattform skal realiseres, hverken teknisk,

funksjonelt eller organisatorisk. Dette gjør det vanskelig å gi en fullstendig vurdering av

hvordan de planlagte endringene vil påvirke spesialisthelsetjenesten som kunde av SLV.

Den overordnede modellen som har blitt presentert gir like fullt en del føringer som medfører

flere viktige indikasjoner på hvordan nåværende og fremtidige informasjons- og

funksjonsbehov kan dekkes, og hvilke utfordringer som må løses før en har etablert en ny og

velfungerende plattform for å levere legemiddelinformasjon til alle SLVs kunder.

5.2.1.1 F5, standarder og åpne lenkede data Når en ny tjenesteplattform for FEST skal implementeres bør tjenestene og

utvekslingsformatene i så stor grad som mulig baseres på internasjonale standarder. Bruk av

etablerte standarder er med på å sikre god interoperabilitet mellom systemer, minimere

implementeringskostnader, og kan bidra til at spesialisthelsetjenesten er godt posisjonert i

forhold til et internasjonalt leverandørmarked i forbindelse med anskaffelser.

Dersom proprietære formater må benyttes for enkelte tjenester, bør tjenestene i så stor grad

som mulig gjenbruke terminologi og struktur fra standardene som har blitt valgt for andre

områder, slik at de samlede tjenestegrensesnittene fremstår som helhetlige, harmoniserte og

stabile.

Det har ikke kommet klart frem av SLVs beskrivelser hvordan en i praksis tenker å

harmonisere behovet for standardiserte og forutsigbare grensesnitt og utvekslingsformater

basert på internasjonale standarder med implementering av en dynamisk og utvidbar

informasjons- og tjenestestruktur basert på åpne lenkede data.

Figur: Standarder for åpne lenkede data


At de nye tjenestene og den underliggende informasjonsmodellen skal leveres som åpne,

lenkede data innebærer blant annet at alle informasjonsstrukturer vil måtte beskrives og gjøres

tilgjengelig ved hjelp av gjeldende rammeverk og standarder for åpne lenkede data. Sentrale

standarder (W3C Recommendation) på området er Resource Description Framework (RDF)

med flere tilstøtende og underliggende standarder.

Som figuren over viser, brukes de ulike standardene til å representere data og beskrive

konsepter (RDF), vokabularer (RDF Schema) og ontologier (OWL). På basis av dette kan data

så serialiseres og gjøres tilgjengelig i ett eller flere tilgjengelige formater, for eksempel

RDF/XML eller Turtle, som er formatene SLVs testtjenester tilbyr.

Å utvikle en fullstendig representasjon av den komplette informasjonsmodellen for FEST

gjennom standardene for åpne lenkede data vil være en oppgave av betydelig størrelse.

Dersom grensesnittene og utvekslingsformatene i tillegg skal baseres på internasjonale

standarder for legemiddel- og produktinformasjon, vil en også måtte lage en fullverdig RDF-

representasjon av disse standardene som åpne lenkede data. For store deler av tjenestene vil

det trolig være nødvendig å utforme disse representasjonene fra grunnen av. Det vil også være

behov for en forvaltningsfunksjon for å oppdatere vokabularer og ontologier ved endringer i

standardene.

En implementasjon av standardene for utveksling av legemiddelinformasjon som åpne

lenkede data vil trolig også være et ukjent format for de fleste leverandører. En står dermed i

fare for å introdusere et kompliserende og fordyrende ledd, som kan redusere fleksibilitet og

interoperabilitet mellom løsninger.

Prosjektet ser det også som bekymringsverdig at det tilsynelatende er vanskelig å finne gode

referansecaser for bruk av åpne linkede data til å representere datasett med sammenlignbar

kompleksitet og bruksmønster til det som skal dekkes i forbindelse med FEST.

5.2.1.2 Aktører, behov og prioriteringer F5 skal dekke behovene til alle konsumenter av SLVs tjenester. Dette betyr at funksjons- og

informasjonsbehovene til spesialisthelsetjeneste, fastleger, pasienter, og andre aktører skal

dekkes gjennom samme plattform og innenfor samme forvaltningsregime.

Ulike aktører vil ha ulike behov, krav og interesser til tjenestene som leveres, krav som igjen

kan være knyttet til en rekke ulike egenskaper ved tjenestene. Muligheten til å bedre kunne

dekke behovene til ulike leverandører har av SLV blitt trukket frem som en av grunnene til å

etablere den nye plattformen.


Figur: Konsumenter av SLV sine tjenester

FEST-registeret som leveres i dag gjennom M30-meldingen som en statisk datafil, og andre

støttetjenester er i liten grad tilgjengelig. En har sett eksempler på at ønskede endringer og

oppdateringer har blitt stoppet på grunn av enkeltaktørers utfordringer med å håndtere

endringene. F5 vil kunne løse noen av disse utfordringene, blant annet gjennom tilpassede

tjenester og versjonshåndtering.

Samtidig etableres det gjennom F5 tjenester som skal støtte langt rikere bruksmønstre og

samhandling mellom systemer enn dagens løsning, med en fleksibel og utvidbar

informasjonsstruktur i bunnen. Dette vil trolig også bidra til at forskjellene mellom behovene

til ulike interessenter på flere områder trer enda klarere frem.

Forskjeller vil kunne gjøre seg gjeldende blant annet på følgende områder:

Behov for funksjoner/operasjoner

Informasjonsbehov

Detaljeringsnivå

Foretrukne informasjonskilder

Foretrukne formater og enheter

Krav til ytelse og responstid

Ulike aktører vil ha ulike behov knyttet til hvordan tjenestene utformes; hvilke operasjoner

som er tilgjengelige og hvilke bruksmønstre som støttes av tjenestene. Det kan være ulike syn

på hvilke standarder, referansemodeller eller kodeverk som bør benyttes. Ulike aktører vil

også kunne ha ulike behov og krav knyttet til detaljering av informasjonen, både med tanke på

detaljnivåer (hierarkisk), og presisjon på enkelte informasjonselementer eller attributter.

I tillegg til at en har ulike behov, vil ulike aktører trolig ha ulike prioriteringer av de samme

behov, krav og leveranser fra SLV. Enkelte informasjonsbehov vil kunne være kritiske for én

aktør og mer eller mindre irrelevant for andre aktører. Tilsvarende kan stabilitet, ytelse og

responstid på tjenestene være kritisk for en aktør og av mindre betydning for en annen.


FEST-registeret ble i utgangspunktet opprettet for å dekke behovene i e-reseptkjeden, noe

dagens forvaltningsmodell og endringshåndtering også bærer preg av. Forvaltningen er derfor

i dag i liten grad innrettet mot å støtte en balansert behandling og prioritering av meldte

behov, med god representasjon fra ulike aktører. Spesialisthelsetjenesten har for eksempel

ikke faste representanter i dagens endringsråd. Det forventes at forvaltningsprosessen som er

under utarbeiding av SLV vil sikre en godt balansert deltakelse fra ulike interessenter i

endrings- og prioriteringsarbeid knyttet til FEST-registeret.

Det er også slik at spesialisthelsetjenesten har høye krav til kvalitet og tilgjengelighet for all

informasjon som er nødvendig for å kunne behandle pasienter trygt og effektivt. Bortfall av

informasjon, eller alvorlige feil og mangler i informasjon som er kritisk for pasient-

behandlingen, kan introdusere uakseptabelt høy risiko for pasientskade. Prioriteringen av

SLVs aktiviteter, og kravene til den enkelte tjeneste, må derfor ikke utelukkende baseres på

hva flertallet av aktører prioriterer og har behov for, men også på basis av en vekting av effekt

og konsekvens. Disse prioriteringsmekanismene må være forutsigbare, transparente og

omforente.

5.2.1.3 Anbefaling til SLV rundt eierskap og ansvarsforhold SLV skisserer med F5 et konsept der den underliggende informasjonsmodellen enkelt skal

kunne utvides med nye informasjonselementer, og nye informasjonskilder enkelt skal kunne

kobles på. Det skal også være mulig for ulike aktører å bruke ulike kilder til samme

informasjon. For noen informasjonselementer der det per i dag ikke finnes klare kandidater til

kilder, vil det måtte opprettes fagredaksjoner som vedlikeholder informasjonen.

Figur: Ny informasjonskilde i F5


Figuren over viser et eksempel der en ny type informasjon og kilde skal legges til registeret.

Det må da analyseres hvordan den nye informasjonen kan representeres i den underliggende

informasjonsmodellen, eller om informasjonsmodellen må revideres for å dekke behovet.

Videre må en se på om endringer i tjenestelaget er påkrevd for å levere den nye informasjonen

og støtte eventuelle nye bruksmønstre. Informasjonsbehov og bruksmønstre må avstemmes

mot eventuelle andre aktører som har blitt identifiserte som interessenter i endringen, og det

må besluttes hvilken kilde som skal brukes, eventuelt om det må opprettes en fagredaksjon for

å produsere informasjonen.

Dette er en modell som stiller store krav til forvaltningsfunksjonen. Uklare ansvarsforhold vil

raskt kunne føre til at det etableres uoversiktlige nettverk av avhengigheter, som igjen kan

lede til interessekonflikter og pulverisering av ansvar. Det er derfor kritisk at alle

ansvarsforhold knyttet til forvaltningen av informasjon og kilder er helt klart definerte.

SLV må ta et overordnet ansvar for at all informasjon i registeret er pålitelig og komplett,

også der eksterne kilder benyttes. Forvaltningsfunksjonen til SLV må kontinuerlig sikre at

informasjonen som leveres gjennom tjenestene har et akseptabelt kvalitetsnivå og

tilgjengelighetsgrad. I den grad forvaltningsansvar plasseres hos andre aktører må det være

helt utvetydig hvilket ansvar disse aktørene har ovenfor både SLV så vel som andre aktører.

Hvordan forvaltningen av eierskap og ansvar knyttet til kilder helt konkret er tenkt organisert

fremgår ikke av dokumentasjonen som SAFEST-prosjektet så langt har mottatt fra SLV.

Prosjektet forutsetter at også disse aspektene av forvaltningen inngår i SLVs pågående arbeid

med å utforme den nye forvaltningsmodellen.

5.2.1.4 Oppsummering og konklusjon FEST-registeret som det i dag leveres via M30-meldingen dekker på langt nær alle av

spesialisthelsetjenestens behov. Kurveprosjektene i HSØ og HV har også avdekket problemer

med kvaliteten og konsistensen i dataene som er i registeret i dag. SLV har konkludert med at

det ikke vil være mulig å dekke nye behov i dagens melding, og at det derfor må etableres en

ny leveranseplattform, F5. I dialogen med SLV vedrørende kvalitet i registeret og

mulighetene for nye leveranser har det også fremkommet at SLVs kapasitet, etter egne utsagn,

per i dag ikke er skalert for å gjøre en tilfredsstillende kvalitetssikring av dataene i registeret,

og samtidig drive videreutvikling av registeret.

SLV har fremlagt sine planer for den nye leveranseplattformen for SAFEST-prosjektet.

Planene som har blitt presentert er av en konseptuell og overordnet art, og beskriver i liten

grad den faktiske implementeringen av plattformen, hverken fra et teknisk, funksjonelt eller

organisatorisk perspektiv.

Implementeringen av F5-plattformen i sin helhet vil ha en høy kompleksitet på flere nivåer,

og det er fremdeles en betydelig uklarhet rundt utformingen av mange kritiske elementer av

løsningen. Etableringen av en ny forvaltningsfunksjon for mottak av bestillinger og behov fra

ulike aktører, med påfølgende evaluering, koordinering og implementering, vil i seg selv være

både tid- og ressurskrevende. Design og implementering av selve tjenesteplattformen vil også

være krevende. I tillegg kommer utfordringen med å kvalitetssikre dataene som allerede ligger


i FEST, og å etablere mekanismer som sikrer konsistens og kvalitet på data fra eksterne

kilder.

Det vil trolig ta tid å bygge den nødvendige kapasiteten og kompetansen i SLV til å kunne

levere i henhold til ambisjonene de skisserer. Også andre eksterne faktorer, som SPOR-

prosjektet, er med på å skape betydelig usikkerhet i forutsetningene for hvordan F5 som

plattform kan og bør implementeres.

SAFEST-prosjektet mener SLV må ta et klart ansvar for å sikre kvaliteten på all informasjon

som skal leveres som en del av FEST. Lenking av eksterne kilder via FEST kan ikke frita

SLV for ansvar for kvalitetssikring av det som leveres. Når nye eksterne informasjonskilder

inkluderes i FEST må alle ansvarsområder knyttet til kilden være klart definerte og eierskap

entydig plassert, for å unngå etablering av uheldige avhengigheter og pulverisering av ansvar.

SAFEST-prosjektet anbefaler også at SLV i utgangspunktet ikke har et hovedfokus på åpne

lenkede data. Det bør heller fokuseres på å sikre kvaliteten på dataene som allerede ligger i

registeret, og på mulighetene for å realisere løsninger for å dekke enkelte høyt prioriterte

behov parallelt med at en etablerer den nye forvaltningsmodellen og en mer robust

leveranseorganisasjon. Fokuset bør da primært være på å levere tjenester basert på

internasjonale standarder; å tilby åpne lenkede data bør være sekundært. Dette er også i tråd

med anbefalingene fra Difi:

«Selv om viderebruksverdien øker med antall stjerner, så er vårt råd å prioritere å få ut data

på nivå tre framfor å utsette i påvente av publisering med fem stjerner.»

Når en har fått etablert den nødvendige leveransekapasiteten hos SLV, og de største

uklarhetene er ryddet av veien, kan det eventuelt vurderes å utvide til å tilby tjenester på fem

stjerners nivå.


5.2.2 SPOR

SPOR prosjektet gir et mulighetsrom til å gi legemiddelregisteret i Norge et betydelig utvidet

datagrunnlag med høyere kvalitet. SPOR vil inneholde alle legemidler som omsettes i

EU/EØS området og vil således omfatte så godt som alle legemidler omsatt i Norge.

Registrert vil også inneholde studiemedisin. Dette vil f.eks. gi mulighet for elektronisk

rapportering av bivirkninger også for studiemedisin og beslutningstøtte i forhold til

legemiddelintoleranse eller interaksjoner.

Ved å ta i bruk SPOR som datakilden vil det gi mulighet til å ta ut gevinster hos flere aktører

som er involvert i legemiddel håndtering. Det vil også gi kvalitative gevinster i

pasientbehandling, monitorering og forskning. Det vil også berede grunnen til å muliggjøre

utveksling over landegrensene for monitorering og forskning.

Standardisert og unik merking av legemidler vil være viktig for håndtering av

legemiddellogistikk, spesielt i spesialisthelsetjenesten. Innføring av standardisert merking av

legemidler i EU/EØS vil potensielt gi besparelser på ompakking/merking av legemidler som

ikke er produsert for det norske markedet. Standardisert merking er også en forutsetning for

innføring av lukket legemiddelsløyfe, uten pasientbundet dosepakking med robotpakking av

dose/multidose.

Datamodellen i SPOR understøtter et rekursivt nivå for pakning, dvs man kan ha et

ubegrenset antall nivå med pakninger med detaljert innhold pr nivå. Krav til standardisert

merking vil sannsynligvis ikke inneholde nasjonal id/varenummer eller MPID i SPOR.

For å kunne realisere en løsning som trengs for sporing og logistikk må dagens struktur i

FEST utvides til å støtte flere nivåer. I dag er det kun et felt for strekkode i FEST. SLV har

gjort en endring i datamodellen for å kunne publisere flere strekkoder i feltet for strekkode.

Det er vurdert av de regionale kurveprosjektene samt Sykehusapotekene som utilstrekkelig for

å kunne implementere en fullgod løsning for både lukket legemiddelsløyfe og legemiddel

logistikk. Sykehusapotekene har definert et behov for minst tre nivåer, tertiær, sekundær eller

primærforpakning. For lukket legemiddelsløyfe vil primær og sekundærforpakning

sannsynligvis være tilstrekkelig, mens tertiærforpakning vil være mest aktuelt for logistikk.

En løsning med felles grunnlagsdata i EU forventes å øke mulighetene til å kunne ta i bruk

standardiserte beslutningstøtte i legemiddelhåndteringen og bør kunne forenkle integrasjon

mot legemiddelregister i medikasjonsløsningene for aktørene. Man vil få et større

datagrunnlag som vil gi nye muligheter for å kunne gi pasienten riktig medikamentell

behandling og unngå overdosering.

Felles grunnlagsdata vil også gi bedre sporbarhet på legemiddelbruk og mulighet til å

overvåke eventuelle uheldige bivirkninger gjennom standardisert rapportering fra både pasient

og ansvarlig behandler.

En innfasing av SPOR i nasjonale register vil også åpne muligheten for uttak av E-resepter i

andre land i tråd med OpenMedicine initiative i EU.


Det er en del utfordringer for å innfase SPOR i FEST/SAFEST, der det kreves videre

utredning. Enkelte områder kan dette starte umiddelbart (slik som varenummer), men det er

også avhengigheter som påvirkes av selve implementasjonen i SPOR prosjektet. De viktigste

utfordringene som må hensynta er følgende:

1. Varenummer (utredes)

I dag benyttes varenummer som felles nøkkel for identifikasjon av registrerte

legemidler i Norge i ulike deler av verdikjeden. Varenummeret utstedes av Farmalogg

og benyttes av HELFO, grossist, apotek, SLV, E-resept og forskrivningssystemer til

bl.a. økonomisk oppgjør og tilknytning mot LIS avtaler. Bruk av nasjonalt

varenummer bør utredes nærmere og bør unngås der det er mulig. Sentrale nøkler som

skal benyttes i en kompleks verdikjede bør etableres/utstedes av en myndigheter, der

SLV eller HELFO ansees som potensielle aktører.

2. Unike nøkler (utredes)

Et legemiddel i SPOR (MPID) vil kunne få ny id hvis det er endringer på følgende

områder: Markedsføringstillatelse (MAH), legemiddelnavn, form og styrke,

innhold/sammensetning (inkludert hjelpestoffer) og indikasjon. Virkestoff, form og

styrke vil være et farmasøytisk produkt og ha en unik nøkkel (PhPID) i SPOR.

Farmasøytisk produkt vil ha statisk/konstant nøkkel uavhengig av endringer over.

3. Pakningsnivåer (utredes)

Athene/Fest har kun ett nivå på pakning, mens SPOR har et (ubegrenset) antall nivå.

Det er et behov for å støtte flere nivåer, det må utredes om tre nivå som foreslås av

Sykehusapoteket er tilstrekkelig. Paknings id (PCID) kan påvirkes av punktet over.

4. Datamodellen i FEST avviker fra SPOR (utredes)

SLV anbefales å utvide datamodellen i aktuelle systemer til å støtte IDMP standarden

og utvikle en datamodell og integrasjon mot SPOR som kan koble identisike

medisinske produkter, dvs merke og virkestoff, form og styrke i FEST til elementer i

SPOR. En utdyping og alternativ løsning er beskrevet i appendix B.

5. Konvertering av data i «artikkel 57 databasen» (utredes)

Prosjektet har hatt dialog med Jeffrey Martin, medlem i Task force IDMP i SPOR,

som spesielt har uttrykt bekymring rundt konvertering av gammel registerdatabase.

Martin mente at den manuelle konvertering kunne forventes å ta 5-8 år med

eksisterende ressurser. Det må derfor vurderes hvor store mangler databasen har i

forhold til de informasjonselementene SLV mottar fra Farmalogg, samt et anslag på

hvor stor andel av legemidler i dagens FEST som er berørt. En evaluering vil være av

avgjørende for når en bør gå over til ny modell for masterdata.

6. Fremdrift

SPOR er et prosjekt som har en ambisiøs fremdriftsplan. Prosjektet forutsetter både

etablering av ISO standarder, konvertering av store datamengder og etablering og

ibruktagelse av komplekse tjenester. Prosjektet er 6-12 måneder forsinket i forhold til

opprinnelig plan. Det er noe usikkerhet når man vil være endelig ferdig.


5.2.3 Farmalogg Farmalogg er i dag ansvarlig for drift av vareregister som er primærkilde til FEST. Farmalogg

har sitt utspring i en avtale mellom apotekerforeningen og tre grossister fra 2001. Det har vært

kvalitetsutfordringer på det som har blitt levert fra Farmalogg til SLV. Det er også, i følge

Statens legemiddelverk, Farmalogg som selv avgjør og prioritere endringer i struktur og

innhold i grunnlagsdataene. Dette har f.eks. resultert i at man har prioritert å ta inn nye

varegrupper som har hatt prioritert av apotekene fremfor å prioritiere ernæring som er viktig

for løsningene i sykehuset. Det vurderes som prinsippielt uheldig at en aktør, som er eid av

markedsaktører, har en premissgivende og sentral rolle i et virksomhetskritisk og

virksomhetsovergripende nasjonalt register.

Det synes derfor fornuftig å vurdere en alternativ informasjonsflyt for legemiddelregister, der

SPOR får en autorativ rolle for legemidler som inngår i SPOR. Oppføringer og innhold i

FEST/SAFEST bør følge en verdikjede der Statens legemiddelverk i siste ledd garanterer for

kvaliteten, mens autorativ kilde vil være der den tidligst oppstår i verdikjeden under.

Farmalogg har i dag en avtale fra mars 2015 med SLV om å levere grunnlagsdata for

legemiddelregsiteret. Pr 2016 så er det 38 dataelementer som utveksles fra Farmalogg til SLV.

Det forventes at SPOR vil mangle 10-15 av dataelementene (angitt i appendix A). Disse

vurderes å ha relativt lav betydning for spesialisthelsetjenestens bruk av FEST registeret.

Avtalen mellom SLV og Farmalogg forplikter SLV til å publisere data i FEST med samme

kvalitet/innhold som levert av Farmalogg. Grossist og apotek benytter FEST for å oppdatere

interne varekateloger. Det er uheldig at SLV ikke kan gjøre kvalitetsforbedrende tiltak før

man publiserer oppdateringer i FEST og denne restriksjonen bør avikkles så raskt som mulig.

Handelsvarer vil ikke inngå i SPOR og har således behov for alternativ autorativ kilde. Det er

også tvilsomt om naturlegemidler og plantebaserte legemidler dekkes av SPOR på kort sikt.

Eksisterende avtale med SLV og Farmalogg bør reforhandles hvis de strukturelle endringene

som anbefales gjennomføres.


5.2.4 Tjenesteleverandør I Sverige har Läkemeddelverket ansvaret for register og registerkvalitet i nasjonal

legemiddeldatabase, tilsvarende Athene i Norge. eHälsomyndigheten har imidlertid ansvaret

for bruk av registerdata i ulike tjenester ut til konsumenter, slik som apotek, E-resept,

spesialisthelsetjenesten, Tandvårds- och läkemedelsförmånsverket (TLV) og

legemiddelindustrien. eHälsomyndigheten tilsvarer Direktoratet for e-helse i Norge. Enkelte

av kravene til nye tjenester identifisert i SAFEST prosjektet krever kliniske vurdering og

fagredaksjoner. Det er for prosjektet uklart hvordan SAFEST skal kunne finansieres og

forvaltes med SLVs mandat og dagens ressurser. SAFEST prosjektene har vært kjørt for å

hjelpe SLV med å konkretisere og prioritere behov fra spesialisthelsetjenesten. SLV har

manglet ressurser til å kunne utføre dette arbeidet i egen organisasjon.

Direktoratet for E-helse har et overordnet ansvar for å bidra til nasjonal innsats, styring og

samhandling i sektoren og forvalte løsninger. Direktoratet har et fagmiljø og

kompentaseprofil som passer bedre til utvikling og forvaltning av en sentral tjeneste for

mange aktører i sektoren. Det bør derfor vurderes om det bør skilles på eier og produsent av

grunnlagsdata og tjenesteleverandør for sammensetning av legemiddel-, kliniske og

farmasøytiske data, som er ambisjonen i SAFEST. En tilsvarende modell er valgt i Sverige,

der det skilles på publiseringsansvar og eier av grunnlagsdata. Prosjektet vurderer dette som

en mer robust og bærekraftig løsning på sikt og anbefaler at det gjøres en vurdering rundt

eierskap og publiseringsansvar.


6. Tjenestegrensesnitt SLV har skissert en løsning hvor aktører i helsetjenesten i Norge skal få meldinger på det

formatet som er ønskelig.

Det vil i lang tid fremover være behov for å levere dagens M30 melding, mens nye behov for

informasjon fremtvinger nye meldingsformat. Dagens M30 melding har i lang tid skapt

utfordringer rundt nye krav, da meldingen ikke er skalerbar.

For å skape en mer skalerbar løsning har SLV satset på åpne lenkede data slik tidligere

beskrevet. Ved bruk av åpne lenkede data legges data tilgjengelig på REST rammeverket.1

6.1 HL7 FHIR HL7 (Health Level 7) er en internasjonal standard for utveksling av data i helsesektoren.

FHIR (Fast Healthcare Interoperability Resources) er HL7 sin siste satsning på neste

generasjons standard. FHIR kombinerer det beste fra tidligere standarder (v2, v3 og CDA) og

har fokus på utviklersiden – resurssene skal være enkle å ta i bruk for utviklere. FHIR er den

standarden som er best tilpasset bruk sammen med REST rammeverket. Det er også en veldig

fleksibel standard.

For mer informasjon: http://www.hl7.org/fhir/summary.html

FHIR mangler ressurser som er tilpasset til bruk for medisinske registre eller ressurser som

kan erstatte Common Product Model (se neste avsnitt). Dette ligger i planleggingsløpet til

HL7, men vil ta noen år før det er på plass.

6.2 HL7 Structured Product Labeling og Common Product Model SPOR prosjektet definerer bruk av HL7 v3 Common Product Model for utveksling av data.

I tillegg skal produkter defineres med HL7 SPL (Standard Product Label). 2

Definisjon fra HL7:

«HL7 versjon 3 Structured Product Labeling ( SPL ) spesifikasjonen er en dokument standard

som spesifiserer struktur og semantikk av innholdet av autorisert publisert informasjon som

følger med former for medisin lisensiert av medisinske konsesjonsmyndigheter .

Mottakere av produktets merkings dokumenter er en person eller organisasjon, herunder

allmennheten for øvrig, eller en agent for det offentlige (for eksempel en

reguleringsmyndighet).»

SPL dokumenter er kjent som «produkt merking», «pakke vedlegg», «forskrivnings

informasjon», «produkt informasjon», «medisin informasjon» og mange andre navn.

The Common Product Model (CPM) er utviklet for å møte felles data krav på tvers av

områder (domener) innenfor HL7 som adresserer produktrelatert informasjon. Domenene av

interesse er:

1 For mer om REST: https://en.wikipedia.org/wiki/Representational_state_transfer

2 Kilde:

http://www.ema.europa.eu/ema/index.jsp?curl=pages/regulation/general/general_content_000645.jsp&mid=WC

0b01ac058078fbe2

http://www.hl7.org/fhir/summary.html

https://en.wikipedia.org/wiki/Representational_state_transfer

http://www.ema.europa.eu/ema/index.jsp?curl=pages/regulation/general/general_content_000645.jsp&mid=WC0b01ac058078fbe2

http://www.ema.europa.eu/ema/index.jsp?curl=pages/regulation/general/general_content_000645.jsp&mid=WC0b01ac058078fbe2


Farmasi: Modellens innhold trekker på Pharmcy DMIM (Domain Message Information

Model), og omfatter innholdet brukes til å støtte medisinering informasjon.

Immunisering: Det antas at dersom de medisinsk datakravene er riktig modellert vil datakrav

for immunisering være dekket i meldingen.

Pasientsikkerhet: Innholdet baseres mye på Individual Case Safety Report (ICSR). Den

medfølgende CMET (Common Message Element Type) gir en representasjon av de dataene

som trengs for å representere den produktinformasjonen som finnes i ICSR.

Strukturert produktmerking (SPL): Modellens innhold baseres også på SPL

RMIM(Refined Message Information Model) modellen, og omfatter innholdet som brukes til

å støtte merking rapportering.

Stabilitet Rapportering Modellen innhold omfatter strukturer og egenskaper som trengs for

å støtte produktinformasjon for stabilitet rapportering. Opprettelsen av en CMET å støtte

behovene til denne rapporteringen er ventet å bli utforsket.

Fakturering og regnskap Foreløpig inneholder «Fakturerbare Kliniske Varer»- CMET

relevant produktrelatert informasjon.

Stoffer Det er nå to temaer dedikert til definisjonen og spesifisering av stoffer (små

molekyler, polymerer, proteiner, nukleinsyre, naturlige blandinger og komplekse stoffer).

SLV bør sjekke ut om dette blir et grensesnitt som kan og bør benyttes også i Norge.

Dersom det allerede er på plass gode grensesnitt i forhold til en internasjonal standard bør det

i stor grad etterstrebes å benytte disse i motsetning til proprietære særnorske grensesnitt.

Bemerk: I SPOR/svar fra SLV henvises til ISO standarder. ISO har gjennomgått og godkjent

SPL. Det arbeides med CPM.


6.3 Målbilde

7, 8, 10, 12, 13, 14, 15, 17, 19, 20, 21, 22

Numre i rødt er enten veldig usikre eller ikke leverbare i forhold til svar fra SLV.

Forklaring til målbildet:

Figuren viser hvilke krav som kan leveres innefor M30 samt innenfor F5. Noen av kravene

kan leveres på begge format.

Krav markert med rød kant er veldig usikre pga mangel på kilde av data.

Kravlisten:

Kravnr Overordnet prioritering

av krav

Hovedkrav

1 HØY Datakvalitet Registerdata må være strukturerte, konsistente,komplette

og kvalitetssikrede

2 HØY Katalog virkestoffordinering Katalog for virkestoffordinering må fylles med innhold

3 HØY Legemiddelformer Informasjon om legemiddelform må være tilpasset behov

ved generisk ordinering

4 MEDIUM Oppbevaring etter istandgjøring Informasjon om oppbevaring og holdbarhet av legemidler

etter istandgjøring



av krav

Hovedkrav

5 HØY Vaksiner og immunglobuliner

Informasjon om vaksiner, diagnostika, immunglobuliner

og sera må være tilgjengelig

6 HØY ATC-koder ATC-koder må være tilgjengelig for alle virkestoff og

preparat

7 LAV Krav utgår

ATC-koder Det bør være mulig å ha flere ATC-koder for flere

indikasjoner/bruksområder per produkt

8 MEDIUM Administrasjonsvei Informasjon om administrasjonsvei må være tilgjengelig

for alle produkt

9 HØY Styrkeangivelse Angivelse av styrke (evt. alternativ styrke) må relateres til

mengde virkestoff pr enhet/dose

10 MEDIUM Utblandingsvæsker Informasjon om utblandingsvæske(r) for aktuelle

produkter må være tilgjengelig

11 MEDIUM Oppbevaringsbetingelser Informasjon om oppbevaringsbetingelser for produkt, jmf.

gjeldende standard, må være tilgjengelig

12 HØY Preparatomtale. Tilgang til preparatomtale for preparat som benyttes til

pasientbehandling

13 MEDIUM Hjelpestoff Informasjon om hjelpestoffer i legemidler/andre produkter

må være tilgjengelig

14 HØY Strekkode Elektronisk lesbar ID, f.eks. strekkode, på ulike

pakningsnivå må være tilgjengelig

15 HØY Ernæring Informasjon om produkt og produktinnhold for

ernæringsmidler som benyttes til parenteral eller enteral

pasientbehandling, må være tilgjengelig

16 HØY

Blodprodukter Generisk varebetegnelse- informasjon om blod- og

plasma-produkter må være tilgjengelig

17 HØY

Blodprodukter Pakningsinformasjon for blod- og plasmaprodukt med data

om pakningsstørrelser og styrker, må være tilgjengelig



av krav

Hovedkrav

18 HØY Knusing/deling Informasjon om hvorvidt perorale legemidler kan knuses,

deles og/eller administreres via sonde, må være

tilgjengelig

19 LAV Naturpreparater/kosttilskudd Informasjon om naturpreparater og kosttilskudd må være

tilgjengelig

20 LAV Start- og kombinasjonspakninger

Relevante registerdata for start-/ kombinasjons-pakninger

må være tilgjengelig

21 LAV Legemiddel utseende Informasjon om legemidlets utseende -fortrinnsvis for

tabletter og kapsler- må være tilgjengelig

22 MEDIUM Katalog byttegruppe

Informasjon om byttbarhet for preparater som i stor grad

benyttes i spesialisthelsetjenesten, må være tilgjengelig

6.4 Oppsummering tjenestegrensesnitt På grunnlag av valget rundt REST rammeverket som tjenestegrensesnitt så bør SLV se

nærmere på mulighetene innenfor HL7 FHIR. Vi i Norge bør være pådrivere for å få til en

løsning basert på FHIR, og bidra inn mot arbeidet internasjonalt.

I tillegg må SLV se til SPOR prosjektet og gjenbruke de meldingene som legges til rette for

der. HL7 v3 standarder har ofte en høyere terskel for implementering (jref – Direktoratet for

eHelse sitt prosjekt for gjennomgang av internasjonale standarder). Likevel kan denne

terskelen minskes dersom SPOR prosjektet får produsert gode implementasjonsguider.


7. Konklusjon/Avslutning

Arbeidet rundt arkitektur i SAFEST prosjektet har vist seg å være en stor oppgave. Detaljene

rundt løsninger som er valgt og prosjekter som påvirker løsningen bør og skal være SLV sitt

ansvar. Arkitektene i SAFEST prosjektet etterlyser mer grundige evalueringer og

gjennomganger på løsninger som er valgt av SLV. Vi har valgt å belyse løsningene som

virker kraftig inn på leveransen, slik at risikoene og usikkerhetene blir belyst.

Basert på våre gjennomganger så ser vi klare utfordringer til SLVs valg av arkitektur rundt ny

FEST løsning. Vi ønsker å utfordre dem på valget om åpne lenkede data og håper at

oppklaringer rundt dette kan gi større forankring for valget som er tatt.

Det som er viktigst for spesialisthelsetjenesten er at vi får korrekte og utfyllende opplysninger

fra FEST. Vi ønsker at FEST skal bli den ene kilden som gir informasjon om legemidler.

Vi ønsker også å kunne hente dataene på en standardisert og sikker måte, mot systemer som

har strenge krav til oppetid.

Målet bør være å levere tjenester på HL7 FHIR, evnt HL7 Common Product Model.

Forslag til alternativ modell for eierskap for SAFEST. (figur)


7.1 Forslag til tiltak Etablere en masterdatamodell for FEST med IDMP/SPOR som kjernedata og

oppdatere dagens avtaler i.h.h. til denne.

Etablere en implementasjonsguider for HL7 CPM/FHIR for ulike kataloger for FEST.

Etablere en felles identifikator for bruk i hele verdikjeden.

Etablere katalogen for virkestoffordinering.

Innføre støtte for flere pakningsnivåer i eksisterende datamodell.

Etablere et skille på tjenesteansvar for SAFEST og eier av legemiddelregisterdata.

Etablere en forvaltningsmodell for fagnettverk.

Etablere en tjeneste som støtter spesialisthelsetjenestens behov for

ernæringsinformasjon, spesifisert i vedlegg til kravliste fra prosjektet.


Appendix A

Informasjonsfelt I

SPOR Kommentar

Varenummer

PCID (pakningsid) vil kunne erstatte varenummer på sikt

Erstatningsvarenummer

Handelsnavn X

Varebetegnelse

Markedsføringsstatus X

Kvantum X SPOR inneholder pakningsdetaljer, kan avvike noe fra dagens definisjoner

Enhet for kvantum X SPOR inneholder pakningsdetaljer, kan avvike noe fra dagens definisjoner

Styrkeangivelse X

Legemiddelform X

Utgåttdato grossist

Varegruppe nummer

ATC-kode X

Ekstra info

Produsent/innehaver av MT X

Vare endret dato (X) Usikkert

Multidose

Reseptgruppe X Usikkert

Markedsføringsdato X

Pakningstype X SPOR inneholder pakningsdetaljer, kan avvike noe fra dagens definisjoner

Multippel

Antall

Mengde

Enhet for mengde

Enhet for dosering X

Administrasjonsvei X

Virkestoff tekst

Strekkode innerpakning

Strekkode (EAN-kode) X

Bruksområde

DDD

Statistikkfaktor

Oppbevaring X Er planlagt i en sen leveranse

Virkestoff med styrke X

Virkestoff Id X

Virkestoff navn X

Styrke X

Styrke nevner X

ATC kombipreparat

Appendix B

Fest har i dag en datamodell der pakninger har en relasjon både på legemiddelDose- og

LegemiddelMerkevare-nivået. Prosjektet har ikke diskutert bakgrunnen for at man har valgt

en slik modell med SLV. Det kan derfor være utfordringer eller avhengigheter i datamodellen

som gjør at det kan være vanskelig å endre dagens design.

Det anbefales at man gjennomgår datamodellen på nytt og ser på muligheten til å fjerne

relasjon til pakning fra legemiddeldose og endre relasjon mellom Legemiddeldose og


Legemiddelmerkevare til «en til mange». Legemiddeloppføring i SPOR vil da tilsvare

LegemiddelMerkevare, som bør utvides til å inkludere markedsføringstillatelsedetaljer med

landkode. Det vil også være strukturellt fornufitg å legge en referanse til virkestoff fra

legemiddeldose da dette er det høyeste nivået. Dette vil påvirke de fleste som bruker FEST i

dag og vil være en stor endring. Det må derfor gjøres en vurdering hvor stor konsekvens det

vil ha for konsumentene. Det kan være et alternativ å utvide legemiddeldose og beholde

eksiterende relasjon på legemiddelmerkevare.

Eksisterende datamodell i FEST:

Legemiddeldose LegemiddelMerkevareLegemiddelpakning

Virkestoff/Hjelpestoff

Datamodell som understøtter SPOR:

Legemiddeldose LegemiddelMerkevare LegemiddelpakningVirkestoff/Hjelpestoff

Farmasøytisk produkt

Documents

29.4 SAFEST planlegging Arkitektur · 29.4 SAFEST planlegging- Arkitektur v1.0 2 Versjon Dato Endring Produsent Godkjent 0.1 01.04.16 Opprettelse av dokumentet Trond Andre Aag,