Møte 7 i FHIR fagforum

  • Dato: 2021-09-01
  • Klokkeslett: 1300-1600
  • 82 deltakere på det meste

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)
    1. Opptak av møter, diskusjon (5 min)
  2. Informasjon fra HL7 Norge, Øyvind Aassve, Sykehuspartner (5 min)
  3. Integrating a FHIR server in you architecture, Christiaan Knaap, Firely, FHIR server (40 min)
  4. MF-Helse, Trond Klakken og Tor Arne Gjelhus, Webstep (20 min)
  5. Kort pause (5 min)
  6. Microsoft FHIR server, sky, Magnar Wium, Helsedirektoratet (20 min)
  7. SmileCDR erfaringer, plattform og arkitektur valg, Andy Harrison, Egde (20 min)
  8. Kjernejournal erfaring med FHIR fasade, Kjernejournal, NHN (20 min)
  9. Diskusjon og eventuelt

Presentasjoner

Velkommen presentasjonsrunde

Velkommen Opptak : argumenter for og imot diskusjon i sekretariatet

  • vil det påvirke deltakelsen i forumet hvis alt er tilgjengelig i etterkant?

Info fra HL7 Norge

  • Invitasjon til videre arbeid med Appointment, Shcedule, Slot, Encounter, Episode of Care, AuditEvent, CarePlan, DiagnosticReport, Speciment, ServiceRequest
  • Vital-signs observation
  • Workshop nasjonal profilering oktober/november

Integrating a FHIR server in you architecture

  • Firely Server

  • Use-cases

  • FHIR server should handle the hard parts of FHIR
  • FHIR clients should be easy to build and use
  • Functions in the API to implement in the FHIR server
  • Generic FHIR servers, Firely server, Microsoft server, HAPI/smileCDR
  • Specific FHIR servers
    • bound to a backend system
    • FHIR facade to a system
  • Choose an architecture
    • Existing data (3)
    • Hosting cloud/on-prem (4)
    • Use-cases, read and write? Resource-types, Specific IG’s, special operations needed? (1)
    • authorization, SMART, custom (2)
  • Arcitecture outline
  • Enterprise Integration Patterns
  • Patterns for simple source/consumer use-case
    • facade on sorce, requires mapping from/to FHIR to native format, works best if the mapping is not to complicated
    • Generic FHIR server, map outbound data, get a sync problem (batches/transactions or specialized API/CLI/pipeline/queue) (!)
    • Facade on consumer, consumer becomes a FHIR Server, source becomes a FHIR client, still have mapping to do
  • Pattern for multiple sources (very alike to Grunndata Person)
    • Consumer is the integration point
    • Mapping for each source
    • may have to poll all sources
    • Combine all responses
    • Facade on the sources
      • Source become FHIR servers
      • mapping is at the source
    • Generic FHIR server
      • All servers integrate to the FHIR server
      • FHIR server has an aggregator role, copy of data with delay
    • Facade on the consumer
      • probably not recommended
    • Combinations
      • Facades + generic servers
  • Pattern more sources and consumers
    • FHIR Resources as canonnical data model can be useful
    • Encapsulate mappings
    • Scatter-gather becomes hard
      • would probably want an aggregator in th emiddle
  • Pub/sub
    • Sources push data to FHIR-server
    • consumers can be event driven
    • Subscription is revamped in R5/R4B
    • Needs change tracking
  • CDR and Writing
    • extra tiny FHIR server to handle the write process
  • Facade
    • A few resourcetypes
    • a few search parameters
    • read only (write through a facade is usually hard)
    • smal part of a dataset
    • Beyond that a full server is more managable
      • more loosely coupled
      • full search supported
      • data sync could be complex
  • Common integration engine
  • Cloud data pipeline
    • Several sources using different formats
  • Related IG’s
    • SMART etc
    • Bulk data export
    • CDS-Hooks, context from EHR
    • CQL, Clinical Quality Languqage
    • V2 to FHIR / C-CDR on FHIR
    • FAST, FHIR at scale tarskforce
    • FHIRCast, Application context sync

Questions

Could you tell a bit about the bulk insert to a FHIR-server

  • Bulk exort is a IG on that
  • Bulk insert is not yet fully described
    • SmileCDR have some functionality
    • Vonk have an implementation
    • Do you prepare the FHIR format before bulk import
  • General FHIR server share database scema
    • Insert of large number of indexed elements, ingest large number of transactions give poor performance
    • The database needed to be scaled up, 800 resources per second to a scheduled
    • number of indexed fields all standard ones
    • 10-15 parametere er vanlig

