Møte 10 i FHIR fagforum

  • Dato: 2022-02-02
  • Klokkeslett: 1300-1500
  • 69 deltakere (innom møtet)

FHIR fagforum (FFF) er et åpent forum om bruk og implementering av HL7 FHIR i Norge. FFF er åpent for alle.

Agenda

  1. Velkommen og presentasjonsrunde, Thomas T Rosenlund, Direktoratet for e-helse (5 min)
  2. Informasjon fra HL7 Norge, Øyvind Aassve, Sykehuspartner (5 min)
  3. SFM og FHIR erfaringer, Dag Hammer Norsk Helsenett (30 min)
  4. Webmed integrasjon med SFM og erfaringer, Jarle Hjortland, Webmed (30 min)
  5. Ibruktakelse av SAFEST i et nasjonalt perspektiv, Elin May Merry og Bernd Moeske, Helse Sør-Øst (30 min)
  6. Oppsummering fra WGM, Øyvind, Espen og Thomas (10 min)
  7. Eventuelt

Presentasjoner

HL7 Norge - Øyvind AAssve

  • Neste møte WGM er i mai, tilbud om å delta fra HL7 Norge også sponsing
  • Appointment og Encounter fra HL7 Norge basisprofil arbeidet, høring i februar
  • Seminar med John Moehrke siste halvdel av februar om IHE XDS ved bruk av IHE MHD
  • Profileringshierarkiet - internasjonale, basis, domene og implementerte profiler
  • Pågående aktiviteter knyttet til basisprofiler
  • Intro til legemiddelområdet - implementert FHIR grensesnitt i mange prosjekter og kontekster - SFM, SAFEST og Kjernejournal
    • Spent på hvordan dette skal henge sammen - spilt inn til Direktoratet for e-helse

SFM og FHIR erfaringer, Dag Hammer Norsk

  • Ønsket å ha en presentasjon sammen med SAFEST, men SAFEST kunne dessverre ikke stille denne gangen
  • Modul for legemiddelbehandling i EPJ
    • Oppslag mot kjernejournal, RF og andre moduler for å presentere og gjennomføre forskrivning
    • Tilgjengeliggjør informasjon om forskrivning gjennom FHIR API
  • Samhandling med nasjonale systemer er kompleks
  • SFM Basis API for å skape kommunikasjon mellom EPJ og PLL
  • SFM Datadeling API med fullversjon (GUI), gir tilgang til mer informasjon strukturer fra PLL?
  • Hvorfor ikke SMART on FHIR app? SMART vil ha tilgang til data i EPJ, SFM lagrer egne data og har kun minimalt behov for kontekstinformasjon fra EPJ
  • Dokumentasjon av FHIR API - SIMPLIFIER og GitHub
    • synkronisering mellom Github og SIMPLIFIER er ikke stabil nok, krever endel manuell interaksjon
  • Forge - for å profilere, selve profileringen må læres
  • no-basis Patient benyttes som grunnlag for sfm-Patient direkte og det har fungert fint
  • XMLSpy som verktøy for XML
  • SFM Basis API - PLL dokument - testverktøy for å teste API
    • Funksjonalitet for å arbeide med pasienten og legemiddellisten - SFM Basis API testverktøy med GUI
  • FHIR Server for Azure ble valgt da den kom (istedenfor egenkomponert) - Det var en god avgjørelse
    • Tilgjengelig i Azure som plattform eller som OpenSource som man kan drifte selv på egen plattform
    • Kom sent
    • Problemer med UTF, regex problem, non-breaking-space feilet i validering
    • SFM har businesslogikk bak dataelementer - Ikke Swagger?
  • Mange extensions - utvidelser fordi man måtte tilpasse den norske resepten (som er strøm på papir)
    • Mye profilering - mange tilpasninger
  • Har blitt inspirert mye av arbeidet med FHIR IPS
  • MedicationBundle (BasisAPI) er et dokument (Bundle av type composition) med veldefinerte seksjoner som har definert forskjellig type innhold
  • Datadeling (API for SFM Fullversjon) mer REST basert
  • Benyttet .NET FHIR API, noen andre benytter rammeverk basert på Delphi
  • Testsystem tilgjengelig på internet, integrasjon med HelseID
  • Oppfølging av leverandører
  • MedicationStatement - 4.0.1 forsvinner i R5?
    • Hva skjer ved overgangent til R5
  • Helseplattformen og Meona skal ta ibruk BasisAPI, SFM er på lufte

