Møte 25 i FHIR fagforum

  • Dato: 2024-08-28
  • Klokkeslett: 1300-1500
  • 85 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: SMART on FHIR

  1. Info from HL7 Norway and welcome to fagforum, Thomas og Øyvind 10 min
  2. Webmed implementasjon av SMART on FHIR, Jarle Hjortland (Webmed AS) 25 min
  3. NAV sitt arbeid med SMART on FHIR, Erik Haug og Leo-Andreas Ervik (NAV) 25 min
  4. DIPS sitt arbeid med SMART on FHIR, Sverre Coucheron (DIPS AS) 20 min
  5. Helsedirektoratet sitt arbeid med SMART on FHIR, Merete Lassen og Frank Braathen (Helsedirektoratet) 20 min
  6. Finnish IG on SMART on FHIR, Mikael Rinnetmaki (HL7 Finland), 10 min
  7. Discussion 10 min

Presentasjoner

HL7 Norge

  • 1 million kroner til HL7 Norway.
  • WGM+ i Atlanta
  • Arbeid og høring på nasjonale domeneprofiler AuditEvent og Vitale parametere

Webmed, Jarle Hjortland

Behov

  • partnerintegrasjoner uten lange utviklingsløp.
  • Historikk, ønske om å ta i bruk i Førerrettprosjektet.
  • Legene ønsker ikek å forholde seg til flere klientapplikasjoner.
  • Sikkerhet for at applikasjon kan hente ut data fra EPJ på en trygg måte.
  • Tegn på og nasjonal anbefaling å bruke HL7 FHIR standarden

Førerrett prosjektet

  • Prosjektet var kommet langt.
  • Funding fra EPJ løftet.
  • 6mnd for å levere første versjon av implementasjonen
  • 3 partnere Webmed, NHN og Vegvesenet.
  • 1300 førerrett attester til Vegvesenet hver måned.
    • Gevinsten er hentet ut.

Arkitektur i Webmed

  • Førerrett utvikling
    • Firely fasad, utvikle selv eller Microsoft FHIR server
    • Valgte Microsoft FHIR server - SFM bruker også dette
  • Autentisering
    • Implementert på FHIR IdentityServer 4
    • Utveksler Launch context og claims
    • I løpet av året må oppgraderes til Duende IdentityServer
  • FHIR API
    • Implementert som fasade mot WebMed Backend
    • Token inneholder informasjon om kunde/backend som skal bruke data
    • Persistence layer bruker Odata mot Webmed backend
    • Ett felles FHIR API for alle kunder

Utforderinger

  • Tar lang tid for nye utviklere å sette seg inn i prosjektet og FHIR
    • Krevende opplæring og trening.
  • Webmed tilgjengelig på helsenett eller VPN
    • De som lager smartapp har ikke helsenett
    • Løsning to sett med identity servere på internet og helsenett
    • FHIR fasade på internett med IP whitelist
    • Backend tillater tokens fra både internett og helsenett
  • Kun behovene for førerrett er støttet i API’ene
  • Havner fort bak i forhold til oppdateringer på Microsoft FHIR server og andre produkter i kjeden
    • Krevende å holde oppdatert
  • Når backend og servere oppdateres fungerer da appene etterpå?

Nye smart APP’er

  • To apper i produksjon
    • Spirare og Førerrett
  • Pilot
    • Brain Twin
  • Test
    • Afail transkribering
  • Under utvikling

SPirare tilbakemeldinger

  • Spirare bruker FHIr som datamodell
  • Skulle ønske at flere brukte HL7 FHIr og SMART.

Questions

Q: behov for videreutvikle FHIR Api med integrasjon i Spirare? Svar: De fleste trenger kontekst (pasient etc.) og legge resultater tilbake. Notat appen trenger noe mer funksjonalitet. Noen prosjekter har vi satt nei til fordi vi ikke har API’ene. Ønsker å gjøre ting.

