Referat FFF 28

docs/FHIR-faglig-forum/_referat/2025-02-05-referat.md

@@ -10,14 +10,14 @@ tema: Devices, MTU og måledata
 
 * Dato: 2025-02-05
 * Klokkeslett: 1300-1500
-* XX personer innom møtet virtuelt endel flere i diverse møterom.
+* 74 personer innom møtet virtuelt endel flere i diverse møterom.
 
 FHIR fagforum (FFF) er et åpent forum om bruk og implementering av HL7 FHIR i Norge. FFF er åpent for alle.
 
 ## Agenda: Devices, MTU og måledata
 
 1. Velkommen og info fra HL7 Norge, Thomas og Øyvind 10 min
-2. FHIR for EKG, spirometri, 24-timers blodtrykk og statistikk om bruk av utstyr, Lars Kristian Roland (Spirare), 35 min
+2. FHIR for EKG, spirometri, 24-timers blodtrykk og statistikk om bruk av utstyr, Lars Kristian Roland (Diagnostica), 35 min
 3. Pasientens måledata, Jon og Sigurd (NHN), 20 min
 4. Integrasjon av MTU i HSØ, Øyvind Aassve (Sykehuspartner), 25 min
 5. DMP sin [Eudamed](https://webgate.ec.europa.eu/eudamed/landing-page#/) implementasjon, Nikolai Nordby (DMP), 20 min
@@ -29,3 +29,212 @@ FHIR fagforum (FFF) er et åpent forum om bruk og implementering av HL7 FHIR i N
 
 ## Info fra HL7 Norge
 
+* Høring av vitale parametere eventuelt sammen med basisprofiler for vitale parametere.
+* Akselerator på Device interoperabilitet 27 februar kl 2000
+* HL7 europa EU-athon
+
+## Spirare fra Diagnostica
+
+* Diagnoseløsning for EGK og spirometri.
+* Spirometri målinger for eksempel
+* Bruker R5 av FHIR, blant annet notat på Diagnostic report.
+  * Mange Observation, Procedure, Patient og Practitioner
+  * Device, DeviceUsage og MetricDevice
+* Kodeverk
+  * SNOMED
+  * 11073 - hardware nært
+  * LOINC i vitale parametere
+  * Egne kodeverk for proprietære data.
+* Alle undersøkelser er en DR med samling av ulike observasjoner
+  * 24t blodtrykk er en Observation
+  * EKG brukes flere Observastions - rådata og flere filtrerte og representativt beat (medianslag)
+* Procedure brukes med spirometri for å skille ulike type undersøkelser
+* Kodeverk - bruker så standard kodeverk og terminologi som mulig.
+* Eksempel 24-timers blodtrykk
+  * Bruker både LOINC og SNOMED koder i Observation
+* EKG eksempel
+  * Inneholder både rådata og filtrerte data pluss kroppsvekt og høyde (komponenter)
+* Spirometri
+* Utstyrsinformasjon - hvem som bruker utstyret og hvor mye det er brukt, kvalitetskontroll utført dato
+* FHIR til å lagre deviceinformasjon
+  * Device, Metric, usage og koblet til Observation og hvilken pasient som bruker det nå.
+* Interoperabilitet? 
+  * Trenger endel lokale ting for å få til applikasjon. 
+  * Endel data er nok ikke interessert i de proprietære datapunktene.
+  * Det hjelper å bruke en felles standard i bunn for å kunne utveksle data med andre.
+* Circulating reference - Standardisering som fører til at informasjon går tapt
+  * De lokalt nyttige dataene forsvinner på veien.
+  * Spirare er nok mer på det lokalt tilpassede formatet som gir verdi for deres applikasjon.
+
+### Spørsmål til Lars
+
+* Lokale tilpasninger er bra, og bruk av FHIR gjør det mulig å dele det som er generelt.
+  * FHIr API som eksponeres inn mot applikasjonen er nok ikke likt det som skal brukes i nasjonale tjenester
+  * Men det gjør det enklere å dele dette også eksternt.
+  * FHIR gir mulighet itl flere koder/kodeverk i samme måling, noe som er en god fleksibilitet.
+  * Hvis du krever data standardisert, som man ikke har lokalt så man må samle mer for forskning så er det farlig og arbeidskrevende.
+* Erfaring med HAPI server?
+* SMART støtte, har noen tatt det i bruk?
+  * Veldig god erfaring med HAPI - lite support, men helt solid. Veldig solid så aldri noe problem, litt nervøs i forhold til support. Det har også SMILE CDR.
+  * Mange EPJ som jobber med SMART integrasjon - viewer applikasjon så du kan se undersøkelser på web, skal komme flere funksjoner.
+  * Kan bruke Spirare inn i andre EPJ og ta US som EPJ.
+
+## Pasientens måledata, Sigurd og Jon, NHN
+
+* Status
+  * Dele data mellom kommune og spesialisthelsetjenesten.
+  * Startet med Drammen/asker og VV-HF og hjertesviktpasienter
+  * Tynt pasientgrunnlag
+  * Tar inn OUS i 2025
+* Øverføring av målinger fra DHO løsning til VKP og videre til PMD
+  * Tilgjengeliggjøring via API av målinger fra PMD
+  * FHIR Observation
+  * DHO er valgt som utprøving fordi behovet er kommunisert tydelig , men behovet er antakelig universelt.
+* Pasientens måledata - recap siden 2024
+  * Informasjonsdeling på tvers av flere aktører
+  * Unngå/begrense variasjon
+  * Enklelt å bruke for leverandører og utviklere
+  * Må kunne utvides etter som nye behov oppdages.
+  * DHO er behovseier foreløpig
+  * Informasjonsbehovet er foreløpig uavklart, men vi vet at i DHO har vi behov for hyppige målinger og trender.
+  * NHN er databehandler for de dataansvarlige kildene (kommune og sykehus)
+  * I PMD er det målinger som er viktig
+  * Får mer data i DHO systemene notat, varsel og spørreskjemabesvarelser
+  * Informasjonsbehov måledata DHO
+    * Kommer fra måleapparat: type måling, verdi, enhet, tid og device
+    * Berikes typisk med: hvilken pasient, tersekverdier, vurderinger (trafikklys) og notat
+    * Hvilke behov er foreløpig uavklart
+      * Hvem har tatt målingen?
+      * Hvem godkjente målingen etter QA?
+      * Ansvarlig organisasjon?
+      * Dataansvarlig for målingen?
+      * Mer informasjon om utstyret (Device)
+    * referenceRange brukes til terskelverdier strukturert slik at disse kan vises sammen med data.
+  * Kodeverk som benyttes
+    * LOINC koder hentet fra vitale parametere
+    * SNOMED begreper angis som en opsjon
+  * Eksempel LOINC for systolisk blodtrykk
+* Erfaringer måledata / FHIR observatins
+  * Passergodt rett inn, FHIR definisjon brukes mer eller mindre direkte
+    * Lite behov for utvidelser
+  * Kontekst rundt målingene må kanskje bygges ut.
+  * Bruk av terskelverdier.
+  * Utfordringer
+    * Litt vanskelig (HL7 FHIR)
+    * Helseinformasjon er vanskelig med høy kompleksitet
+    * Generelle definisjon inkluderer feltnavn og beskrivelser - åpner for mye variasjon og gir mulighet for misforståelser og feil.
+    * Er FHIR definisjoner enkle å forstå?
+  * Erfaringer fra VKP (trygghet og mestring)
+    * Der FHIR ikke enkelt passer - så blir det tungt å implementere FHIR og vanskelig å finne korrekte dataelementer - krever ekstra definisjon
+    * Standarder vil tolkes ulikt av ulike lesere.
+    * Må oversettes fra VKP sin FHIr og Helseplattformen sin FHIR siden det er ulike innhold
+    * VKP er på R4 og jobber med å få alle over fra STU3
+      * Tar lang tid
+    * Standardisering av representasjon - men ulike forskjeller i klinisk praksis
+    * Trenger koordinering like mye som standardisering - begreper og standarder må tas i bruk likt.
+  * Vurdering VKP/PMD
+    * Tilpasning til behov
+    * Efaring der det må være likt må vi kunne validere
+    * Være mer åpen og fleksibel der det er ulike implementasjoner.
+    * Skal man ha med all ekstrainformas i alle tilfeller.
+
+### Spørsmål til NHN
+
+* Koordinering er viktig og hvordan får vi til dette på en mest mulig effektiv og bærekraftig måte?
+  * Dette er en stor utfordring.
+  * Hver journalløsning og EPJ har sin struktur.
+
+## Integrasjon av MTU i HSØ
+
+* Deling av informasjon i MTU på FHIR
+* Arkitektur
+* PHG
+* Informasjonsarkitekturen for FHIR/MTU
+
+### PHG - PH Gateway
+
+* Felles gateway melom utstyr og ulike applikasjoner
+* Komponent 1 - Google HealthConnect og Apple HealthKit
+  * Kan lagre data fra leverandørapplikasjonene.
+  * Vanligvis integrasjon mellom device og applikasjon i telefonen.
+  * Lagres på telefonen.
+  * Dele data fra HealthKit eller HealthConnect (ikke via sky)
+* Komponent 2 og 3 - Azure data service integrasjon (regionens skyløsning)
+  * Regionalt målarkitekturarbeid
+  * Regional målarkitetkur for FHIR
+
+### FHIR i POC for MTU
+
+* Mye proprietære data fra devicene.
+* Nasjonalt rammeverk for FHIR profilering - baserer seg helst på internasjonale implementasjonsguider.
+* Internasjonale implementasjonsguider for MTU
+  * Vitale parametere
+  * Point of care general IG (MTU)
+  * PHG (personlige devicer)
+* PoC MTU
+  * Enklere målinger kan bruke vital-signs
+  * Point-of-Care Device FHIR IG
+    * operasjon, post operativ og intensiv
+* PHG
+  * Vital signs dekker det meste
+  * Personal health device FHIR IG
+    * Videreutvikles og forvaltes nå av HL7 Device, PCHA og IHE
+    * Benytter 11073
+* Nasjonale profiler
+  * Benytte utvikling i VKP og PMD løsningene til NHN
+* FHIR vital signs
+  * VKP og PMD - kan tilpasses til å bli no-basis
+  * no-domain vital signs
+    * endel informasjon som er mer komplisert enn det PHG trenger
+
+### Spørsmål til Øyvind
+
+* Ved målinger i hjemmet: Skilles det på målinger tatt på CE-merket utstyr (mdr) om annet utstyr?
+  * Enklere utstyr som ikke er CE merket blir nok ikke brukt så mye fra sykehuset sin side.
+
+## DMP sin implementasjon av Eudamed
+
+* Data om utstyret
+* MDR myndighet 
+* Det meste som har medisinsk hensikt 
+* EUDAMED - European database on Medical devices
+* Felles database for grunndata om medisinsk utstyr
+  * Aktører
+  * Utstyr
+  * Transparens offentlig tilgjengelig
+  * Sturkturert
+  * En kilde
+* EU - kommisjonen utvikler
+* Plikt til bruk.
+
+### Spørsmål til Nikolai
+
+* Er det 500 000 modellar/klassar, eller 500k enkelteiningar?
+* Type av utstyr finnes, men ikke hver enkelt utstyrsinstans
+  * Produsent, egenskap, sertifikat, sikkerhetsmeldinger og markedsdistribusjon
+* Eksempel
+  * Offentlig tilgjengelig informasjon
+  * Ikke noe API
+* Nytt mottak av informasjon/saksbehandlingssystem for informasjon om produsenter og utstyr i markedet.
+  * Effektiv overvåkning av medisinsk utstyr
+  * MS Fabric platform for integrasjon mot EUDAMED
+  * EUDAMED tilbyr ikke mulighet for å hente data via API, bør vi tilgjengeliggjøre det via FHIR API
+    * Er Det behov for FHIR api for grunndata om medisinsk utstyr?
+  * Teknisk informasjon om utstyr, produsent, recall, sikkerhetsmeldinger kan eventuelt distribueres via API.
+  * Ønsker innspill på dette
+
+### Diskusjon
+
+* Medusa forvaltning - implantatregisteret er veldig relevante integrasjoner
+* Interessant informasjon for leverandørene av applikasjoner som bruker utstyr
+  * Få informasjon om utstyret som er brukt, enklere med en integrasjon mot databasen
+  * Må være gratis
+* Oversikt over sikkerhetsmeldinger og hva som finnes av utstyr, bør være tilgjengelig maskinelt.
+* Klassifisering av utstyr og kategorisering inn i nettverket, NKKN og ta data inn i arkitekturverktøy slik at det kan planlegges for integrasjon
+  * Mest mulig tilgjengelig dat på klassifikasjoner om medisinsk utstyr.
+  * Medusa benytter MKKN som klassifikasjon som bruker de europeiske ID-ene
+  * Felles nasjonal klassifikasjon trenger vi ihvertfall og tilgjengliggjøring må finnes enten nedlastbar eller via FHIR API.
+* EMDM blir nominasjonsklassifikasjonen
+* KI og henviser til at EUDAMED kommer - kan FHIR API enklere fange opp sikkerhetsproblematikk som gjør det mulig å følge med på KI bruk innen helse
+* Øke synligheten i hele kjeden kan gjør det enklere å implementere MDR
+  * Bøte på behovet for å driftsinformasjon spesielt knytte titl Norge som lite land og lite marked.