Spørsmål

  • Da kan sectionDispense kanskje på sikt også inneholde dokumentasjon fra utleveringer som gjøres med digitale hjelpemidler - digitale medisinskap, medisindispensere o.l. Hvor hentes data fra til denne seksjonen?
    • Ikke tenkt på automatisk utlevering i utgangspunktet
  • REST vs Operations?
    • Operations fungerer helt fint i FHIR server fra Microsoft
    • EPJ er vanligvis ikke REST i natur, da er det
  • Er det diskutert om administrering også kunne være i SFM?
    • Ja løpende diskusjon om dette, ikek i scope nå
  • Autentisering og autorisering av brukere samme som kjernejournal?
    • Det er samme struktur og logikk, ikke personnummer og info i samme kall

  • Samarbeid med Webmed og helseplattformen - valgte Patient istedenfor sfm-Patient - spesifikk i forhold til å referere til eksakte profiler

  • Er løsningen med sentral forskrivningsmodul/PLL vurdert opp mot Medical Device Regulation?
    • Jeg vet heller ikke hvordan dette stiller seg, men jeg vet at “A Medication Module” i et EPJ eksplisitt er beskrevet at er medical device. MDCG 2019-11 s. 19. https://ec.europa.eu/health/system/files/2020-09/md_mdcg_2019_11_guidance_en_0.pdf

Webmed integrasjon med SFM og erfaringer, Jarle Hjortland, Webmed

  • To kunder live, ønsker rulle ut til 100 kunder
  • Lite kunnskap om FHIR i utgangspunktet
    • Krever mer enn ren Open API
  • Dokumentasjonen er ikke nøyaktig, hvilke felter i et API kall er påkrevet?
    • Hva betyr elementene?
    • Må snakke mye med SFM for å forstå
    • Hvordan ser svarene fra API’en ut?
    • Hvilke felter inneholder hvilke verdi?
  • SIMPLIFIER har ikke innebyggede eksempler og integrasjonen
  • FHIR extensions gir kompleks kode
    • Ødelegger for gjenbruken
    • FHIR struktur er dyp, vanskelig å vite hvor i strukturen informasjon ligger
  • Største utfordring med SFM integrasjonen har vært HelseId, SFM session og Patient ticket
    • Holde session oppdatert med token

  • 5 ganger mer ressurser enn man forventet

  • FHIR fremover
    • Eksempler må være gode og vise hva man skal gjøres
    • Eksempelprogram som fungerer, koden må være innholdsrik
  • Skuffende at Person og Melde.no går bort fra FHIR
  • eHelse og NHN må stå for valget
    • Er i startgropen for SMART on FHIR
    • Blir veldig dyrt om man ikke er tro mot beslutningen om FHIR
  • Bedre dokumentasjon

Spørsmål kommentarer

  • Støtten har vært god, men dokumentasjonen er ikke god nok, prosjektet har vært i fart
  • FHIR API kan bli veldig kompliserte og vanskelig å se for seg ren Swagger
    • Gå igjennom de enkle use-casene på en god måte
  • HVordan beskriver man hva som er påkrevd av
    • Dokumentasjon av API funksjonalitet har blitt til iløpet av prosjektet
  • Ingvar Sørlien - SMART on fhir er avhengig av felles tillitsmodell
    • Fellest tillitsmodell og datadeling og FHIR - mulig tema?

