Møte 4 i FHIR fagforum

  • Dato: 2021-03-10
  • Klokkeslett: 1300-1500
  • 51 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 5 min (alle skriver i chatten hvor de kommer fra + aktuell erfaring/prosjekt)
  2. Informasjon om metode for utvikling av områdeprofiler 5 min (Thomas T Rosenlund)
  3. Informasjon fra HL7 Norge 5 min (Øyvind Aassve)
  4. Behandlingsplan/CarePlan 30 min (Ingvar Sørlien)
  5. Besøksplan i VKP med Careplan 15 min (Jørn Sikkerbøl)
  6. Digitale behandlingsplaner med CarePlan 15 min (Vidar Mehti)
  7. Diskusjon 15 min
  8. Tarmscreening 30 min (Jon Aarbakke/Marten Smits/Linn Brandt)

Presentasjoner

Velkommen presentasjonsrunde

Velkommen pluss chat.

Metode for områdeprofiler og kommentarrunde

Informasjon om metode for utvikling av områdeprofiler 5 min (Thomas T Rosenlund)

Info fra HL7 Norge

  • Vital Signs områdeprofilering

Egenbehandlingsplan Care Plan Ingvar Sørlien

  • Egenbehandlingsplan beskriver hvordan tiltak utføres av og med pasient
  • IHE Dynamic Care Planning DCP
  • Arkitektur for deling av og samarbeid om behandlingsplan mellom pasient og helsearbeider
  • Tar utgangspukt i FHIR workflow definition - Definition, Request og Event
  • Benytter FHIR ressursene
    • Guideline Template - PlanDefinition
    • Pasientens plan (draft) - CarePlan
    • Approved plan - DocumentBundle med signert CarePlan
  • Maler, PlanDefinition for eksempel for KOLS
    • Rammeverk for å håndtere maler
    • Definere regler når aktiviteter skal gjennomføres
    • Benytter ActivityDefinition for å beskrive aktiviteter som skal gjennomføres.
  • Apply Operation - å instansiere en template til en behandlingsplan
    • PlanDefinition, legge inn pasientinformasjon og opprette en CarePlan ressurs basert på dette
  • Dokument
    • Persistent
    • Stewardship - har en juridisk enhet med definert ansvar for vedlikehold
    • Sporbarhet og uaviselighet, kan signeres og knyttes til rodkjenner
    • Kontekst - beskriver sin egen kontekst
    • Helhet - Dokument betraktes som helhetlig mengde informasjon
    • Menneskelig lesbart - dokumentet skal kunne leses av mennesker
      • Ligger en HTML versjon av innholdet integrert i dokumentet
  • Rendring av dokumentet kan tilpasses for applikasjoner som kan lese strukturen
  • Nasjonal deling for eksempel via nasjonal dokumentdelingsløsning
  • Relevante ressurser om CarePlan og planning
    • DevDays foredrag
    • John Moehrke IHE ITI planning
    • IHE whitepaper

Spørsmål

  • FHIR APII som tilgangsmetode for CarePlan?
    • Ja, det er fint, men dokumenter gir noen funksjoner som vi trenger
  • Finnes mange prosjekter som forsøker å gjøre noe med KOLS, blant annet Epitale fra Danmark, 3P i Norge Nasjonal senter ehelseforskning
    • Kristiansand er en samarbeidspartner i prosjektet, Thelma
  • Bruker Bundle i kontekst av dokument, obligatorisk atributt som heter kode, er det gjort noen valg for dokumenttype?
    • Husker ikke, kan ta det offline
  • Trenger man document? mye metadata i CarePlan
    • Kunne hatt Careplan med mye contained
    • Kunne gjort det vanskelig å samarbeide og holde orden på versjoner
    • Bundle er bare et lag rundt CarePlan for å holde orden på sporbarheten
  • Kristine forholdet mellom pasientens behandlingsplan og pasientens journal løsrevet?
    • Egenbehandlingsplan kan være en del av journalen i en virksomhet juridiske enhet/system

Velferdsteknologisk knutepunkt og behandlingsplan

  • VKP handler om å knytte Velferdsteknologiske løsninger tettere til kommunenes journalsystem
  • Journalføring av informasjon fra VKP
  • CarePlan brukes i velferdsteknologi til besøksplan
    • Hente besøksplan fra EPJ
  • Søke med API etter CarePlan med identitet på pasient
  • Profil av CarePlan for å representere besøksplanen
    • Activity beskriver besøkene som er planlagt og gjennomført
    • Lite annet i ressursen som benyttes
    • subject, author, period, activity
  • Ved søk på fødselsnummer benyttes POST interaksjon og _search med fødselsnummer i body for at ikke pasientidentitet skal havne i HTTPS header og HTTP logger

Spørsmål

  • CarePlan category være et kodeverk på Volven?
    • Ja, det bør det være, men det ligger ikke der ennå.
  • Samme gjelder description?

HL7 FHIR for Behandlingsplanerl

  • Helsedirektoratet og Rambøl
  • Helhetlig behandling man skal understøtte helhetlig behandling av pasienten
  • Systemene til de forskjellige delen av helsetjenesten snakker dårlig sammen
  • OVersikt over personenen hvilke helsepersonell som er involvert i oppfølging av tiltakene og oversikt voer tiltak som er planlagt
  • CarePlan elementer - sentrale
    • Condition
    • Goal
    • Careteam
    • Activity
  • Pasienten skal ha en egenbehanldingsplan
    • Sammendraget skal gi informasjon om hva som eksisterer av behandlingsplaner for pasienten.
  • Teknisk konsept for å dele informasjonen om behandlingsplan mellom aktørene
    • Sentral nasjonal lagring i KJ er et av konseptene
    • REST API for tilgang til behandlingsplanen (hva med skriving?)
      • Integrasjon mot nasjonal portal
      • EPJ systemer
      • Inbygger relaterte tjenester
      • helsenorge - nasjonal portal
  • Maler bør eksisterer for noen pasientgrupper
    • Generisk behandlingsplan
    • Der det ikke eksisterer diagnose, egen mal?
    • Dagens papirskjema kan integreres i løsninger
  • Mappe skjema til CarePlan i FHIR