Q: Når man har støtte for en app, hvor mye gjenbrukes i neste app? Svar: Sette opp ny app tar 30 minutter, det som tar tid er opplæring i FHIR/SMART on FHIR. Veldig enkelt å sette opp, ny URL og sette opp sikkerhetsregimet

Q: Hvordan synes du integrasjonen mot Spirare, Noteless vs Førerrett i forhold til dokumentasjon. Svar: Spirare EKG kommer tilbake, Førerrett svar kommer tilbake men notatapp sender bare tilbake FHIR vedlegg (sier ikke brukeren noe i siste tilfelle).

Q: Sikkerhet og test av apper i forhold til at de ikke gjør noe de ikke skal inn mot API/Webmed. Svar: Vi gir bare tilganger og åpner for så lite som mulig, avtalene med tredjeparts leverandører må regulere dette.

Q: Tilgangskontroll og autentisering, basert på HelseID, regionene har andre metoder for tilgangskontroll? Flere token regimer. Svar: Webmed sitt tokenregime, brukeren må logge på webmed med HelseID bruker til syvende og sist er det personnummeret som styrer tilgang.

Behov for informasjonutveksling mellom NAV og helse

  • Kommunikasjon med fastlege, sykemelding, sykepenger, arbeidsavklaring etc.
  • Men mange tema og mange ulike virksomheter innen helse.

Pilot pleiepenger sykt barn

  • Helse-Vest, NAV og DIPS
  • Skjemaløsning

Strategi

  • Gjennomføring
    • Nav tar ansvar fo rgjennomføring og utrulling til helsetjenesten
      • Tverfaglige team med helsepersonell, brukere og NAV
  • Løsning
    • Nav lager løsningene som skal brukes av helsepersonell
      • Smart
      • Selvstendig Webapp
  • Utvikling av ny sykemelding
    • utvikling starter høst 2024

Intensjon

  • SMART on FHIR krav til det norske markedet fra NAV sitt perspektiv
  • Gjelder mest SMART og ikke så mye FHIR
  • Det er komplisert…

Ktegorier for SMART on FHIR

  • Oppstart av SMART app
  • Hente informasjon fra FHIR server/API
  • Sende/hente data utenfor tilbyder av EPJ
    • Sende sykemelding til NAV sin backend

Oppstart

  • smart config endepunkt
  • EPJ smart configurator følger minimumskravene
  • God praksis er at SMART apper initialiseres fra launch endepunkt
    • Fra SMART får de bare id, trenger HPR og HER id mend et kan de få fra FHIR serveren.

Utfordringer med oppstartsfasen

  • OAuth 2 er tydelig definert og bruk innenfor SMART
  • id_token inneholder ikke nødvendig informasjon for oppstart av NAV applikasjonen
  • EPJ-spesifikk navngivning av elementer fører til mange konfigurasjoner av samme app
  • Manglende påkrevde felter i well-known/smart-config
    • Uthenting av data prefikses med FHIRresurs/id

Utfordringer med access token

  • Kortlevd tilgang til ressurs fra en database
    • Data kan være endret innenfor levetiden til token
  • ID matcher ikke ressursene på FHIR serveren

Utveksling av data fra EPJ

  • Nav må kunne verifisere token som brukes it lå åhente data fra FHIr server (JWT token)
  • Variasjoner i nettverksoppsett og sikkerhetsforvenintinger hos aktører
  • Hvordan sende informasjon mellom legekontor og NAV innenfor et zero trust rammeverk.
  • Open source på Github
  • SMART launcher
    • Sier hva som mangler og gir warnings
    • Legen har ikke norsk HPR nummer
    • Pasient har ikke fødselsnummer

Økt konkurranse og innovasjon, økt automatisering

DIPS, Sverre Coucheron

Open DIPS og FHIR

  • OpenDIPS med åpen dokumentasjon

