Møte 18 i FHIR fagforum

Dato: 2023-05-24
Klokkeslett: 1300-1500
59 personer innom møtet

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

Agenda: FHIR infrastruktur og arkitektur

Velkommen, Thomas Tveit Rosenlund, Direktoratet for e-helse (10 min)
Info fra HL7 Norge, Øyvind AAssve, Sykehuspartner (5 min)
Pasientsentrisk plattform for helsedata, Ingvar Sørlien, Siemens Healthineers (30 min)
Pasientens måledata – en oppfølger til Pasientens prøvesvar, Ivar Yrke, Norsk Helsenett (30 min)
FHIR facade og health gateway, Andy Harrison, Egde (30 min)
Eventuelt og diskusjon (15 min)

Presentasjoner

HL7 Norge - Øyvind AAssve, Sykehuspartner

HL7 FHIR Release 5 er ute
- Bruk av R5 er ikke tvingende nødvendig, anbefales å bare ta i bruk R5 ved greenfield
HL7 Norway med profileringsierarkiet
Workshop 13 juni om Appointment/response
Edenlabs 20 juni seminar profileringsverktøy

Spørsmål

Definisjon av domene/fagfelt?
- Dette er under modning

Intro til server og facade - Thomas Tveit Rosenlund, Direktoratet for e-helse

Facade vs full FHIR server

Pasientsentrisk plattform for helsedata, Ingvar Sørlien, Siemens Healthineers

Deling av data ved hjelp av FHIR for å understøtte sømløs integrasjon mellom virksomheter og i et pasientforløp.
IHE affinity domain - deling av dokumenter krever mange fellestjenester
Dokumentdeling hva har det med FHIR å gjøre
- Snakker ikke om PDF dokumenter men strukturerte dokumenter som FHIR document eller CDA
Eksempel på dokumentdeling - sykehus, prøvesvar, jorunalnotat og labsvar
- mXDE og QEDm profilene til IHE
Master Patient Index - håndtering av pasientinformasjon og pasientidentitet
- Hjelpenummer eller andre ufullstendige identifiseringer må kunne slås sammen med kjente identiteter med verifisert fødselsnummer
Discret data management - Sykehus i tyskland må ha data lagret på eiendommen.
Tilgangsstyring - er komplisert - konfidensialitetsnivå pr. dokument
Sjekke om den som spør om dokumentet faktisk skal ha tilgang

Spørsmål

Data som tilhører flere dokumenter?
- Kan diskrete elementer av dokumentet brukes i andre sammenhenger?
- Tilgangsstyring vil i utgangspunktet være knyttet til et bestemt dokument
Dokument brukes typisk om pdf, hvorfor bruker vi det om strukturerte data?
- Dokumenter kan være strukturerte og ikke bare pdf.

Pasientens måledata - PMD - Ivar Yrke, NHN

Samle og tilgjengeliggjøre måledata i løsningen
Innkommende målinger fra DHO sammenheng
Informasjon som samles innn til kommunens journal kan tilgjengeliggjøres til andre virksomheter som trenger informasjonen - ligner på pasientens prøvesvar.
Data inn på FHIR og ut på FHIR
- Datastrukturene er relativt enkle
Innkommende data er:
- FHIR Observation
- FHIR PractitionerRole med organization (kommune) og practitioner (pasienten)
- Trenger informasjon om kommunen for å filtre og tilgangsstyre tilgang til bare egne data, data fra en kommune.
VKP profiler for observasjoner
- Bruke nasjonale profiler for observasjonene
Data lagres på internt format (domenemodeller)
- Preprosessering og pseudonymisering slik at informasjon som er lagret ikke kan identifiseres hvisd et kommer bort
- Lagres i MongoDb - dokumentdatabase
Data pakkes på etterspurt format ved utlevering
- Hvilken som helst FHIR versjon eventuelt andre formater
Ingen binding til FHIR versjon i den interne modellen, det kan pakkes ut på andre modeller senere.
- All intern logikk bygges rundt interne datastrukturer
  - Tilgangsskontroll er viktig del av den interne logikken
- Utpakking til utdataformat skjer on-demand
- Robusthet ved å ha lokal kopi av alle data man er avhengig av for å levere svar (persontjenesten, personverninnstillinger)
Teknologi(bort)valg
- Valg bort FHIR database (Vonk m.fl.)
  - Blandede erfaringer med ytelse
  - Sterk låsing til innkommende format/versjon av data, sterk låsing i Vonk til eksisterende FHIR versjon når data kommer inn
  - Fasade som lager FHIR på vei ut
- Skulle hatt erfaring med bruk, utviklingen ligger foreløpig på is.

Spørsmål

Er FHIR fasaden egenutviklet?
- Utgangspunktet basert på Spark open source
- Mye av det de trenger er støttet i Firely SDK
Dere kan ta imot fra hvem som helst kommune/sykehus etc?
- Kildeutvalget kan utvides etterhvert.

Infrastruktur og arkitektur - Egde

Andy Harrison, Fionn Bass (Tigeni) og Jan Ivar Øyulvstad
Egde Health gateway
Behov for konvertering inn og ut av FHIR
Etterhvert som man bygde flere prosjekter kunne man gjenbruke komponenter mellom prosjekter
Mange kunder har god backend, men trengte FHIR backend services
Egde Health Gateway
- Different projects
Tigeni - leverer hjemmeprøvetaking for blodprøver
- Tilkobling til NHN gjennom Egde
Arkitektur for Egde Health Gateway fokus på mange til mange integrasjoner
- API-data og meldinger
- Tiegi og ABEL integrasjoenr
- Ulike plattformer
  - FHIR REST (VKP og OPendips)
  - Partner API (soap og rest)
  - Partner API client (soap og rest)
  - Meldingsutveksling (SMTP eller AMQP)
- Kapabiliteter på plattform, lagring (SQL/dokumentdb), datakonvertering og intern formidling
- Kan støtte samme data til mange ulike behov (meldinger/dokumenter/API)
- Consent flyt for å dele data mellom virsomheter på plattform
Godt begynt
Implementation guides
- Egde Health gateway baserer seg på no-basis der det er relevant
- internasjonale profiler er også relevante
- Egen IG for different products

Spørsmål

Hvordan sikrer dere at data alttid hentes ut i riktig kontekst, og at det ikke finnes nye oppdateringer? spesielt knyttet til pasientens prøvesvar
- Ved API brukes SMART on FHIR på Tigeni og helseid maskin til maskin
- Pasientbasert app med pasientkontekst eller …
- Meldingsflyt
- Pasientens prøvesvar sender data inn via EDI, men har en FHIR utdata
- Facade som benyttes - Firely SDK benyttes ved mappes
- Helsepersonell logger seg på så er det greit, hva med pasienter som logger seg på via HelseID og bankid