Tabellen under angir grensesnittene mot FEST. FEST oppdateres fra saksbehandlingssystemet hos Direktoratet for medisinske produkter (DMP) og med informasjon fra Helfo og Farmalogg. Helfo, Farmalogg, EPJ- og Bandasjistsystemene henter data fra FEST.

FEST vil være basert på ikke-krypterte formater siden det kun er offentlig tilgjengelig informasjon i FEST.

Grensesnitt mot DMP (Athene)

Dette er grensesnittet fra saksbehandlingssystemet hos Direktoratet for medisinske produkter (DMP til FEST. Saksbehandlingssystemet oppdaterer alle data i FEST unntatt medisinsk forbruksmateriell og næringsmidler til medisinsk bruk og strukturert dosering. Legemiddelinformasjon produseres i Athene. En egen applikasjon for generering og kvalitetssikring av FEST er utviklet, Apollon. Apollon genererer FEST ved å importere data fra Athene og andre kilder, og sette informasjonen sammen til M30-meldingen.

Grensesnitt mot Helfo

FEST oppdateres med informasjon om medisinsk forbruksmateriell og næringsmidler til medisinsk bruk fra produkt- og prislisten til Helfo. Helfo er ansvarlig for å kvalitetssikre informasjonen før den sendes til FEST. Helfo oppdaterer produkt- og prislisten en gang per kvartal, med mulig ekstra oppdatering hver måned. DMP mottar data på M30-format fra Helfo via ebXML.
Gamle data av medisinsk forbruksmateriell og næringsmidler til medisinsk bruk slettes før nye filer oppdaterer FEST. Inkrementell oppdatering av rekvirentsystemer medfører derfor at all informasjon om medisinsk forbruksmateriell og næringsmidler til medisinsk bruk lastes opp i ny versjon. Historikk utover den historikken som ligger i filene fra Helfo vil heller ikke være tilgjengelig fra FEST. Helfo har datomerking på varer som skal utgå. Varer som er utgått er tilgjengelig for inkrementell nedlasting i FEST med status utgått i 2 år for å ivareta historikk uten annen informasjon enn oppførings-id. Varene fra Helfo har unike varenumre, også for parallellimporterte varer.
Helfo legger inn fra-dato og til-dato på alle priser. Det vil kunne være en tidsperiode på ca. 14 dager hvert kvartal hvor en vare ikke har en nåværende pris. Partene (bandasjist, apotek og rekvirent) sikrer nåværende pris. Spesielle regler og begrensninger gjelder på enkelte varer fra Helfo, for eksempel begrensning på antall som kan utleveres per år. Disse begrensningene er strukturert i dataene fra Helfo.
Rekvirent skal kunne forskrive på varegruppenivå og på varenivå – i spesielle tilfeller. Kobling mellom varegruppe og varenummer er derfor med i oppdateringene fra Helfo på en slik måte at det kan forskrives på varegruppenivå med tilgjengelig informasjon om refusjoner.
Kodeverket for produktgruppe vil tilgjengeliggjøres fra Helfo til kodeverkskatalogen i FEST.

Grensesnitt mot EPJ-systemene

Dette grensesnittet gjelder mellom FEST og EPJ-installasjonene på legekontorer og sykehus. Legekontorer og sykehusinstallasjonene skal først sende ut forespørsel om å hente en kopi av FEST. Første utsendelse fra FEST er et fullt sett av data. Deretter er oppdateringer inkrementelle. Ved inkrementell nedlast av FEST, benyttes det en variant av M30 hvor IDREF er erstattet med string. Dette gjelder xsd for M30 og Forskrivning.
Det skal sikres at data fra FEST kommer riktig inn i EPJ og benyttes på korrekt måte ved forskrivning. Rekvirent må se det som signeres før sending av resept. Det må sikres at data i M1 er korrekt i forhold til gjeldende M30. Spesielt må det sikres rutiner ved gjenbruk av gamle resepter (konvertering av data) som grunnlag for forskrivning, slik at det baseres på aktuelle FEST-data. Kontroller og funksjoner for dette skal lages i EPJ.
EPJ-systemene må konfigureres slik at de automatisk initierer en WebService-dialog med FEST. Figuren nedenfor viser hvordan en slik WebService-dialog er tenkt.


Figur 20 – Oppdatering av EPJ-system
Beskrivelse

• EPJ-system sender forespørsel om oppdatering med tidspunkt på når det sist ble oppdatert.

• FEST sender inkrementelle dataoppdateringer tilbake til EPJ-systemet

Alternativ beskrivelse 1

• EPJ-systemet sender forespørsel om oppdatering med ugyldig eller svært gammelt tidspunkt på når systemet sist ble oppdatert.

• FEST sender samtlige data til EPJ-systemet

Inngangskriterier
EPJ-systemet trenger å bli oppdatert og sender forespørsel om oppdatering til FEST.
Utgangskriterier
FEST har sendt data til EPJ-systemet.

En gang i året eller ved behov bør EPJ-systemet også kunne oppdateres fullstendig. En slik oppdatering bør være på samme formatet som en inkre mentell oppdatering, (bortsett fra at IDREF ikke er erstattet med string) men vil ha med all informasjon fra FEST.
Protokoll for WebService-dialog med EPJ-systemene avklares med EPJ-leverandørene.

Grensesnitt mot bandasjist

Dette er grensesnittet mellom FEST og bandasjistsysteminstallasjonene ute hos den enkelte bandasjist.
Installasjonene av bandasjistsystemene oppdateres med WebServices-dialog på samme måte som EPJ-systemene. Eneste forskjell er at bandasjistsystemene kun har tilgang på medisinsk forbruksmateriell og næringsmidler til medisinsk bruk, samt sterilt saltvann i en egen variant av M30-meldingen. Det er egne WebService-kall for bandasjistsystemene som kun returnerer produkt, medisinsk forbruksmateriell og næringsmidler til medisinsk bruk. Oppdateringen av medisinsk forbruksmateriell og næringsmidler til medisinsk bruk er ikke inkrementell. Enten overføres alle data fra FEST til bandasjistinstallasjonen eller så er det ingen oppdateringer.

Grensesnitt mot apotek/Farmalogg

Apoteksystemet får tilgang til FEST-data via Farmalogg. FEST-data hentes av Farmalogg i forbindelse med vareoppdatering hver 14. dag.
Informasjon fra Farmalogg som skal inn i FEST importeres til DMPs saksbehandlingssystem Athene. Informasjonen overføres ved bruk av XML. DMP utfører en rekke kontroller for å sikre at informasjon i Vareregisteret og FEST samsvarer. Handelsvarer merket Multidose hos Farmalogg, eksporteres til FEST der de merkes som kosttilskudd. DMP kontrollerer varenummer mellom importen av M30 fra NAV og fra Farmalogg. Dersom det mottas samme varenummer fra begge kilder avvises forekomsten fra Farmalogg (den fra NAV skal brukes videre i M30).
Når samme varenr finnes både som handelsvare og legemiddel, så kan denne varen finnes i begge katalogene.