SMART on FHIR

  • Hvordan bruke smart til å samarbeide bedre
  • Anbefaling av SMART som verkøty for applikasjonsintegrasjon
  • Kjørende SMART on FHIR apps i DIPS arena
  • OpenDIPS ønsker å bruke API til datadeling
  • Mange spesialiserte løsninger internasjonalt (Island, Australia, USA…) man kan benytte i egen løsning
  • Embedde webapp inn i DIPS, risikokalkulator retinaRisc
    • I dag standalone webapp, ønsker å integrere tettere
  • Har etter dette jobbet mye med NAV og mange andre:
    • Sectra
    • AgeCare
    • ShareIT
    • Narati
    • deepinsight
    • Elekta Kaiku - hjemmoppfølging
    • ANYLITE
  • Standardisert måte å integrere klientapper på er lurt
  • Har en SMART launcher på nett som lanseres snart.
    • Konfigurere SMART app på web
  • hello-open-dips app på Github åpen kildekode

Er alt bare flotters?

  • Utfordringer med produksjonssetting
  • SMART on FHIR mangler noe arbeid for å strømlinjeforme dette
    • Trenger noe standardisering nasjonalt/internasjonalt som gjør at det er reell plug an play
  • SMART fungerer som en god teknologi, ja
    • Men noen uavklarte spørsmål
      • Support ved bruk av SMART?
      • Look and feel på tvers av apper?
      • Standardisering, trengs det ytterligere standardisering

Helsedirektoratet sitt arbeidet med SMART

Oppdatering av anbefalingen om SMART on FHIR som skal revideres.

  • Nye leverandører som skal integrere mot førerrett.
  • Ferdigstille oppdatering av anbefaling i løpet av 2024
    • Implementasjonsguide for HelseAPI (NHN)
    • Implementasjonsguide for SMART on FHIR (NHN)
  • Behov for avklaring av FHIR API’er
  • Det er behov for avklaringer på sikkerhet
  • Avklaring av lovlige FHIR scopes i SMART
  • Behov for standardisering knyttet til EPJ og struktur i data som lagres?
    • Kravet handler om API inn/ut av EPJ.
  • Hva med avtaler mellom EPJ og SMART app leverandør
    • Godkjenning og sertifisering av apper?
    • Godkjenning og sertifisering av EPJ sin implementasjon av HelseAPI.

Anbefalingen

  • Anbefalingene er svakt formulert.
  • Anbefaling av SMART on FHIR er veileder - som er en svakere anbefaling.
  • Bruksområder konkrete råd
    • Erklæringer
    • Beslutningsstøtte
    • Prosesstøtte
    • Leverandørstyring
    • Behandlingsplaner
    • Integrasjon av MTU
    • Rapportering

Questions

Q: Hvordan ser dere rollen til CDS Hooks i forhold til SMART on FHIR, for enklere beslutningsstøtte som ikke trenger interaksjon med brukeren? (Viser f.eks. en kalkulasjon eller advarsel basert på data i FHIR-serveren.). Er det noen spesielle bruksområder som ikke SMART bør brukes. Svar: Det er beskrevet noen relevante problemstilinger knyttet til områder hvor andre teknikker bør brukes, inkludert CDS Hooks.

Finnish SMART app launch framework IG

Patient empowerment

  • Point of view - of the patient
  • Putting the data in the hands of the patients, maybe missing in the norwegian anbefaling?
  • App market - business aspect of the app business.
  • App gallery

Data sharing

  • SMART health cards and links

Business models

  • 100’s of patient facing apps but not used throughout the healthcare sector
  • France remote monitoring apps - with fixed pricing

The Finnish IG for smart app launch

  • Build a fruitful app ecosystem
  • Create something that procurers can refer to in tenders

  • Demonstrate benefits through examples

  • Adopt best bractices
  • Not create new requirements
  • Make spec easy to implement
  • Mace spec easy to adopt and extend

The official IG

  • Not many conformance
  • But there are examples

Ideas for Nordic app launch framework

  • Keep the same constraints
    • Require REST and JSON, recommend XML and IPA
    • Offer doumentation and examples
    • Ling app accretitations processes
    • Lightweigh conformance testing procedure for apps and server
      • List conformant implementations
    • Test apps should be included in the IG