Møte 5 i FHIR fagforum

  • Dato: 2021-04-21
  • Klokkeslett: 1300-1500
  • 82 deltakere

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

Agenda

  1. Velkommen og presentasjonsrunde (alle skriver i chatten hvor de kommer fra + aktuell erfaring/prosjekt), Thomas T Rosenlund, Direktoratet for e-helse (5 min)
  2. Informasjon fra HL7 Norge (WGM, profileringsworkshop, metode) Øyvind Aassve, Sykehuspartner (5 min)
  3. Konsept SMART, Lars Kristian Roland, Direktoratet for e-helse (15 min)
  4. Teori app launch framework, Kenneth Myhra, Incendi/NHN (20 min)
  5. Implementasjon av SMART i førerrett, Kristian Moum og Klaus Reinholt Andersen, Aspit (30 min)
  6. Micro frontends + SMART, Thor Stenbæk, DIPS (30 min)
  7. Eventuelt og diskusjon (15 min)

Presentasjoner

Velkommen presentasjonsrunde

Velkommen pluss chat.

Info fra HL7 Norge

WGM i mai 24-28 mai, deltakelse støttes av HL7 Norge

  • Mulighet for å oppleve arbeidsgruppemøte uten å reise langt
  • Være med i arbeidsgruppene og se hvordan arbeidet foregår her
  • Detaljerte diskusjoner rundt utviklingen av standarden
  • Early bird 8. mai
  • Europeisk tid

Workshop juni

  • basisprofil for Procedure, basert på HSØ arbeidet tarmscreening prosjekt
  • kodeverk og terminologi trenger diskusjon på overordnet nivå
  • Problemstillinger sendes til HL7 Norge representanter (eller på Git)

metode FHIR områdeprofiler

  • Metoden er publisert både på e-helse og GitHub

Konsept SMART

Ønske om å få til ny funksjonalitet raskere enn tidligere SMART app launch framework for å integrere web-applikasjoner inn i EPJ-system Stort spekter av brukerbehov, noen har alle, men mange behov er det få personer som trenger.

  • longtail (Amazon) - EPJ leverandørene må fokusere på å dekke brukernes viktigste behov
    • De andre behovene dekkes gjennom web-applikasjoner osv som ikke er integrert
  • Arkitekturprinsipper - brukernes behov og arkitekturbeslutningen på riktig nivå
  • Anbefaling om bruk av SMART on FHIR
    • Prøve og dele erfaring
    • Teknisk, sikkerhetsmessig og medisninsfaglig

Spørsmål

SMART on FHIR modul kunne oppdatere data i host utenom det som er satt av kun til modulen

  • Kommer ann på sikkerhetsimplementasjonen i den enkelte SMART app’en
  • Kan oppdatere data i server, EPJ og i browsermodulen, men det er avhengig av implementasjon

Autorisasjon?

  • Dette er endel av rammeverket

Teori app launch framework

App launch framework gir autorisert tilgang til data i EPJ via autorisasjonskontroll Flere bruksscenarioer beskrevet i Argonaut prosjektet. Oversikt over oppstartsflyten

  • Launch sekvensen initieres ved å kalle web applikasjonen
  • EPJ mottar launch notiofikasjon
  • Applikasjon utførere en forespørsel mot autoriserings endepunktet
    • launch og scope for APP i EPJ
  • Autoriser og redirect tilbake til SMART app’en etter autorisering
  • Autorisasjonskoden veksles inn av EPJ til et tilgangstoken
  • Applikasjonen har nå tilgang til helsedata basert på token og scope

Scope og launch kontekst

  • Oppbygging av scopes og launch kontekst
  • patient-user / fhirressurs-* / read-write-*
    • Pasientkontekst

Spørsmål

Hvem tar initiativet EPJ eller APP?

  • EPJ tar vanligvis initiativ basert på brukerens handlinger
  • Finnes det brukerscenarier hvor APP tar initiativ til launch-sekvens?

Launch sekvens kan være både for frittsåtende app og fra EPJ

  • kontekstsynk mellom web-apper

Hvilke andre brukerscenarier har vi til SMART-apper?

  • Starter en app fra en EPJ i kontekst av pasient og starter web-appen i kontekst av pasient
  • for eksempel

Implementasjon av SMART i førerrett

