Behov for å kunne filtrere mellom systemutledet tilgang og egenerklærte tilgangsbehov som grunnlag for tilgang

[richardhus]

Helseforetakene i Helse Sør-Øst har nå fått litt erfaring med å gjøre logganalyse basert på informasjon fra konsumenter som formidles til dem som kilder etter spesifikasjonen som Helse Sør-Øst startet med under utprøvingen. Blant de attributtene de så langt har funnet nyttige finner vi et boolsk flagg som indikerer om en tilgang er systemutledet basert på informasjon om helsepersonellet og pasienten som er registeret i PAS/EPJ (eventuelt i annet fagsystem) eller om tilgangen er basert på en egenerklæring av at helsepersonellet trenger tilgang til pasienten. Ønsker derfor å foreslå at denne typen informasjon innlemmes også i tillitsrammeverket.

[eirikbroen]

Er dettte synonymt med en blålystilgang/break the glass? Eller er det en spesiell form for egenerklæring?

Ikke uenig i at det kan være verdi å ta dette med. Har du et forslag til navn på attributt og hvor det passer i informasjonsmodellen? Tenker du at hvis verdi på denne er true så skal purpose_of_use_details inneholde begrunnelse?

[richardhus]

Blålystilgang/break the glass er en spesiell og ekstra kraftig form for egenerklært tilgangsbeslutning. Andre egenerklærte tilgangsbeslutninger i våre systemer kan være "Henvendelse fra pasienten" eller "Henvendelse fra pasientens behandler", som ikke nødvendigvis berettiger å overstyre pasientinitierte sperring som blålys/break the glass i noen tilfeller innebærer. Mens det flagget jeg ønsker inn her handler om å kunne formidle om tilgangen lokalt er innvilget som følge av en egenerklæring eller om det er en automatisert og systemavledet konklusjon basert på for eksempel administrative og logistiske opplysninger om helsepersonellet og pasienten. Eksempelvis når en pasient er inneliggende på en avdeling som helsepersonellet er gitt tilgang til, eller dersom det ligger en henvisning til vurdering hos en avdeling der helsepersonellet har i oppgave å vurdere henvisninger. Ytterligere et eksempel kan være at en kollega har sendt en arbeidsoppgave til helsepersonellet som gjelder denne pasienten, da gir systemet typisk tilgang på tross av at pasienten hører til en avdeling helsepersonellet i utgangspunktet ikke har tilgang til. Det er mange flere eksempler både på systemavledede tilganger og egenerklærte tilganger enn jeg har listet opp her, for DIPS-kunder kan man se den komplette oversikten over tilgangsårsaker her: DIPS care relation code system

Dersom verdien indikerer at det er en egenerklært tilgang er det i DIPS i dag et krav at brukere må oppgi en fritekst som utdyper hvorfor de tar seg tilgang til pasienten. Det er særlig relevant for eksempel for å dokumentere hvem pasientens behandler var når de tar seg tilgang i kraft av "henvendelse fra pasientens behandler". Dette vil ikke være et så strengt krav i samhandlingen mellom virksomheter, men dersom det finnes bør det kunne formidles i decsion_ref:user_reason heller enn i purpose_of_use_details. Og da bør dette kunne formidles også når helsepersonell frivillig har lagt inn utdypende begrunnelse ved systemavledet tilgang, for det er også mulig i DIPS (men det krever at helsepersonellet aktivt henter frem og legger inn en slik fritekst, så dette gjøres kun når helsepersonellet selv føler at det vil være lite intuitivt for utenforstående å forstå hvorfor de var inne på pasienten selv om det var systemutledet at de kunne få tilgang).

Jeg foreslår at informasjonen om dette (altså flagget for sann/usann) formidles enten som et eget underelement under decision_ref eller under purpose_of_use_details. I Hele Sør-Øst har vi latt oss inspirerer av HL7 FHIR som kaller dette for userSelected Coding, så jeg foreslår at det blir navnet. Jeg tenker dette passer best under decsion_ref ettersom man der er i kontekst av den spesifikke tilgangsbeslutningen som er gjeldende, mens purpose_of_use_details formilder koden fra kodeverket som inneholder de generisk tilgjengelige tilgangsbeslutningene. Det kan finnes tilfeller der den spesifikke koden i kodeverket for generiske tilgangsbeslutninger både kan være egenerklært og systemavledet (avhengig kontekst den brukes i). I så fall er decsion_ref et riktigere sted.

[richardhus]

@steinarnoem: Oppdaterer du informasjonsmodellen som du vurderer at dette passer best?

[eirikbroen]

En avklaring, det er kun snakk om å overføre om forespørsel om tilgang har skjedd på bakgrunn av en egenerklæring. En enkelt verdi for true/false og Ikke å overføre selve beskrivelsen?

Hvis vi skal skille mellom slik eksplisitt tilgangsbeslutning, bør vi også ta med flere koder under _purpose_ofuse ? Tenker da egentlig først og fremst på BTG slik at vi kan skille på faktisk blålys og andre situasjoner hvor f.eks en egenerklærling overstyrer standard tilgangsbeslutning i EPJ

[mortsten]

Støtter true/false sammen med purpose of use.

[steinarnoem]

Commit: https://github.com/NorskHelsenett/Tillitsrammeverk/commit/ba47175a7116d016553ec1c00b4cfcfefa62e0b0