Møte 33 i FHIR fagforum

Dato: 2025-12-10
Klokkeslett: 1300-1500
26 personer innom møtet virtuelt

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

Agenda: Tannhelse on FHIR

Velkommen, Thomas og Info fra HL7 Norge Øyvind, 10 min
IG for tannhelse, Jørn Andre Jørgensen (Novari IKS) 60 min
Oppsummering fra Norsk FHIR Hackathon på EHiN, Thomas, Adam, Michael ++, 30 min
Hvordan forholder klientene seg til flere versjoner av FHIR, med utgangspunkt i CarePlan (R4 og R5/R6), Vidar Methi (NHN), 20 min
Eventuelt

Presentations

Info from HL7 Norge

FHIR Hackathon 10. november med 40 deltakere
FHIR IG for kommunesektoren, output fra OKT sporet på Hackathon.
HL7 WGM i Køln var fullt, stor deltakelse fra Norge også, handlet mye om EHDS.
Condition, Encounter og DiagnosticReport

Tannhelse on FHIR

Bakgrunn og ønsket situasjon
Den offentlige tannhelsetjenesten (DOT)
- 1.6 millioner innbyggere
Få systemene til å snakke sammen
- Lite rom for tilpasse løsningene til behovene
- Vanskelig å utvikle ny funksjonalitet
- Manuell oppgaveløsning
- Mange feil
Felles informasjonsmodell
Informasjonsmodell, standardisering og terminologi (FHIR og SNOMED CT)
Også med EHDS
Innformasjonsinnhold i dagens løsninger
Validering av at modellen kan romme informasjonen
Kartelgge arbeidsprosesser
Terminologi og kodeverk - basert på SNOMED
- Inn i det internasjonale referansesettet
- Nasjonale referansesett
FHIR standardisering
- Informasjonsmodell - profilering og normering
- Trenger normerende tyngden fra hdir og standardsieringorganisasjoner for å få leverandørene til å levere standardiserte løsninger.
På tannhelse er SNOMED CT et godt valg for terminologi.
FHIR R4 rammeverk er valgt.
- Nasjonal anbefaling
- EHDS bruker FHIR
- Tannhelsemiljø internasjonalt tenker FHIR
- R4 siste stabile release
- Open EHR handler mer om intern datastruktur for systemene
Prinsipper for FHIR arbeidet
- Bruke nasjonale basisprofiler
- Bruke FHIR ressursen direkte hvis no-basis ikke fungerer
  - Eksempler på hva som ikke fungerer? No-basis har gjort valg som ikek passer med use-case
- Terminologibinding der det ikke finnes.
- Lite ekstensjoner
Demo med data fra gammelt system - transformasjon til FHIr og aksess av data fra HAPI FHIR.
Prekoordinert kode må alltid være tilstede
- Optional postkoordinert må være identisk eller en spesialisering av prekoordinert
- Bodysite må være identist med postkoordineringskodene fra expression
Ønsker å kreve at systemene innenfor tannhelse støtter postkoordinering for å uttrykke mer presise angivelser av conditions for eksempel.
Flere bodysites når det er kvalifikatorer til BodySiteen

Spørsmål

Re Dental Care (and sorry about using English): For background I recently watched your (I think) SNOMED CT Expo presentation on same subject. Can you elaborate on your “real life” experiences for using post-coordination for actually recording data i.e. using ECL as FHIR code value ? Instead of creating a lot of new concepts for many related things, as I understood from the Expo material.
- Using expressions or ECL to show the tooth diagram in the simulator
- The expression code is used for almost everything
- Needs 72 000 concepts with pre-coordination but only 500 using postcoordination.
For statistikk du viste i R, har dere vurdert å hente ut FHIR data fra HAPI og lage statistikk med CQL?
- Har ikke vurdert CQL ennå, men vet at dette kan gjøres smartere.
Postkoordinering stiller store krav til leverandørene og blant annet i forhold til å bruke SNOMED CT terminologitjeneste
- Alle de postkoordinerte begreper blir lagret i terminologitjeneren.
Da trenger man også en fast standardisert form av ECL-en, noe som canonical form av XML?
- Ja det er derfor vi validerer uttrykket mot snomedtjeenern
Procedure og condition og bodysite 0..1 eventuelt kvvalifikator fra EHDS, åpent spørsmål.

FHIR Hackathon 2025

OKT-track - oppsummering

Hvordan lage FHIR grensesnitt for tjeneste som ikke var FHIR native.
Mapping til FHIR strukturer
Implementation guide ble utviklet som en del av hackathon forberedelse
Diskusjon av hvilken ressurs som best fungerer for utveksling av Kommunale tjenester
Hele kjeden var representert i diskusjonen
Viktig å begrense scope av diskusjonen så den ikke tar helt av sted
Resutlater
- Bestemte seg for hilke ressurser som passet for maping av OKT-tjeneste
- Mapping til FHIR
- Demonstrere at hackathon kan fungere også for diskusjoner om løsning
Utkast til IG ligger på Github og det skal jobbes videre med uavklarte spørsmål
Legge til terminologi for kodede elementer
Fremtiden til OKT FHIR API
- Er opp til tjenesteeier

PMD track oppsummering

PMD API er FHIR
Begrenset oppgave om å lage klient for konsum og publisering av måledata mot API
Hadde en testklient uten helseID autentisering.
Test og tilbakemelding av dokumentasjon og funksjon på API.
- Blir gjort noe med API’et slik at dette støttes
Åpne spørsmål
- Konteksten rundt måledata
- Hvor kommer data fra
- Datakvalitet til målingene
Dialogen mellom utviklerne er veldig nyttig.
- Viktig å vite hvordan leverandørene bruker standarden og API’ene
Demo

Flere versjoner av FHIR

Pasientens planer skal snart ut på anbud

CarePlan har fått endel endringer siden R4
R6 blir antakelig den nye standarden og kanskje den siste versjonen av FHIR?
R6 bruk vil kanskje gjøre det vanskelig for leverandører å forholde seg til mange versjoner av FHIR?
Vil dette føre til store utfordringer for leverandørene.

SAFEST til DMP - har vært mye diskutert om R4 eller R5.

Microsoft FHIR server støtter ikke R5 ennå.

Noen ressurser har store endringer, blant annet definition ressursene for medisinering som har et ganske avgrenset økosystem.

CarePlan - hvor store endringer er det snakk om mellom R4 og R5?

Legge opp til overgang - forenklet overgang - ved å legge til utvidelser for å gjøre det enkelt på gjøre overgangen til R5

Utvidelser som understøtter eventuelt nye datastrukturer.

Umodne ressurser på R4 - lag extensions for å støtte overgang til R6 er antakelig et godt råd.