FHIR i Persontjenesten

  • Persontjenesten folkeregisteret i helsesektoren
  • Bruke skytjeneste, managed servers, endte på Azure
  • SQL-server måtte velges for å tilfredstille alle kravene i prosjektet til sikkerhet og arkitekturrammeverk
  • Microsoft støttet ikke søk i extensions på beslutninstidspunktet
  • Vonk eller HAPI
    • Vonk ble valgt mye fordi den kjører på .NET og utviklingsmiljøet kan .NET best
    • utvidelse av funksjoner ville være enklere i .NET
  • Schrems II satt en stopper for sky som plattform
    • kuberneteskluster som kjører på Dora
    • Privat sky
  • Vonk ga prosjektet (funksjonalitet ut av boksen)
    • Støtte for søk og oppslag i henhold til FHIR standard
    • akseptable responstider på søk og oppslag
    • støtte for custom profiler
    • søk i extensions
    • begrense dataminimering ved hjelp av _elements
    • Plugin funksjonalitet for å designe custom operasjoner som var nødvendige
    • Støtter de daglige oppdateringene fra Folkeregisteret
  • Ulemper ved å benytte FHIR for persontjenesten
    • PErson er en parantes i FHIR, trenger mange extensions
    • _elements gir lite granularitet, gjør dataminimering vanskelig
    • Person/RelatedPerson må gjøres med _include/_revinclude
  • Personer og oppdatering av ressurser
    • Antall linjer i indeksdata ved søk 244 per person
    • 244 inserts per person
    • Modellen som er valgt gir store indekseringsproblemer
    • Se godt på hva slags mengde data og indekser dette fører til
    • Fleksibiliteten er stor, men kan gi utfordringer med ytelse
    • Noen som har sett en løsning i forhold til dette?
      • Gjelder ved store volum av oppdateringer
    • _total timet ut
    • SQL database og antall linjer per ressurs er et problem for ytelsen
    • Ett problem er at produsentene (Skatt) plutselig dumper 2 millioner oppdateringer

Spørsmål

Er ikke dokumentdatabasen bedre FHIR persisteringslag er vanskelig Fasade som mapper on the fly for å få til bedre ytelse? Spanner benyttes av Google, kan være interessant alternativ

  • pure google cloud
  • shrems 2 Ble PAAS tjeneste i microsoft før schrems2? Vi ønsket å søke i extensions noe Microsoft ikke støttet
  • Microsoft implementerte dette før sommeren iår sies det på chat’en

Microsoft FHIR server, FHIR i sky

MS FHIR server Hos Helsedirektoratet

  • Administrasjon av helsepersonell med refusjonsrett fra Helfo
  • kontaktinformasjon
  • Tekniske mål
    • FHIR
    • Hendelsesbasert kommunikasjon
    • Høy ytelse på søk og oppslag
    • Uavhengig av infrastruktur
    • Multi-tennant sikkerhetsmodell
    • Bane vei for HDIR sin skystrategi
  • Status
    • 12 systemer på
    • Full produksjon mot sentrale NAV systemer
    • I forvaltning
    • Vanligvis 300-600k oppslag i løsningen daglig
  • Microsoft FHIR server ble valgt fordi
    • Dekker nødvendig HL7 funksjonalitet
    • Open source med stort community
    • kjent teknologi .NET
    • Kjører i Azure og IIS
  • MS FHIR server produktet
    • utviklet av Microsoft, men åpen kildekode
    • Finnes som PAAS tjeneste i Azure, men det er helt nytt, det er også søk på extensions
    • RESTful API for FHIR spek
    • Kjernelag for å plugge inn utvidelser
    • Persistence layer - pluggable mot MS SQL eller Cosmos db
  • Cosmos db
    • Dokumentdatabase som tjeneste i Azure
    • Operasjoner innen en partisjon er billig, men spørringer på tvers av partisjoner er dyrt
    • Transaksjoner er bare mulig innenfor en transaksjon
    • Ingen skjema eller duplikatkontroll
    • Endringskø gir alle endriner i serveren
  • MS FHIR + Cosmos db
    • Alle FHIR-ressurser i en container
    • Partisjonsnøkkel er ressurs-id
    • Versjoner legges i samme partisjon
    • Effektivt søk gjennom “meta” modell
      • dokument med feltene som er promotert for søk
      • Søke parametere som egne dokumenter
      • Nye paramtere krever at alle meta-dokumenter blir oppdatert
    • Transaksjoner er ikke støttet
    • Søk på tvers av FHIR ressurser blir dyre spørringer
      • Veldig effektivt å oppdatere/legge inn dokumenter
    • Løsningsskisse
    • Erfaringer
      • Microsoft server var bra valg
      • Fagsystemer kommer raskt på
      • Søk blir etterhvert veldig dyrt
      • Databasen blir etterhvert stor

