Møte 13 i FHIR fagforum

  • Dato: 2022-08-31
  • Klokkeslett: 1300-1430
  • 54 personer innom møtet + noen i møterom

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

Sikkerhet og logging

  1. Velkommen og presentasjonsrunde, Thomas T Rosenlund, Direktoratet for e-helse (5 min)
  2. Informasjon fra HL7 Norge, Øyvind Aassve, Sykehuspartner (5 min)
  3. Intro til arkitektur for sikkerhet og logging og relevante FHIR ressurser, Thomas T Rosenlund, Direktoratet for e-helse (10 min)
  4. HelseID, Autentisering og autorisering av API tilgang, NHN, Dag Østerhagen (30 min)
  5. AuditEvent og loggoppslag, Trond Elde, DIPS, Richard Husevåg, HSØ, Helge Grimnes, OUS (40 min)
  6. Eventuelt og diskusjon

Presentasjoner

HL7 Norge - Øyvind AAssve, Sykehuspartner

  • WGM HL7 international i Baltimore
  • Behovet for forvaltningsorgan signalisert med brev til Direktorate for e-helse
  • Nasjonalt profileringshierarki
  • Aktiviteter i Norge - AuditEvent blir presentert idag blant annet

Intro til FHIR og sikkerhet

  • Datadeling er enkelt
  • målarkitektur for Datadeling
  • FHIR rammeverk for sikkerhet

HelseID, Autentisering og autorisering av API tilgang, NHN, Dag Østerhagen

HelseID for FHIR hoder

  • Har arbeidet med HelseID siden 2015
  • HelseID tilbyr pålogging for helsepersonell og single sing-on
  • To protokoller
    • OpenID Connect
    • OAuth 2
  • Terminologi - Client, Resource, Secret, Token, Identitetstilbyder, Authorization server
  • HelseID er en autorisasjons server
  • Token/sikkerhetsbillett
    • OpenID Connect identity tokens for klientapplikasjoner i innloggingsformål
    • OAuth 2 - Access tokens - tilgang til API
      • Klienten ser ikke på access tokens når kommunikasjon med API
      • Inneholder informasjon (sikkerhetsbillett)
      • Informasjonen kan brukes i logger
      • Formatet er JWT - JSON Web tokens
      • Valideres av de som skal tilgjengeliggjøre - API’et server siden
    • Token struktur, hode, kropp og signatur
    • Tokens inneholder attributter - claims/påstander fra utsteder
      • Standardiserte claims: Issuer, dato, expiry, audience (hvem skal ha), scope/rettigheter
      • Annen informasjon: identitet til helsepersonell, virksomhet og underenhet, påloggingsmetode, identitetstilbyder
  • Hva KAN token inneholde i fremtiden, fagsystem inneholder mye informasjon som ikke er gjenspeilet i dagens tokens
    • Hva trenger systemer av informasjon om helsepersonell, behandlingssted og pasient?
    • Kontaktinformasjon lokale rettigheter og grupper
    • Metainformasjon, kilde, tillitsnivå og type identifikator

Spørsmål

  • Må det være et kjent API?
    • Absolutt, bør bare gjelde API som skal eksponeres eksternt
  • Roller i Tokens?
    • Bare spesifikt for AMK per idag, minst mulig autorisasjon, vil helst ikke ha den biten i HelseID
  • Authorization service - tilgangsstyring er en egen greie,
    • Mye ekstraarbeid for å lage backend for å støtte dette
  • Samhandlingswebklient i kommune - behov for mer info fra token arbeidsforhold
    • Kjent problemstilling vi bør diskutere det direkte
  • Mer informasjon for å dele dokuemnter, mer kontekstinformasjon
    • Vi har teknisk løsninger for å få til dette på mange nivå, det diskuteres både juridisk og funksjonelt, vil kommer til en løsning.

AuditEvent og loggoppslag, Trond Elde, DIPS, Richard Husevåg, HSØ, Helge Grimnes, OUS (40 min)

Helge Grimnes - statistisk logganalyse fra HSØ og OUS Trond Elde - produktansvarlig for IAM i DIPS Richard Husevåg - arkitektu dokumentdelingsprosjektet HSØ

FHIR AuditEvent = Logging

  • Generell informasjonssikkerhet
  • Logging er grunnlag for å avdekke hva som har skjedd og omfanget
  • Innsyn i tilganger

  • Sporbarhet, grunnlag ved tilsynssaker

  • Basisinformasjon som alltid logges i HSØ
    • Hvem har gjort noen
    • Hvorfor (tjenstlig behov)
    • Hva som er behandlet
    • Når
  • Sikkerhetsbeviset i HSØ mappet til FHIR AuditEvent

Statistisk logganalyse

  • En logg bør bare inneholde aktiviteter hvor en bruker kan holdes ansvarlig for
  • Behov for så mye informasjon som mulig, loggen gir aldri fullstendig bilde av situasjonen
    • Formålet Oppslag som bryter med “snoke paragrafene (pasientjournalloven 16 helsepersonelloven 21)

Erfaring med innføring av FHIR AuditEvent

  • Trenger samkjøring
  • Økte krav til logging
    • Nye typer hendelser
    • Hva logges
  • Tømming av logger når de ikke trengs lenger
  • Status er at det er mye logger, men ganske rotete
  • Mange muligheter i AuditEvent, og en ganske generell ressurser
    • Tidspunkt
    • Type hendelser (grov inndeling)
    • Bruker inkludert rolle
  • Trenger en felles måte å utforme typer av hendelser for at det skal være gjenbrukbart på tvers av applikasjoner og virksomheter
  • Tydelige terminologibindinger i FHIR AuditEvent og kanskje profileringshierarki

Spørsmål

  • Forhold til data som logges på et år - ingen øvre grense kan bli veldig mye hva er mengden
    • Loggene er svære og må være svære, datamengden er ikke terabyte, noen hundre gigabyte
    • 400 mill oppslag i DIPS i året OUS
  • Forsiktig med å kalle dette logg, på utviklersiden så må vi ha tydelig ordbruk rundt hva som er hva av logger, logging på mange nivå
  • Statistisk logganalyse trenger store mengder data, og det er utfordringer knyttet til å overføre store megnder data mellom virksomheter. Er det mulig å gjøre analyse på tvers av virksomhetene uten at man har alle data lokalt?
    • Pasientbehandler kontekst-id - kan fungere som en slik enhet for slik

  • Sporingslogg/innsynslogg/revisjonslogg vs teknisk logg - begrep

  • Hvor lenge skal loggene oppbevares, bør kanskje bestemmes nasjonalt (Direktorat/Departement) for rammene for dette

  • Starte smått og få noen erfaringer, hvis man skal bruke FHIR så må vi ikke holde oss på lav modenhet i all fremtid men lage noe som er solid og som virker

  • Jeg som konsument av løsnignen trenger jo mye informasjon når jeg skal fylle min funksjon så blir litt urolig når jeg hører at loggen skal være liten og enkel. Vi trenger endel data.

  • Logging på tvers av systemer, men også håndtere applikasjonens krav til logging, der er det ikke greenfield

  • ingen fellesnasjonale krav i forhold til nasjonale tjenester

Eventuelt og diskusjon

Mange gode diskusjoner