29.4 safest planlegging arkitektur · 29.4 safest planlegging- arkitektur v1.0 2 versjon dato...
TRANSCRIPT
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
29.4 SAFEST planlegging- Arkitektur v1.0 2
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
29.4 SAFEST planlegging- Arkitektur v1.0 3
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
29.4 SAFEST planlegging- Arkitektur v1.0 4
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.
29.4 SAFEST planlegging- Arkitektur v1.0 5
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
29.4 SAFEST planlegging- Arkitektur v1.0 6
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.
29.4 SAFEST planlegging- Arkitektur v1.0 7
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.
29.4 SAFEST planlegging- Arkitektur v1.0 8
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
29.4 SAFEST planlegging- Arkitektur v1.0 9
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
29.4 SAFEST planlegging- Arkitektur v1.0 10
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å.
29.4 SAFEST planlegging- Arkitektur v1.0 11
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.
29.4 SAFEST planlegging- Arkitektur v1.0 12
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.
29.4 SAFEST planlegging- Arkitektur v1.0 13
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.
29.4 SAFEST planlegging- Arkitektur v1.0 14
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.
29.4 SAFEST planlegging- Arkitektur v1.0 15
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.
29.4 SAFEST planlegging- Arkitektur v1.0 16
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.
29.4 SAFEST planlegging- Arkitektur v1.0 17
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):
29.4 SAFEST planlegging- Arkitektur v1.0 18
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
29.4 SAFEST planlegging- Arkitektur v1.0 19
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.
29.4 SAFEST planlegging- Arkitektur v1.0 20
1..1
1..1
1..*
1..1
1..*
1..*
1..*
29.4 SAFEST planlegging- Arkitektur v1.0 21
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.
29.4 SAFEST planlegging- Arkitektur v1.0 22
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
29.4 SAFEST planlegging- Arkitektur v1.0 23
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.
29.4 SAFEST planlegging- Arkitektur v1.0 24
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.
29.4 SAFEST planlegging- Arkitektur v1.0 25
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
29.4 SAFEST planlegging- Arkitektur v1.0 26
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
29.4 SAFEST planlegging- Arkitektur v1.0 27
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å.
29.4 SAFEST planlegging- Arkitektur v1.0 28
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.
29.4 SAFEST planlegging- Arkitektur v1.0 29
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.
29.4 SAFEST planlegging- Arkitektur v1.0 30
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.
29.4 SAFEST planlegging- Arkitektur v1.0 31
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.
29.4 SAFEST planlegging- Arkitektur v1.0 32
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
29.4 SAFEST planlegging- Arkitektur v1.0 33
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.
29.4 SAFEST planlegging- Arkitektur v1.0 34
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
29.4 SAFEST planlegging- Arkitektur v1.0 35
Kravnr Overordnet prioritering
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
29.4 SAFEST planlegging- Arkitektur v1.0 36
Kravnr Overordnet prioritering
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.
29.4 SAFEST planlegging- Arkitektur v1.0 37
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)
29.4 SAFEST planlegging- Arkitektur v1.0 38
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.
29.4 SAFEST planlegging- Arkitektur v1.0 39
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
29.4 SAFEST planlegging- Arkitektur v1.0 40
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