Spørsmål og diskusjon CarePlan

  • Standarder knyttet til malene, generelle maler, konsensus rund malverket
  • Fordeler sentralisert vs desentralisert løsning
    • Noen kombinasjoner av lokale kopier og sentral lagring
    • Bruker API bruke leverandører
    • Åpne API for å få til innovasjon
  • Dokumenter og dokumentbruk - SNAPshot av en tilstand og sikre historikken
    • Sikre versjonering med Bundle
  • Nasjonalt profileringsarbeid - koble det opp mot intro om områdeprofilering
    • Viktig at koding blir gjort riktig og enhetlig i Norge, dekker det totalbehovene
    • Flere prosjekter som bør koordineres for behandlingsplan/besøksplan
    • Egenbehandlingsplan hvilke maler bør vi forholde oss til
  • Arkitekturspørsmål med sentralisterte løsninger, hva om den feiler?
    • Robusthet og tilgjengelighet - mange aspekter og mange tiltak man kan gjøre for å sikre robusthet og tilgjengelighet - må planlegges for
    • Deling av informasjon på tvers
  • Desentraliserte løsninger med åpne API’er og hvordan håndtere sikkerheten? VKP vs overvåkning
    • Viktig å arbeide med dette og ta hånd om dette i utviklingen av slike løsninger
    • Enklere å plassere ansvaret når kommunen eier tjenesten og utstyret
    • Helsepersonellet utstyret pasient med devicer og data
  • Angående arkitektur - Åpenbart og logisk med sentralisert infrastruktur med mange fordeler, men også noen ulemper og utfordringer
    • Innspill at prosjektene må gjøre grundig arbeid med å håndtere utfordringene med sentralisert arkitektur
  • Jobber med klinisk informasjonsmodell for behandlingsplaner, kan gjerne dele og diskutere denne med noen med medisinsk fagkunnskap (Bent)
    • Sverre vil gjerne se på den
  • Nasjonal konsolidering - som allmennlege tenker jeg at noe som er generisk i profilen har stor verdi, utvide med profiler der det er spesifikke behov. Egenbehandlingsplan bør samle trådene. Mest mulig generiske plan definitions og profiler for å etablere infrastruktur og arkitektur
    • Planlegger å starte med MVP med en enkel plan som dekker de viktigste
  • Journaldelingsprosjekt i helse-vest og helse-nord
    • Har jobbet mye med like problemstillinger i dette prosjektet
    • Ikke teknisk men juridisk og organisatorisk
    • Mye arbeid på å arbeid med å dele journaler
  • Dokumentdeling skal ikke kopieres men legges ett sted, mens disse dokumentene skal samhandes og samarbeides rundt

Tarmscreening

  • Jon Aarbakke, Linn Brandt og Martens Smiths
  • Strukturerte data på HL7 FHIR format sendes til Kreftregister og Gastronet
    • Fleksibelt er bra og dårlig
  • Prosjektet skal lage løsning for å sende en stor rapport til noen få aktører
  • Tar informasjon fra strukturert via et FHIR API
  • Arkitektur - sende og motta rapport - implementert med API i kreftregisteret
  • Status
  • FHIR work
    • Consider standardized terminology: SNOMED CT
    • Stay true to FHIR where possible, use clinical FHIR resources, and not QuestionnaireREsource
    • Add extension where FHIR does not provide them
  • Overall structure
    • A bundle of type Collection
    • Not a Document, because it contains no human-readalbe part
  • Bundle
    • Patient, Procedure, DiagnosticReport
    • Medicationlist, ProblemList, MedicationStatement, Observaion, Condition
  • Issues along the way
  • Profiles
    • Procedure
      • a lot of extension to provide data specific to registries
      • Observations with slicing for different kinds of reports
  • Hva er spesielt med registre
    • Koloskopiskjema
  • Stort fokus på terminologi og kodeverk
  • Problemstillinger underveis
    • Skal vi gjøre det lett eller vanskelig? Ressurser kliniske istedenfor QR
      • Bruker data generert andre steder på en bedre måte enn med QR
      • Vanskeligere på kort sikt i forhold til sending og mottak
      • QR eller extensions for spesielle datatyper
      • Ingen QR overhode, selv om hypotesen var å benytte QuestionnaireResponse til mye data
    • Medisinsering
      • mange norske medisinering prosjekter
      • Samkjørt med SFM-PLL, sykehus er vanskeligere
      • SAFEST er ikke integrert
      • Behov: total mengde som blir gitt av et medikament
        • SFM - har en extension men den så ikke ut til å dekke behovet
  • Fortsatt rom for justeringer så kom med kommentarer
  • Registre er spesielle
    • Trenger spesifikk data, men den må være gjennomførbar for klinikerne
      • Bedre integrasjon med journal burde kunne avhjelpe?
    • Bruke terminologibegrep som er standardiserte
    • Clinical drug i SNOMED product containing (virkestoffer)

Eventuelt

Takk for møtet.