spørsmål

Sensitive data?

  • fått en dispans siden den ble laget før Shrems 2
  • vanskelig i sky nå Proxy løsningen
  • Mange kommer med fødsel og personnummer
  • Relasjonsbase for å mappe mellom ofisiell id og syntetisk id
  • FHIR server støtter ikke multi tennant
  • Spesialregler håndteres i proxy Proxy støtter personkontekst?
  • Forsystemer må gjøre autorisasjon

SmileCDR erfaringer, plattform og arkitektur valg

Smile CDR og sky Egde Consulting, SmileCDR erfaringer

  • pasientopplfølgingssystem for evjeklinikken
  • kontinuerlig langtids hjerteovervåkning, backend
  • Helseintegrasjonsplattform og knutepunkt i sky SmileCDR
  • Generisk FHIR server
  • bygget fra HAPI fhir server
  • Java basert
  • støtter DSTU2 og oppover Arkitektur SmileCDR
  • Noder som kjører serveren
  • Moduler som kjører en bit av FHIR funksjonalitet
  • Kjøres som monolit eller kan splittes opp i noder Features
  • FHIR API, validering terminologi
  • Subscriptions
  • Egne søkeparametere
  • SMART on FHIR
  • Ekstern Id provider (openid-connect)
  • Audit log
  • monitorering
  • plugins
  • scripts FHIR API og persistering
  • støtter relational og non-relational database i bunn
  • Delete er soft delet, markeres i databasen som slettet
  • Mange relasjonsbaser og dokumentbaser støttet
    • Noe treghet ved queries
  • Komplisert databasemodell
  • Validering og terminologistøtte
  • Benytter referanseimplementasjon av validering
  • Sikkerhet og monitorering
    • Bruker manager
    • logging
    • 2FA
    • SMART on FHIR
    • monitorering
  • Erfaringer pasientoppfølgingssystem
    • SmileCDR hadde best støtte for features
    • nødvendige governance mekanismer
  • Backend for langtidslagring hjerteovervåkning
    • app for leger mot sensordata
  • Bruk av FHIr i integrasjonsknutepunkt
    • Bruke FHIR-server kjørende som container i kubernetes
    • Bruker per nå HAPI, microsft FHIR server ikke Smile
    • Kjører kubernetes cluster i privat sky basert på Azure stack
    • Integrasjon mot VKP, NHN og journaler
    • Også testet Kojin
  • SmileCDR
    • Fordeler
      • enkel installasjon
      • administrasjon
      • SMART on FHIR
      • ElasticAPM integrert
      • Multitenant funksjonalitet
      • Audit logg integrert
    • Ulemper
      • monolitt
      • vanskelig å tilpass
      • vanskelig debugging
      • kostbare og lite fleksible lisenser
      • utfordrende å skalere riktig
      • utfordrende å tilpasse til containerløsning

Kjernejournal erfaring med FHIR fasade

FHIR facade for å legge til FHIR funksjonalitet til eksisterende løsninger Portal på toppen

  • kjøre mot en FHIR server som håndterer funksjon og persistering
  • lage en custom implementasjon av FHIR på toppen av et selvvalgt persisteringslag FHIR fasade må
  • mappe til en underliggende datamodell (som kanskje eksisterer fra tidligere)

Når bør man bruke FHIR fasade?

  • enkle API, for eksempel noen få ressurser og transaksjoner
  • Noen søkeparametere
  • Det eksisterer data i et legacy system
  • Trenger mye fleksibilitet og kontroll over funksjonaliteten og hvordan den skal implementeres

Mapping er komplisert

Ulemper med å benytte FHIr fasade

  • Mange typer transaksjoner som må implementeres
  • Man kan neppe implementerte alle transaksjoner som støttes av standarden
  • FHIR informasjonsmodell er kompleks og består av generiske objekter
  • Krevende å håndtere flere FHIR versjoner (R4 og R5)
  • Krever større insats for å støtte ny FHIR profil
  • Betydelig arbeid knyttet til API’er som omfatter mange ulike FHIR ressurser

Neste steg tenker Kjernejournal å anskaffe en FHIR server, hvilken server og hvordan det skal gjøre det

Spørsmål

Fhirly server lagrer begge versjonene av dokumentene ved siden av hverandre (R4 og R5 for eksempel)

Mapping og profilstøtte man må uansett antakelig mappe fra og til FHIR uansett.

  • vil alltid være et pain-point med mye mapping.

Takk for møtet

Neste møte 2021-10-20 - Hendelser, Grunndata, hendelsesbasert arkitektur og Subscription