Møte 15 i FHIR fagforum

  • Dato: 2022-11-30
  • Klokkeslett: 1300-1500
  • 74 personer innom møtet

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

Erfaringer fra prosjekter

  1. Velkommen og presentasjonsrunde, Thomas T Rosenlund, Direktoratet for e-helse (5 min)
  2. Informasjon fra HL7 Norge, Øyvind Aassve, Sykehuspartner (5 min)
  3. Pasientens prøvesvar (NILAR), Ivar Yrke, NHN (30 min)
  4. Digital behandling og egenbehandlingsplan, Vidar Methi NHN, Norsk Helsenett/Helsedirektoratet (30 min)
  5. Klinikere “on FHIR”! - Hvordan et API kan skape glede og trygghet i helsetjenesten - SAFEST. Kristine Aasen, Statens legemiddelverk og Bernd Moeske, Sykehuspartner. (30-40 min)
  6. Eventuelt og diskusjon

Presentasjoner

HL7 Norge - Øyvind AAssve, Sykehuspartner

  • Innspill: codeSystem mangler i SAFEST arbeidet (listen over prosjekter)

Pasientens prøvesvar, Ivar Yrke NHN

  • KITH meldinger innkommende som skal tilgjengeliggjøres som HL7 FHIR (R4)
  • Samle inn og tilgjengeliggjøre informasjon
  • Skal kunne søke i labsvar på tvers av de som sender ut lab og behandler
    • Meldingene lagres i labsvar database (MongoDB)
    • PPS tjenesten oppstår on-the-fly i løsningen, all prosessering på vei ut (etter spørringen)
    • Startet med å lagre data i Vonk server men gikk bort fra det (prosessering på vei inn)
  • 1:1 mapping mellom KITH XML og FHIR
    • Datoer er ikke like i FHIR og KITH XML
    • Koder og kodeverk håndteres forskjellig i ulike systemer (labsystemer)
      • koder ligger forskjellig i KITH XML avhengig av hvilket system som har produsert
    • Ulike strukturer i KITH XML men er forutsigbare
    • Ulike tolkninger og implementasjoner av XML standarden så det er ikke alltid samme semantiske innhold kommer på samme sted i KITH XML
      • vanskelig å håndtere i prosjektet siden orden i Labmeldingene ikke er målet for prosjektet
  • Enveis, mappingen fra XML til FHIR går aldri motsatt vei
  • Kan ikke levere data på FHIR format, det kan være aktuelt i fremtiden
    • ønsker ikke å videreføre gjeld fra KITH XML som er med av historiske årsaker
    • FHIR profil for innlevering må være nyproduksjon
  • Profilering
    • Draft mode av Implementasjonsguide
    • FHIR Shorthand profilering
      • Diskuterer med HL7 og TSK
  • Teknologivalg - ingen FHIR mapping på vei inn
    • Innkommende data lagres som de er (KITH XML) nesten med to unntak
      • Delvis pseudonymisering av data i database (navn telefon adresse og personnummer tas bort)
      • Legger på id som blir FHIR id
    • MongoDB - lagring
    • Mapper til FHIR på vei ut ved forespørsel
      • Fhirely.SDK mapper
  • Begrunnelse
    • Dårlig ytelse på mottak av data ved
    • ingen binding av FHIr versjon i persisteringen
    • utdata kan levers på hvilken som helst versjon, ny mapping, ny utdata
    • Ulemper
      • Noe tyngre prosesering på vei ut
      • vanskelig å optimalisere uthenting fra database siden noen av kriteriene ligger godt innkapslet i dataene
      • Henter alle data om person og filtrerer etterpå basret på søket
  • Drift i en måned
    • prøves ut med Furst og ti leger
    • kun test og ikke behandling
    • oppslag via kjernejournal for kliniker
    • Over 1/2 million meldinger mottatt
    • Innsyn i egne data via helsenorge for innbygger
      • Pasientens prøvesvar på helsenorge og se prøvene
      • Mest aktivitet fra innbygger (20 000 oppslag)

Spørsmål

  • Prosessering på vei ut, hva betyr det for ytelsen?
    • Ikke sammenlignet - hadde ikek vesentlige data på Vonk
    • Veldig avhengig av mengden data, mye data gir dårlig ytelse
      • mange sekunder 6-7 sekunder for å få ut data
    • Tallene ca 800ms å få ut svar og kan også optimaliseres ytterligere

Digitale behandlings og egenbehandlingsplaner

  • Helsedirektoratet hovedprosjekt, NHN løsningsutvikler, Helse-Nord har utprøving
  • Diagnoser - Mål - Behandlingstiltak
  • Samhandlingen om pasienten blant behandlere og involvere pasienten
  • Sentral lagring i kjernejournal med åpne API
    • idag er utprøvingen gjennom portalløsning i kjernejournal
    • ønsker å fase ut portalløsningen etterhvert som systemene implementerer integrasjon mot API
  • Behandlergrensesnitt - eksemplifiserer API funksjonaliteten
  • Startet begrenset utprøving med kjernejournal og helsenorge
    • Videreutvikling iløpet av utprøvingen
    • Dokumentere og evaluere etter utprøvingen
  • Teknisk løsning basert på HAPI FHIR
    • FHIR fasade
    • SQL server til å lagre struktur for FHIR ressur, FHIR ressurser lagres som JSON “document”
    • CarePlan brukes som behandlingsplanen
    • Condition - beskriver diagnose/problemstilling
    • Goal - brukes for å skrive behandlingsmål
    • ServiceRequest - tiltak som skal gjennomføres av behandler eller pasient
  • Autentisering - HelseID for kliniker og helsenorge for innbygger
    • Sperring bruker personvernkomponenten i helsenorge
  • Teknisk dokumentasjon på NHN utviklerportal
    • NHN utviklerportal under kjernejournal
  • Identifikatorer
    • id vs identifier
  • Registering av endringer av planen ligger nå som metadata/extension
    • Provenance, contained eller extension -
    • provenance er noe kompleks og bruk av referanser er utfordrende

