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)
   • Dokument til kommentering, frist 12. mars
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

• Fagforum møte 4
• Egenbehandlingsplaner med CarePlan
• Besøksplaner i VKP
• CarePlan og Behandlingsplaner
• Tarmscreening
  • Kontakt tarmscreeningsprosjektets representanter for videre diskusjon
    • Jon Aarbakke ja@promis.no
    • “Linn Brandt” Linn.Brandt@ehelse.no

Velkommen presentasjonsrunde

Velkommen pluss chat.

Metode for områdeprofiler og kommentarrunde

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

• Dokument til kommentering, frist 12. mars

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.