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)
- All intern logikk bygges rundt interne datastrukturer
- 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.
- Valg bort FHIR database (Vonk m.fl.)
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