Spørsmål

  • Valg av lagringsplattform
    • Kjernejournal har en vanlig relasjonsdatabase, vanskelig å lagre FHIR struktur i en relasjonsdatabase
    • Passet best med SQL database for koblingen til kjernejournal
    • SQL enkel å legge i kubernetes
  • Litt erfaringer knyttet til ulike lagringsteknologi
  • CarePlan - har vel en struktur for tiltaket? Hva med kobling til Questionnaire
    • ServiceRequest er et minstevalg, kan tenke seg å utvide mer etterhvert
    • FHIR har rammeverk for mer spesifikke ressurser for å detaljere tiltak
  • Lagring av dokumentene som JSON i databasen hva med spørring?
    • Får spurt i elementer inne i strukturen
  • Modellene som vises her - finnes det noe verktøy?
    • Tegnet selv i Gliffy og andre verktøy
  • Tidligere har det vært juridiske problemer med å lagre en liste over pasientens diagnoser sentralt i kjernejournal. Er det løst opp i, eller er det ok fordi det bare er et utvalg av diagnoser (om det er det)? Og diagnoser, er det angitt med icd-10, og /eller ICPC2? (snakker gjerne om dette etter møtet-mail)
    • ICPC-2 😊 Det er lov å lagre behandlingsplan i kjernejournal (med diagnoser) ref. kjernejournalforskriften, men bare hvis pasient samtykker. Dvs. må pasient gi samtykke til behandler før hen kan opprette plan (dette går som egen request, som vi lagrer det ned). Samtykke kan også trekkes tilbake, og da må vi slette planen. Akkurat hva som er den fulle juridiske problemstillingen her tør jeg ikke helt å svare på i farten, men det er riktig som du sier at dette ikke er en autorativ diagnoseliste - Selv om den kan gi en nyttig “problemoversikt” er det ikke gitt at behandlerne knytter pasientens behandlingsplan til alle pasientens diagnoser.
  • Tar i bruk CarePlan og andre ressurser, planlegger dere å arbeide med basis/domeneressurser, for gjenbruk for eksempel?
    • Koordinering på tvers og eventuelle andre måter å dokumentere FHIr bruken på (SIMPLIFIER eller IG publisher)
    • Ingen utstrakte tilpasninger av CarePlan (stort sett vanilla CarePlan)
      • De bruker bare en extension og har noen kodeverksbindinger (diagnose)
  • AcitivityDefinition - istenfor ServiceRequest, ja det er vurdert.

Kliniker on FHIR, FHI Kristine Aasen og Berndt Moeske

  • Legemiddelverket en del av et internasjonalt samarbeid om trygge legemidler
  • Internasjonale standarder er viktig: IDMP
  • 1:1 forhold mellom iso/IDMP og HL7 FHIR
  • Bruk av ISO/IDMP er hjemlet i EU
  • FHIR spesifikasjonen er direkte tilpasset til medisininformasjon i europa (IDMP)
  • MedicinalProduct er ikke klar før R4B av HL7 FHIR
    • Microsoft FHIR understøtter ikke rekursive søk p.t.
  • Virkestoffordinering
    • Mer presis forordning med virkestoff forordningen
  • Virkestofforordningsgrupper i IDMP
    • Ulike produkter benyttes i forskjellige land
  • PhPID - ingen FHIR profil for PhPID ennå (Hash id)

Spørsmål

  • PhPID - når kommer det?
    • Uppsala har fått i oppdrag fra WHO å utgi PhPID, men det tar tid
    • Nyttig med kontakt internasjonalt
  • FESTid kan også inneholdes i id’en pluss endel kodeverk fra internasjonalt? Er det de norske kodeverkene i FEST som brukes, hva med Volvenkodeverkene for dosering for eksempel?
    • Ønskelig å bruke internasjonale SPOR kodeverk
    • Kan distribuere begge deler
    • Legemiddelform vil det bli en overgang - koden i FEST blir ikek samme som blir levert ut i SAFEST
  • Visning av legemidler for utlendinger må dette på plass? EU Helsedataprosjektet
    • Vi har tenkt at PhPid blir viktig hjelp for forskrvning og utlevering på tvers av landegrenser
    • Kommer ann på

      Eventuelt og diskusjon

  • Neste møte 8 februar, Nordic on FHIR, meld dere på info@hl7.no
  • Mange gode spørsmål

Til Øyvind Øyvind Aassve send meg gjerne litt mer info om den HL7 “kvernen” på peter.evans@nhn.no, så kan jeg legge det inn som en mulig aktivitet i prosjektavslutningen - avhengig av hvor vi står da og hva vi har lært fra utprøvningen