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

• Fagforum møte 5
• SMART on FHIR intro
• Teori app launch framework
• Implementasjon av SMART i førerrett
• Micro frontends + SMART on FHIR i DIPS

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