Ibruktakelse av SAFEST i et nasjonalt perspektiv, Elin May Merry og Bernd Moeske

  • Elin May Merry, Helse Sør-øst informasjonsarkitekt, innføring av SAFEST
  • Berndt Moerske, informasjonsarkitekt
  • Samhandling nasjonalt gitt nytt legemiddelregister
  • Nasjonalt målbilde og korrdinering
    • Norsk Helse-IT, SAFEST, PLL
    • færre feil, bedre overgang mellom omsorgsnivåer, redusere kostnader i forvaltning og mindre feilbehandling
    • SAFEST kan gi stor gevinst men er også en stor investering
  • Legemiddel grunndata fra SAFEST med ISO IDMP
    • IDMP er besluttet i Norge gjennom legemiddeldirektivet
    • SAFEST implementerer nytt legemiddelregister
  • SAFEST grunndata publiseres med FHIR
    • SPOR arbeider tett med FHIR miljøet, tett koblet sammen med standardiseringen i HL7 FHIR
    • FHIR R5 er nesten helt kompatibel med SPOR sin IDMP implementering
    • Trenger nesten ikke tilpasninger av FHIR for å støtte SPOR
    • Microsoft Azure har ikke R5 ennå
      • Rekursive søk er ikke støttet av Microsoft FHIR
    • SAFEST FHIR R4 tilpasses til R5 modellen for den samme modellen
    • Mange utvidelser gi kompleks kode
    • Vi trenger FHIR for å levere funksjonalitet fort
  • Plan for leveranse, 1: Produkkoder, 2: Produsert legemiddel, 3: administrerbar legemiddel, 4:ernæring
  • Først omgang SAFEST og FEST som kilder til legemiddel grunndata
    • Trenger å beslutte en felles nasjonal kilde til legemiddelinformasjon
  • FEST og SAFEST er ikke kompatible for innholdet i legemiddelinformasjonen
    • Legemiddel virkestoff forskringning har ikke tilsvarende ident i FEST
    • Det er også endel kodeverk og måleenheter som benyttes forskjellig
    • Mapping vil være en mulig kilde til feil siden det er mange aktører som må gjøre en slik mapping
  • Overgangen mellom FEST og SAFEST må sees i et nasjonalt perspektiv og kan ikke overlates til hver enkelt leverandør og virksomhet
  • Trenger en nasjonal plan
  • Koordinering fra direktoratet

Spørsmål

  • Etterlyser en koordinert innføring - helt i tråd med det som er gjennomført i forhold til nasjonale kodeverk og nasjonale meldingsstandarder - som også må være nasjonalt koordinert
  • Observerer at Q4 22 skulle være ferdig med innføringen er det reelt?
    • Tror den vil fungerer, det som vises er leveransetidspunkt for SAFEST
  • Problemstillingen er kjent, e-Resept har forsøkt å følge prosjektet - tenkte å forberede seg for å benytte dette i eResept enig i at det må nasjonal koordinering til
    • Har vært svært langt prosjektløp og store endringer i scope underveis i prosjektet
    • Mange misforståelser knyttet til hva SAFEST skal være og hva som blir levert
    • Kan ikke ha to grunndataregistre for Legemidler i norge over lang tid
  • Foregår et arbeid med en satsing på felles grunndata for legemiddelinformasjon
    • Legemiddelinformasjon sett i sammenheng med livssyklus
    • Besluttet i NUFA om tiltak på området, litt sent når man er igang med implementering…
    • Dette er en stor overgang og vi må vite at investeringen er en-gangs

WGM oppsummering

  • PA og FHIR I har mange interessante sesjoner
  • content freeze mars for R5
  • R5 ballot i may
  • FAST - FHIR at Scale Taskforce - aksellerator program
    • Addresserer utfordringer knyttet til storskala implementasjon av FHIR
      • Hybrid
      • Autentisering og autentisering i FHIR økosystem
      • National directory
      • Digital identity matching
    • Åpne møter for alle medlemmer