Aspit - har ikke fastleger i våre systemer idag. Mye prøving og feiling for å utvikle SMART teknologi i systemet.

  • Demo av førerrett i Fysika
  • Viser web-applikasjonen slik den er integrert i Fysika
    • Får ikke, i demoen, lagret rett til vegvesenet
    • Skjemaet er generert av veivesenet
    • Lagrer skjemaet tilbake til journalen for pasienten i Fysika

Teknologivalg

  • Spark som rammeverk for utviklingen
  • Identity server
  • Burde laget et eget SMART testmiljø fra start

Spørsmål

  • Patient, Document, PRactitioner og Organization er i bruk
  • Informasjonen kunne lagres direkte hos Vegvesenet hvis API hadde vært oppe
  • Kan appen plugges inn i andre applikasjoner som bruker sMART?
    • Det er ideen hvis man har rammeverk for SMART implementert
  • Hvis du ikke har questionnaire, hvor er da skjemaets spørsmål?
    • Ligger i SMART appen som har Questinnaire
  • Hvorfor embedded browser og ikke frittsåtende nettelser
    • Bedre kontroll på konteksten (riktig pasient)
  • Er data bare tilgjengelig som pdf?
    • Sender pdf og en JSON struktur
    • Optimalt bør smart-appen støtte questionnaire og QurestionnaireResponse og lagre dette strukturert
    • En teknologisk snarvei å gå via pdf

SMART fra studentprosjekt til Micro Frontends

SMART fra studentprosjekt til Micro Frontends

FHIR har DIPS erfaring med over lang tid, men SMART var nytt.

  • Skulle også konstruere en SMART sandkasse

Oppdrag til studentene - utvikle erklæring for Pleiepenger fra NAV

  • gode ressurser på smarthealthit.org
  • mange gode ressurser som studentene benyttet
  • Use case er det samme som for førerrett
  • Løsningen var en kjørende prototyp og svar via QuestionnaireResponse til en kafka kø i NAV!

DIPS erfaring

Den EPJ delen av SMART er dårligere dokumentert

  • Oauth flyten er sentral i denne biten
  • FHIR service, security-service og en SMART app som kjørte i sandkassen

Demo av sandkassen

  • Enkel tenkt EPJ satt sammen av flere tjenester
    • fhir-service og sikkerhetsservice + et antall apper
  • benytter testdata fra Synthea
    • Vekstkurven appen er SMART appens hello world
  • Pleiepenge appen
    • Lagre (bare lagre i EPJ) eller sende (til NAV-kafka og til EPJ)
  • Hver fane i Sandboksen er en egen SMART on FHIR appen
    • Kjører som en iframe i web-grensesnittet
    • iframen inneholder app-launch runddansen med token og scopes
  • Before frontends
    • Monolith
    • Front-and back - SOA
    • Microservices -
  • Microfrontends
    • Ende til ende teams med micro-frontends
    • SMART frontends
  • Hvor lite kode trengs for en SMART-on-FHIR-app
    • svelte rammeverk
    • FHIR-flite
  • iframes - er en utfordring
    • Hvordan løser vi dette mer sømløst og bedre?

Spørsmål og Diskusjon

  • Hva kalles FHIR-api’et ved send?
    • Sendes som ett dokument
  • Bivirkningsregisteret og sende bivirkninger via en SMART app kan være en bruk
  • Mye er interaksjon basert på autorisering av en lege som får se ber om ressurser og får interagere med dem i en browser og en app/tynn eller tykk. Mekanismer og rettigheter for at dete kan leve videre i konteksten til lege i EPJ’en
    • Hvordan data fra et helsepersonell deles med andre helsepersonell
    • Blokkeringer
  • Microfrontends og vertikal tenking på arkitektur - hvis en ekstern leverer en av disse vertikalene - hvordan vil dette fungere med microfrontends og vertikale microfrontends
    • Fake Oauth sekvens - slik at SoF appene får akkurat det de skal ha, har også en riktig implementasjon av dette, basert på påloggede brukere i DIPS og deres autentisering
  • Hvis kommunen bruker mange applikasjoner/EPJ hvordan kan man da benytte en SoF app for å eksponere måledata om pasienten fra hjemmemålinger, kan da DIPS benytte en slik app til å vise informasjonen for sykehuspersonell i for eksempel DIPS?
    • Dette er det et prosjekt på i DIPS, det er ikke sikkert det blir SoF for dette, men det kan hende

Takk for møtet