Møte 28 i FHIR fagforum

Dato: 2025-02-05
Klokkeslett: 1300-1500
80 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

Velkommen og info fra HL7 Norge, Thomas og Øyvind 10 min
FHIR for EKG, spirometri, 24-timers blodtrykk og statistikk om bruk av utstyr, Lars Kristian Roland (Diagnostica), 35 min
Pasientens måledata, Jon og Sigurd (NHN), 20 min
Integrasjon av MTU i HSØ, Øyvind Aassve (Sykehuspartner), 25 min
DMP sin Eudamed implementasjon, Nikolai Nordby (DMP), 20 min
Q&A, Alle 20 min

Presentasjoner

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.
Det er noen krav i MRD/IVDR om å følge opp ettermarked og recall. ISO 81001 viser dette det i denne figuren, den kjeden dere kan etablere kan gjøre dette lettere: