Tilgangskontroll
Arena har implementert avansert tilgangsstyring i henhold til prinsippet beslutningsstyrt tilgangskontroll (se Norsk EPJ Standard Del 2: Tilgangsstyring, redigering, retting og sletting). Tilgangskontrollmodulen i Arena ivaretar personvernlovgivingen nedfelt i norske lover og tilhørende forskrifter. Følgende lover er sentrale: Helseregisterloven, Helsepersonelloven og Pasient- og brukerrettighetsloven. Detforutsettes at bruker innehar grunnleggende kjennskap til lovverk, og spesielt krav til yrkesutførelse nedfelt i Helsepersonelloven.
Her beskrives hvordan den generelle tilgangskontrollen i Arena fungerer. Dokumentet vil gradvis erstatte "DIPS Classic Beslutningsstyrt tilgang" etter hvert som funksjonalitet flyttes over til Arena.
Oppsett av tilgangskontroll for de ulike Arena modulene, beskrives i hver enkelt modul sin brukerdokumentasjon.
Tilgangskontroll er en grunnmodul som er obligatorisk for alle brukere av Arena.
Tilgangskontroll i Arena er basert på prinsippet Beslutningsstyrt tilgang (BT) og benytter samme oppsett som DIPS Classic, og konfigureres i DIPS Admin. Prinsippet er at all tilgang til pasientopplysninger kan settes opp slik at det kreves et besluttet tiltak for å lese eller endre opplysningene. Et tiltak kan være et steg i et pasientforløp, for eksempel "henvisning til vurdering", "ventende pasient", eller ad-hoc tiltak som "henvendelse fra pasient". Et besluttet tiltak er alltid knyttet til pasienten tiltaket gjelder for.
Beslutningsstyrt tilgang består av to typer beslutningsmaler som styrer en brukers tilganger:
Implisitt tilgang (ordinær/underforstått tilgang)
Eksplisitt tilgang(når ordinær tilgangskontroll ikke dekker behovet)
Implisitt tilgang
Implisitt tilgang er det settet med tilganger en bruker får med utgangspunkt i stilling, organsiasjonstilhørighet og arbeidssted. Disse tilgangene skal være de tilgangene brukeren til enhver tid trenger for å utføre arbeidsoppgavene sine på en pasient i et behandlingsforløp/kontakt ved sykehuset.
Beslutningsmaler implisitt tilgang
Under vises en liste over de implisitte beslutningsmalene i prioritert rekkefølge.
Bruker har behandlingsansvar for pasienten
Krav
Kan settes opp med både tilgang før starttid og tilgang etter avslutning, men vil primært ha innvirkning når bruker er registrert som behandler på en planlagt kontakt. OBS! Bruker og rekvirentkode må være koblet sammen for at denne beslutningsmalen skal virke.
Beskrivelse
Brukeren er behandler for pasienten i følgende situasjoner:
Bruker/rekvirent er registrert som ansvarlig behandler på poliklinisk besøk.
Start: Inntid på konsultasjonen (dvs. at den planlagte kontakten må være hentet fra oppmøteliste/timebok og lagret) Slutt: Uttid på konsultasjonen eller Inntid + 1 dag dersom det ikke er registrert noen uttid.
Bruker/rekvirent er registrert som behandler på planlagt kontakt.
Start: Oppmøtedato Slutt: Utførtdato – som er datoen den planlagte kontakten blir hentet fra oppmøteliste/timebok og lagret
Bruker/rekvirent er registrert som ansvarlig lege på et postopphold
Start: Inntid på postoppholdet Slutt: Uttid på postoppholdet eller dato for endring av ansvarlig lege
Bruker/rekvirent er registrert som behandler innen en konsultasjonsserie i psykiatrien (trenger ikke å være satt som ansvarlig).
Start: Fra-tid som behandler i konsultasjonsserien Slutt: Til-tid som behandler i konsultasjonsserien
Bruker/rekvirent er registrert som koterapeut til en poliklinisk konsultasjon (gjelder psykiatri).
Start: Inntid på konsultasjonen (dvs. at den planlagte kontakten må være hentet fra oppmøteliste/timebok og lagret) Slutt: Uttid på konsultasjonen eller Inntid + 1 dag dersom det ikke er registrert noen uttid.
Dersom en ressurs settes inn på en planlagt aktivitet, vil det implisitt genereres en beslutning av typen «Bruker har behandlingsansvar for pasienten».
Beslutningen vil ha startdato en dag før angitt behandlingstid på aktiviteten, og sluttdato en dag etter.
Bruker er pasientens primærkontakt
Krav
Bruker og rekvirentkode må være koblet sammen for at denne beslutningsmalen skal virke.
Beskrivelse
Bruker/rekvirent er registrert som primærkontakt i postoppholdsbildet.
Gyldighet
Inntid på postoppholdet til Uttid på postoppholdet eller dato for endring av primærkontakt.
Bruker er journalansvarlig for pasienten
Krav
Bruker og rekvirentkode må være koblet sammen for at denne beslutningsmalen skal virke.
Beskrivelse
Bruker/rekvirent er registrert som journalansvarlig for pasienten i F5/Pasientopplysninger – Roller overfor pasient.
Gyldighet
Fra og med dato i "Roller overfor pasient" til og med dato i "Roller overfor pasient"
Bruker er koordinator for pasienten
Krav
Bruker og rekvirentkode må være koblet sammen for at denne beslutningsmalen skal virke.
Beskrivelse
Bruker/rekvirent er registrert som koordinator for pasienten i F5/Pasientopplysninger – Roller overfor pasient.
Gyldighet
Fra og med dato i "Roller overfor pasient" til og med dato i "Roller overfor pasient"
Bruker er informasjonsansvarlig for pasienten
Krav
Bruker og rekvirentkode må være koblet sammen for at denne beslutningsmalen skal virke.
Beskrivelse
Bruker/rekvirent er registrert som informasjonsansvarlig for pasienten i F5/Pasientopplysninger – Roller overfor pasient
Gyldighet
Fra og med dato i "Roller overfor pasient" til og med dato i "Roller overfor pasient"
Bruker har rolle overfor pasienten
Krav
Bruker og rekvirentkode må være koblet sammen for at denne beslutningsmalen skal virke.
Beskrivelse
Bruker/rekvirent er registrert med en rolle overfor for pasienten, med en type rolle som er definert i kodeverket lokalt. Denne vil slå til for alle rollekoder med unntak av "Journalansvarlig", "Koordinator" og "Informasjonsansvarlig". Ny rolle overfor pasient opprettes i kodeverket FE_ROLLEROVENFORPASIENT i DIPS Admin. +
NB! For å se data i skjermbildet "Roller overfor pasient" opprette nye roller og gjøre denne koblingen, må du ha tilgang til elementtypen "Arena roller overfor pasient".
Gyldighet Fra og med dato i "Roller overfor pasient" til og med dato i "Roller overfor pasient"
Innlagt pasient
Beskrivelse
Pasienten er innlagt.
Gyldighet
Start: Inndato for selve innleggelsen Slutt: sluttdatodato for selve innleggelsen På beslutningsmalen kan du angi antall dager bruker skal ha tilgang etter at beslutningen ikke lenger er gyldig. Dette skal gi tilgang til pasientens data x antall dager etter pasienten er utskrevet. Eks: Pasienten er innlagt på avdeling x og post a. Sykepleier har autorisasjoner som gir tilgang til pasientens data 14 dager etter evt. utskrivelse. Pasienten blir flyttet til post b, som sykepleier ikke har tilgang til. Det finnes dermed ikke lenger en gyldig beslutning for sykepleieren. Men sykepleier har tilgang til pasientens data 14 dager etter postoverflyttingen.
Åpen konsultasjonsserie
Beskrivelse
Pasienten har en åpen konsultasjonsserie. Sluttdato er ikke satt, eller sluttdato er frem i tid.
Gyldighet
Start: Konsultasjonsseriens startdato. Slutt: Konsultasjonsseriens sluttdato. Åpen så lenge det ikke er satt sluttdato
Poliklinisk besøk
Beskrivelse
Poliklinisk konsultasjon der sluttid er enten episodesluttid, eller – hvis det ikke er fylt ut – så er det en dag etter episodestarttid
Gyldighet
Start: Inntid på konsultasjonen (dvs. at den planlagte kontakten må være hentet fra oppmøteliste/timebok og lagret) Slutt: Uttid på konsultasjonen eller Inntid + 1 dag dersom det ikke er registrert noen uttid
Pasienten finnes på operasjonsoversikten
Beskrivelse
Pasienten er meldt til operasjon, enten til en bestemt dag, eller på venteliste til operasjon. Beslutningsmalen knyttes kun til lokalisering (operasjonsstedet) på planlagt aktivitet. Den vil altså ikke slå til for en bruker som mangler tilgang til denne lokasjonen, selv om pasienten nå er inneliggende på en enhet brukeren har tilgang til.
Gyldighet
Start: Dato for når operasjonen (planlagt aktivitet) blir opprettet Slutt: 24 timer etter Gitt tidspunkt på operasjonen
Planlagt oppmøte
Beskrivelse
Kan settes opp med både dager før og dager etter Pasienten har et planlagt oppmøte – dvs. en planlagt kontakt med oppmøtedato og klokkeslett (gjelder ikke kontakter med kun planlagt måned/år).
Gyldighet
Start: Oppmøtedato satt i feltet for Oppmøtetid i skjermbildet planlagt kontakt. Slutt: Utførtdato for den planlagte kontakten –som er datoen den planlagte kontakten blir hentet fra oppmøteliste/timebok og lagret
Ventende pasient
Beskrivelse
Det er en planlagt kontakt uten oppmøtedato – men med evt. oppmøtemåned.
Gyldighet
Start: Dato for når den planlagte kontakten blir opprettet. Slutt: Utførtdato for den planlagte kontakten –som er datoen den planlagte kontakten blir hentet fra oppmøteliste/timebok og lagret eller avsluttet på
Vurdert henvisning
Beskrivelse
Henvisning er vurdert (feltet for vurdering har en verdi).
Gyldighet
Start: vurdertdato for henvisningen Slutt: dagen etter vurdertdato for henvisningen
Henvisning til vurdering
Beskrivelse
Henvisning er registrert men ikke vurdert. (Feltet for vurdering er blankt).
Gyldighet
Start: mottatt-dato for henvisning Slutt: vurdertdato for henvisningen
Åpen henvisningsperiode
Beskrivelse
Pasienten har en åpen henvisningsperiode, dvs. at det er enten ikke-vurdert eller vurdert til behandles.
Gyldighet
Start: Mottatt-dato for henvisningen Slutt: Henvisningsperiodens avslutt-tid.
Oppgave i arbeidsflyt
Beskrivelse
Beslutning som slår til dersom det finnes en ikke utført oppgave i arbeidsflyt og som avsluttes når oppgaven er utført. Gjelder alle oppgavetyper. Tidligere het denne "Dokument i arbeidsflyt"
Gyldighet
Start: dato for når oppgaven ble opprettet eller dato i feltet "vises fra" Slutt: dato for når arbeidsoppgaven knyttet til oppgaven ble utført
Pasientadministrasjon
Beskrivelse
Dette er en beslutningsmal som brukeren ikke kan velge selv, men der beslutningen blir opprettet implisitt som en følge av at brukeren oppretter en ny pasient. Den vil i framtiden også bli benyttet på samme måte til andre funksjoner innenfor pasientadministrasjon. Beslutningsmalen blir også brukt når du aktiverer en pasient fra folkeregisteret som ikke har vært registrert som pasient tidligere. Se også Beslutningsmalen "Pasientadministrasjon".
Gyldighet
Start: Ved registrering av en ny pasient. Slutt: Denne har et døgns gyldighet.
Inneliggende ledsager
Beskrivelse
Ledsageren er inneliggende
Gyldighet
Start: Inndato for selve innleggelsen Slutt: sluttdatodato for selve innleggelsen
Autorisasjon gjennom organisatorisk tilgang
Når en hendelse trigger en beslutningsmal så registreres et besluttet tiltak. Et besluttet tiltak kan bli gyldige for en bruker gjennom én av to mekanismer. Enten ved at den er tildelt brukeren direkte (brukerrolle eller rekvirentkode), arbeidsgruppe brukeren tilhører, eller ved at den er knyttet til et sett med organisatoriske enheter brukeren har tilgang til.
Følgende beslutningsmaler vil autorisere gjennom organisatorisk tilgang. For å kunne brukes av en gitt bruker må den aktuelle brukeren ha tilgang til alle enhetene beslutningen er tilknyttet.
Tabell: Autorisasjon gjennom organisatorisk tilgang {#org-unit-authorization .tableblock .frame-ends .grid-none .stripes-odd .stretch}
For alle beslutninger vil sluttid bli satt hvis data slettes. For eksempel en innleggelse genereres en beslutning av typen "Innlagt pasient" med starttid lik innleggelsestidspunkt. Hvis innleggelsen slettes vil det bli satt sluttid på beslutningen. I tillegg vil beslutningen bli markert som slettet, og vil derfor ikke lenger kunne gi tilgang (uansett om autorisasjonen ellers gir tilgang noen dager etter slutttid).
Beslutningsmalene brukes for å gi tilgang til pasientopplysninger.
Beslutningsmalen "Pasientadministrasjon"
Denne beslutningsmalen ble innført med bakgrunn i krav om gyldig beslutning ved aktivering av pasient i Arena. Beslutningen blir automatisk (implisitt) brukt som begrunnelse for aktivering av pasient ved registrering av ny pasient og er nødvendig for å få aktivert den nyregistrerte pasienten.
Beslutningsmalen må som minimum knyttes til elementtypen Aktivering av pasient og Pasient administrative data for at du skal få opprette ny pasient.
Eksplisitt tilgang
Dersom du ikke har gyldig implisitt tilgang til pasienten du ønsker å aktivere må en eksplisitt beslutningsmal benyttes. Du må da ta et aktiv valg og velge riktig eksplisitt beslutningsmal utifra de valgene du har. Standard varighet for en eksplisitt beslutningsmal er ett døgn.
Meldt pasient
Meldt pasient (for eksempel fra legevakta eller ambulansen). Rekvirenten eller organisasjon som melder pasienten kan registreres.
Eksternt prøvesvar/notat til vurdering
Brukes for å åpne pasientens journal når en bruker har mottatt notat/prøvesvar som skal vurderes ut fra en sammenheng. Dette kan være enten eksterne dokumenter som er skannet inn eller interne dokumenter fra andre avdelinger innen foretaket. Avsender kan registreres fra rekvirentregisteret.
Internkontroll/Kvalitetssikring
Noen ansatte har som oppgave å kontrollere koder og andre registreringer i DIPS, kanskje også se på hvordan det registreres/dokumenteres m.m uten at brukeren deltar i behandling av pasient. Da kan denne beslutningsmalen brukes.
Forskning
Beslutningsmal som kan benyttes for å gi tilgang til pasientdata i forbindelse med forskning. Er lansert som inaktiv og de som ønsker ta den i bruk, må sette den gyldig i DIPS Admin.
Etterarbeide
Beslutningsmal som kan benyttes for å gi tilgang til pasientdata i forbindelse med etterarbeide. Er lansert som inaktiv og de som ønsker ta den i bruk, må sette den gyldig i DIPS Admin.
Undervisning
Besluttningsmal som kan benyttes for å gi tilgang til pasientdata i forbindelse med undervisning. Er lansert som inaktiv og de som ønsker ta den i bruk, må sette den gyldig i DIPS Admin.
IT-Systemarbeid
IT systemarbeid er en beslutningsmal som kan benyttes for å gi tilgang til journaldata når it-personell (på sykehuset / eller personell fra DIPS AS), må gjøre systemarbeid, feilretting og lignende på journaldataene.
Tilsyn på annen avdeling
Beslutningsmalen kan benyttes når en behandler bes om å foreta et tilsyn på en annen avdeling, og behandleren av den grunn ikke har ordinær tilgang til journalen. Det kan angis hvilken rekvirent som har bedt om at tilsyn skal foretas.
Henvendelse fra pasientens behandler
Behandleren kan registreres enten med rekvirentkode eller ved å søke fram organisasjon.
Henvendelse fra pasientens pårørende
Pasientens pårørende kan registreres ved å søkes fram fra folkeregisteret.
Tilsyn med helsepersonellets virksomhet
Tilsyn med helsepersonellets virksomhet. Denne eksplisitte tilgangen skal ikke settes opp med «selv tildeles». Det er ikke mulig å tildele denne til seg selv.
Statlig tilsyn
Statlig tilsyn er forankret i Helsetilsynsloven, Spesialisthelsetjenesteloven § 6-2 og Pasientjournalloven §26
Pasientinnsyn
Pasientens innsyn i egen journal. Brukes når en bruker, på forespørsel fra en pasient, bistår en pasient med innsyn i egen journal
Bestilling av dokumenter fra offentlige og juridiske instanser og forsikringsselskap
Bestilling av dokumenter fra offentlige og juridiske instanser og forsikringsselskap. Bestillers organisasjon kan registreres, men må finnes i organisasjonsregisteret.
Henvendelse fra pasienten
Brukes for å åpne pasienten journal når bruker får en henvendelse fra en pasient.
Egen læring
Begrunnelse forankret i Helsepersonellovens §29 c
Deltar i behandling av pasienten
Brukes blandt annet for regionale leseroller på tvers av foretak i basen.
Yte helsehjelp til annen pasient
"Yte helsehjelp til annen pasient" kan benyttes for å gi tilgang til pasientopplysninger på en pasient for å yte helsehjelp til annen pasient, jf. helsepersonelloven §25 b.
Administrasjon
For administrative oppgaver som feks skanning av dokumenter, endring av pasientopplysninger, kodekontroll o.l. NB: Det eksistrerer også en implisitt bestlutningsmal for administrasjon ("Pasientadministrasjon"), men det er ikke teknisk mulig å ha samme beslutningsmal som både implisitt og eksplisitt.
Henvendelse - annet
Behov for innsyn/registrering i pasientens journal på bakgrunn av henvendelse
Hver beslutningsmal for eksplisitt tilgang er en egen elementtype og kan settes opp på følgende måter:
Brukeren kan tildele seg selv tilgang gjennom beslutningsmalen
Brukeren kan tildele andre tilgang gjennom beslutningsmalen
Brukeren kan tildele både seg selv og andre tilgang gjennom beslutningsmalen
For å dra nytte av den eksplisitte tilgangen må mottageren også være tildelt tilgang til data ved hjelp av den aktuelle beslutningsmalen.
Eksempel på eksplisitt tilgang
En behandler har tilgang til pasientens journal mens pasienten er innlagt på avdelingen.
Etter at pasienten er utskrevet kommer det en telefonhenvendelse fra pasienten, men nå er data ikke tilgjengelige fordi kriteriet for denne implisitte beslutningen ikke lengre er oppfylt (pasienten er ikke lenger inneliggende).
Ved hjelp av den eksplisitt beslutningsmalen "Henvendelse fra pasient" vil behandleren igjen kunne få tilgang til data for en gitt tidsperiode.
Kriteriebasert egentilgang
Kriteriebasert egentilgang er en utvidelse av de samme autorisasjonene som gjelder for eksplisitt tilgang (elementtypekategori 4), ved at det i tillegg er mulig å angi et kriterium for når det skal være mulig å benytte den eksplisitte beslutningsmalen for tilgang til pasient (forutsatt at pasient ikke er sperret).
Med kriteriebasert egentilgang, vil det variere fra pasient til pasient om bruker kan få eksplisitt tilgang til pasient, og dernest hvilke besluningsmaler som kan velges som grunnlag for eksplisitt tilgang. Per i dag støttes kun ett kriterium: «Brukerrolle må ha hatt implisitt tilgang til pasient» inntil x antall dager tilbake i tid. Da vil beslutningsmalen være tilgjengelig dersom brukerrollen har hatt implisitt tilgang til pasienten en eller annen gang i perioden fra dagens dato og x antall dager tilbake i tid. Sjekken tar hensyn til tidligere implisitt beslutningens start og sluttdato, og ikke ekstra antall dager før eller etter. Denne logikken er felles for alle de implisitte beslutningsmalene som støttes.
Implisitte beslutningsmaler som kan benyttes som grunnlag for «Brukerrolle må ha hatt implisitt tilgang til pasient»:
Pasienten finnes på operasjonsoversikten
Åpen konsultasjonsserie
Inneliggende ledsager
Vurdert henvisning
Henvisning til vurdering
Innlagt pasient
Planlagt oppmøte
Poliklinisk besøk
Åpen henvisningsperiode
Ventende pasient
For å sette opp Kriteriebasert egentilgang, se IAM Admin CLI kubernetes-dokumentasjon: https://docs.dips.no/k8s/operations/modules/iam-admin-service/cli-operation-guide/
Oppsett av kriteriebasert egentilgang støttes i dwAdmin fra versjon 7.4.12.1.
Konseptuell beskrivelse
Hvordan fungerer kriteriebasert egentilgang?
Tilgangskontroll-hurtiginnføring
Aktiver pasient
Sett markøren i feltet for globalt søk i Arena eller bruk hurtigtast F3. Skriv inn navnet på pasienten, søket gir treff på pasienter og funksjoner, marker riktig pasient og venstreklikk.
Aktivere blålys
Har du tilgang til blålys finner du ikonet i pasientlinjen, sett musepekeren over ikonet og klikk en gang.
Hva har jeg tilgang til
Sett musepekeren over innlogget brukernavn i menylinjen, til høyre for globalt søk, og skjermbildet "Brukermeny" kommer opp, velg "Mine tilganger".
Brukerroller og passord
Dersom du har flere brukerroller kan du enkelt bytte brukerrolle, og du kan når som helst endre passord.
Reservasjon og samtykke
En pasient kan ha bedt om ulike typer reservasjoner.
Logging
Alle hendelser som besluttede tiltak, begrunnelse for aktivering av pasient og lesing, endring, opprette ny eller sletting av opplysninger logges.
Forutsetninger for å ta i bruk tilgangskontroll
Tilgangskontroll i Arena baserer seg på Beslutningsstyrt tilgang (BT). Dette forutsetter at sykehus som ønsker å ta i bruk Arena har gått over til BT før Arena kan tas i bruk.
Bruke tilgangskontroll
Aktivering av pasient
All aktivering av pasient i Arena krever en begrunnelse, i form av en beslutning som begrunner hvorfor du trenger tilgang. I DIPS Classic finnes dette kravet kun ved åpning av listen med journaldokumenter for pasienten, og i noen andre journalrelaterte skjermbilder. I Arena er dette kravet flyttet, slik at det allerede ved aktivering av pasient gjøres en sjekk på eksisterende beslutninger. I de fleste tilfeller vil du ikke merke noe til det. Dersom det allerede finnes en "Implisitt" beslutning (se Implisitt tilgang) som autoriserer deg, f.eks. fordi pasienten er inneliggende eller har en henvisning som skal vurderes, vil du få aktivert pasienten automatisk basert på denne beslutningen.
Dersom det ikke finnes noen slik beslutning, vil du måtte angi en "eksplisitt" begrunnelse (se Eksplisitt tilgang) for åpning av pasienten journal, slik skjermbildet nedenfor viser:
I linjen "Velg beslutningsmal" trykk på pil ned i nedtrekkslisten, da listes opp begrunnelser som du har tilgang til for å åpne journalen. Marker en begrunnelse med musen eller piltastene på tastaturet. Trykk knappen: Enter eller klikk med musen.
Feltet "Oppgi begrunnelse" er et fritekstfelt hvor du skriver inn begrunnelse for åpning.
OK Åpner tilgang til pasienten.
Avbryt Tilbake til startsiden.
Dersom du ikke har tilgang til selv å angi begrunnelse, vil det komme melding om at du ikke har tilgang til pasienten. Da må du kontakte systemansvarlig hvis du mener det er feil.
Begrunnelse for innsyn
I pasientmenyen finner du valget, Begrunnelse for innsyn. Her kan du til enhver tid se begrunnelsen du har brukt for å aktivere pasienten.
Det kan være tilfeller der du ønsker å endre begrunnelsen, fordi nåværende begrunnelse ikke stemmer med ditt pasientarbeid i dag.
Et eksempel Pasienten er inneliggende på en sengepost der du jobber noen dager i uken. Du har implisitt tilgang via beslutingen Innlagt pasient som systemet har valgt etter innebygget prioritet mellom beslutninger. Pasienten har et planlagt oppmøte på poliklinikken. Du jobber også på poliklinikken og skal forberede pasientens besøk der. Din brukerrolle har tilgang til beslutningen Planlagt oppmøte. Du ønsker da å bruke Planlagt oppmøte som begrunnelse og velger den. Se også Implisitt tilgang.
Nåværende begrunnelse
Her vises nåværende begrunnelse. Du kan bare ha en aktiv begrunnelse.
Ny begrunnelse
Her kan du velge ny begrunnelse. I listen kan du finne både implisitte og eksplisitte beslutninger. Listen er basert på hvilke beslutninger din brukerrolle har tilgang til. Den er sortert alfabetisk.
Utdypende begrunnelse for aktivering av pasient
Her kan du skrive en utdypende forklaring på hvorfor begrunnelsen er benyttet. Det er plass til 2000 tegn i feltet.
Tidligere begrunnelser
Listen viser hvilke begrunnelser du tidligere har brukt for å aktivere pasienten og tidsperioden begrunnelsen er brukt.
Utdypende begrunnelse for gitt tilgang
Feltet vises bare dersom du har aktivert pasienten basert på at andre har gitt deg tilgang, se Involver andre i pasientforløpet.
Tabell: Begrunnelse for innsyn {#Begrunnelse_for_pasientaktivering .tableblock .frame-ends .grid-none .stripes-odd .stretch}
Dersom nåværende begrunnelse ikke kan vises på grunn av feil, kommer det en feilmelding: Det oppstod en feil. Kan ikke vise begrunnelse for pasientaktivering. Valget Begrunnelse for innsyn er ikke aktivt. Prøv da å oppdatere skjermbildet (F5).
Du kan endre begrunnelse selv om databasen er i ReadOnly-modus og når du er pålogget med en ReadOnly brukerrolle, se ReadOnly brukerrolle.
Involver andre i pasientforløpet
I pasientmenyen finner du valget, Involvere andre i pasientforløpet. I noen tilfeller kan det være at du ønsker å involvere en eller flere av dine kollega i en pasientbehandling, men din kollega har ikke nødvendig tilgang. Da kan du tildele dine kollega tilgang, dersom din brukerrolle er satt opp slik at du kan tildele beslutninger til andre. Du kan bare tildele tilgang basert på eksplisitte beslutningsmaler.
Det er mulig å involvere andre i pasientforløpet uten at du har aktivert pasienten (menyvalg Pasient / Involver andre i pasientforløpet). Du trenger heller ikke ha tilgang til pasienten ("kollegialt besluttet tilgang"). Kravet er at brukerrollen din har autorisasjon til å tildele andre bruker tilgang for minst én beslutningsmal. Det er støtte for å gi tilgang til flere pasienter på en gang, for å gjøre det enklere å gi tilgang til en gruppe pasienter (f.eks. utvalg av pasienter til kontrollkommisjonen).
Når du tildeler tilgang til andre, tildeler du tilgang til en arbeidsgruppe eller en bestemt brukerrolle . Det kan være privat eller felles arbeidsgruppe. Brukere som er medlem av arbeidsgruppen vil da få tilgang til de data som foretaket har bestemt at de skal få tilgang til, gjennom den tildelte beslutningsmalen.
Det er ikke mulig å gi tilgang til seg selv.
Eksempel 1 En pasient er meldt på vei til akuttmottaket. Du jobber på akuttmottaket og har aktivert pasienten. Du har lest i pasientens journal for å sette deg inn i pasientens sykehistorie. Du ønsker å involvere en gitt kollega i pasientarbeidet. Din kollega har ikke nok tilgang til å vurdere situasjonen. Da kan du gi tilgang til din kollega basert på eksempelvis beslutningen Meldt pasient. Hun vil da få tilgang til de data som er satt opp at hennes brukerrolle skal få tilgang til gjennom beslutningen Meldt pasient.
Eksempel 2 Kontrollkommisjonen skal ha tilgang til data på gitte pasienter. Da kan du tildele tilgang ved å gi tilgang til en arbeidsgruppe kontrollkommisjonen har tilgang til, basert på eksempelvis beslutningen Internkontroll/Kvalitetssikring.
Pasienter
Her kan du søke opp pasienter du ønsker å tildele tilgang til.
Søk med pasient-id
Kryss av her dersom du ønsker å bruke pasientid for å søke opp pasienten.
Legg til i bulk
Trykk her dersom du ønsker å tildele tilgang til flere pasienter samtidig. Det åpnes da et nytt vindu, hvor du kan legge inn de pasientene du vil gi tilgang til. Pasientid kan legges inn som en kommaseparert liste.
Legg til aktiv pasient
Trykk her dersom du ønsker å tildele tilgang til pasienten du har aktiv.
Brukerrolle
Søk opp og velg den brukerrollen du ønsker å gi tilgang. Du kan ikke velge dine egne brukerroller, men du kan velge andre personer sine brukerroller. Du kan bare søke opp og velge arbeidsgrupper som tilhører samme sykehus som din brukerrolle.
Arbeidsgruppe
Søk opp og velg den arbeidsgruppen du ønsker å gi tilgang. Du kan ikke velge egen private arbeidsgruppe, men du kan velge andre personer sin private arbeidsgruppe. Du kan bare søke opp og velge arbeidsgrupper som tilhører samme sykehus som din brukerrolle.
Begrunnelse
Velg begrunnelse. I listen finnes bare eksplisitte beslutninger, basert på hva din brukerrolle har tilgang til. Listen er sortert alfabetisk.
Utdypende begrunnelse
Skriv en utdypende forklaring på hvorfor du ønsker å involvere andre/gi andre tilgang. Merk at bare de to første linjene du skriver vil vises i kolonnen Utdypende begrunnelse for gitt tilgang i pasientlisten Arbeidsguppe-tilgang.
Fra og med
Standard fra og med i dag.
Til og med
Standard en dag fremover i tid. Maksimal varighet på en tildeling er 1 år.
Send som oppgave
Huk av her dersom du ønsker at tilgangen skal bli sendt som arbeidsoppgave. Det vil da ikke være mulig å legge inn "Til og med", da tilgangen vil være gyldig til oppgaven er utført.
Tabell: Involver andre i pasientforløpet - Ny involvering {#Registrere_involver_andre_i_pasientforlopet .tableblock .frame-ends .grid-none .stripes-odd .stretch}
Når du har valgt en pasient for Involvering av andre, kan du se hvilke eventuelle nåværende og fremtidige tilganger som er gitt på pasienten av deg eller andre.
Når du har registrert Involvering av andre legges den i listen over Fremtidige og nåværende aktive tilganger i Historikk-fanen. Listen sorteres etter opprettet tid, de nyeste legges øverst.
Du kan redigere sluttdato og du kan kansellere en tildelt tilgang.
Du kan ikke se om den tildelte tilgangen er blitt brukt av den/de du har tildelt den til.
Du ser tilganger som din brukerrolle har tildelt i Historikk-fanen.
For å dra nytte av den eksplisitte tilgangen må mottager være tildelt tilgang til data ved hjelp av den aktuelle beslutningsmalen.
Som mottaker av tildelingen, se også Arbeidsguppe-tilgang.
Fremtidige og nåværende aktive tilganger
Viser hvilke tilganger du har tildelt, som er aktuelle nå og i fremtiden.
Utgåtte tilganger
Viser hvilke tilganger du har tildelt, men som ikke lenger kan benyttes, da gyldighetsperiode er passert.
Kansellerte tilganger
Viser hvilke tilganger du har tildelt, men som du har kansellert.
Tabell: Involver andre i pasientforløpet - Historikk {#Oversikt_over_involvering_av_andre_i_pasientforlopet .tableblock .frame-ends .grid-none .stripes-odd .stretch}
Du kan bruke funksjonaliteten Involver andre i pasientforløpet selv om databasen er i ReadOnly-modus og når du er pålogget med en ReadOnly brukerrolle, se ReadOnly brukerrolle.
Pasientutvalg: Pasienter autorisert gjennom funksjonalitet involver andre
Når noen tildeler tilgang til pasienter ved å bruke Involver andre i pasientforløpet, hvor tilgangen gis til din brukerrolle eller en arbeidsgruppe du er medlem av, vil du få tilgang til de data foretaket har bestemt at du skal få tilgang til, gjennom den beslutningsmalen avsender har gitt.
En pasientliste basert på pasientutvalget Pasienter autorisert gjennom funksjonalitet involver andre viser pasienter med aktive beslutninger som autoriserer deg gjennom brukerrollen eller arbeidsgruppen du er medlem av.
Bruk kolonneutvalg: Involver andre tilgang og Pasient (navn) som utgangspunkt for pasientliste.
Se Arena pasientliste-admin for oppsett/administrasjon av pasientliste.
Aktivere blålys
Blålys er en funksjon som kan benyttes i situasjoner der du har akutt behov for informasjon om pasienten, og du ordinært ikke har tilgang til informasjonen. Blålys skal være en sikkerhetsventil som kan brukes når behovet for informasjon er akutt.
Blålys kan bare benyttes når den aktuelle pasienten er aktivert. Klikk på blålys-ikonet oppe til høyre i pasientlinjen.
Når blålys aktiveres visualiseres det ved at blålys-ikonet får blå farge. Blålys blir aktivert både i Arena og Classic "embedded".
Blålys vil være aktivt i 24 timer, dersom det ikke slås av. Blålys vil være aktivt ved av og pålogging i Arena og Classic "embedded" så lenge det ikke slås av.
Ved bruk av blålys «kortslutter» du tilgangskontrollen og du får tilgang til alle medisinske data om pasienten, men det er noen unntak som det er viktig å være klar over:
Sperret pasient.
Sperrede dokumenter, se Dokumentreservasjon.
Pasientens sykehussperre, se Pasientens sykehussperre.
Journalgrupper som du ikke har ordinær tilgang til og heller ikke kan åpne med blålys, se Journalgrupper du ikke har tilgang til.
Systemoppsett "Adgangskontroll: Filtrer bort annet sykehus" på nivå 2.
Merk at bruk av blålys, samt begrunnelsen du oppgir ved aktivering av blålys logges i en egen blålyslogg, se Blålyslogg.
Blålys kan benyttes selv om databasen er i ReadOnly-modus og når du er pålogget med en ReadOnly brukerrolle, se ReadOnly brukerrolle.
For å få tilgang til blålys må du ha tilgang til funksjonselementet «Blålys».
Journalgrupper du ikke har tilgang til
Dersom du ikke har tilgang til en journalgruppe, vil du ikke nødvendigvis få tilgang til dokumenter i journalgruppen selv ved bruk av blålys. I oppsettet for hver journalgruppe er det et felt for å velge hvorvidt gruppen åpnes for tilgang ved bruk av blålys. Du må derfor vite hvordan dette er satt opp ved ditt sykehus for å vite hvorvidt du får tilgang her.
Mine tilganger
Klikk på eget navn oppe til høyre i Arena-vinduet, din Brukermeny kommer opp, velg Mine tilganger.
Formålet med Mine tilganger er å gi deg som bruker mulighet til å kontrollere om det er noe du burde hatt tilgang til, utover det du allerede har.
Mine tilganger åpner et nytt vindu med følgende arkfaner:
Kopier til utklippstavlen: For at formatet i utklippstavlen skal få god lesbarhet, må lim inn gjøres med monospaced font: https://en.wikipedia.org/wiki/Monospaced_font
Mine tilganger er også tilgjengelig via globalt søk F3.
Journalgrupper
Her vises hvilke journalgrupper din brukerolle ikke har direkte tilgang til eller blålystilgang til. Listen tar hensyn til tilgang som er gitt til andre sykehus via tilgangsprofil.
Formålet med listen er å gi brukeren anledning til å gjøre egenkontroll om det er journalgrupper som vedkommende burde ha hatt tilgang til av de som er mulig.
Navn: Navn på journalgruppen. Også journalgrupper som ikke er i bruk vises.
Sykehus: Hvilket sykehus journalgruppen tilhører. Felles betyr at journalgruppen ikke er knyttet til noe sykehus.
Blålystilgang: Angir om journalgruppen er tilgjengelig ved aktivering av blålys.
Se også kopier til utklippstavlen.
Arbeidsgrupper
Her vises en liste over alle arbeidsgrupper du er medlem av/har tilgang til. Oversikten viser nå-situasjon. Den viser ingen historikk.
Navn: Navn på arbeidsgruppen.
Sykehus: Hvilket sykehus arbeidsgruppen tilhører. Ingen betyr at arbeidsgruppen ikke er knyttet til noe sykehus.
Tildelt av annen bruker: Om en annen bruker har tildelt deg tilgang til arbeidsgruppen. En kollega kan for eksempel ha tildelt deg tilgang til sin private arbeidsgruppe for at du skal følge opp arbeidsoppgavene mens hun/han er på ferie.
Se også kopier til utklippstavlen.
Moduler
Her vises alle installerte Arena-moduler levert av DIPS AS. Den viser hvilke moduler din brukerrolle har tilgang til og hvilke den ikke har tilgang til.
Navn: Navn på modulen.
Har tilgang: Om din brukerrolle har tilgang til modulen eller ikke.
Har lisens: Om sykehuset som din brukerrolle er knyttet til har lisens på modulen eller ikke.
Elementtype: Navn på elementtypen modulen er knyttet til.
Listen kan sorteres alfabetisk ved å klikke på kolonnetittel.
Se også kopier til utklippstavlen.
Konfigurerte sider
Her vises hvilke konfigurerte sider som er aktivert i foretaket, og om din brukerrolle har tilgang til siden eller ikke. Konfigurert sider er sider som ditt foretak har konfigurert etter eget behov.
Navn: Navn på siden.
Har tilgang: Om din brukerrolle har tilgang til siden eller ikke.
Har lisens: Om sykehuset som din brukerrolle er knyttet til har lisens eller ikke.
Elementtype: Navn på elementtypen siden er knyttet til.
Se også kopier til utklippstavlen.
Pasientlister
Her vises hvilke pasientlister som er installert, og om din brukerrolle har tilgang til listen eller ikke.
Navn: Navn på pasientlisten.
Har tilgang: Om din brukerrolle har tilgang til listen eller ikke.
Har lisens: Om sykehuset som din brukerrolle er knyttet til har lisens eller ikke.
Elementtype: Navn på elementtypen listen er knyttet til.
Se også kopier til utklippstavlen.
Eksplisitte begrunnelser
Her vises en oversikt over alle eksplisitte begrunnelser som kan brukes. Du får kjapt oversikt over hvilke du kan bruke selv og hvilke du kan tildele andre.
Navn: Navnet på beslutningsmalen.
Er i bruk: Om beslutningsmalen er i bruk ved foretaket eller ikke.
Kan tildele seg selv: Om du selv kan bruke beslutningsmalen som begrunnelse.
Kan tildele andre: Om du kan tildele beslutningsmalen til andre.
Beskrivelse: En utfyllende beskrivelse om beslutningsmalen.
Se også kopier til utklippstavlen.
Innlogging
Arena krever brukernavn og passord for å kunne logge på. Administrasjon av brukere og rettigheter skjer i DIPS Admin.
Brukernavn og passord
Når brukernavn og passord er utfylt, blir knappen for å gå videre aktiv og du kan trykke på denne eller trykke «Enter». Dersom feil oppstår under pålogging, vises feilmeldingen i samme skjermbilde
Eksempelvis dersom brukernavn eller passord ble tastet feil eller at Caps Lock er på.
Dersom det logges inn med en ny bruker som nettopp er opprettet i Admin, må midlertidig tildelt passord benyttes. Passordet må umiddelbart endres ved først gangs innlogging i Arena. Du vil få opp felt for passordbytte hvor ønsket passord skrives inn. Velg ønsket brukerrolle for å fullføre påloggingen.
Dersom du har flere brukerroller, kan du markere en av brukerrollene som din standard brukerrolle. Dette forenkler påloggingen ved at du bare trykker Enter - Enter når du skal bruke standardrollen din, i stedet for å måtte klikke i listen hver gang.
Dersom du kun har en brukerrolle, velges denne automatisk.
Bytt brukerrolle
Dersom du ønsker å bytte brukerrolle uten å måtte logge av Arena kan du velge "Bytt brukerrolle" i brukermenyen. Menypunktet er kun synlig dersom:
Din bruker har flere brukerroller.
Arenapåloggingen ikke skjer via ContextSync. Det betyr at hvis Classic startes først, så vil ikke menyvalget vises i Arena.
I brukermenyen kan du også se eventuell utløpsdato på brukerrollen din. Utløpsdato kan være greit å sjekke for eksempel dersom du jobber som vikar og har fått forlenget vikarperioden. Da må også utløpsdato på brukerrollen din forlenges. Det må gjøres av systemansvarlig.
Logg av/bytt bruker
Dersom du ønsker å logge av Arena velger du "Logg av/bytt bruker" i brukermenyen. Innloggingsbildet kommer frem og en annen bruker kan logge på.
Bytt passord
Passord er gyldig i 3 måneder, og du må da bytte passord ved innlogging. I DIPS Admin kan du gi brukeren mulighet til å utsette dette X antall ganger for å unngå å bli hindret dersom en kritisk situasjon skulle oppstå. Passord kan også byttes ved å velge menypunktet «Bytt passord» under brukermenyen i Arena.
For å endre passord må du fylle inn det gamle passordet, og fylle inn nytt passord to ganger for å minimere at feil passord blir lagret. Du må i tillegg følge reglene for å fullføre passordbytte.
Regler for nytt passord:
Må inneholde tall
Må inneholde små bokstaver
Kan ikke inneholde mellomrom
Kan ikke inneholde brukernavnet
Må ha minimum 6 tegn
Begge passord må være like
ReadOnly brukerrolle
Dersom du har en brukerrolle der navnet på rollen slutter på ReadOnly vil denne rollen kun gi deg tilgang til å lese og skrive ut. Det er ikke mulig med denne rollen å endre, slette eller opprette nytt element. Det finnes noen unntak, for eksempel å registrere unntak fra reservasjon (Registrere unntak) og bruk av Blålys (Aktivere blålys). ReadOnly -brukerrollen kan gi mulighet til å lese pasientopplysninger ved andre sykehus i samme database, hvis det er satt opp slik. All «leseinnsyn» logges på vanlig måte i innsynsloggen.
Reservasjon knyttet til brukertilgang
Reservasjonsrett noe pasienten bestemmer og er hjemlet i pasient- og brukerrettighetslov § 5-3. Reservasjon er en ubetinget rett pasienten har når det gjelder bruk av journalopplysninger til helsehjelpformål. Krever pasienten visse opplysninger sperret, så skal de sperres for dem pasienten ikke ønsker skal få se opplysningene.
Samtidig finnes det begrensninger i pasientens reservasjonsrett både når det gjelder opplysninger til virksomhetens ledelse og pasientadministrative system og de situasjonene som faller inn under pasient- og brukerrettighetsloven § 5-3.
Pasientreservasjon (pasientsperre)
Dokumentreservasjon (dokumentsperre)
Pasientens sykehussperre
Her forklares hvoran de ulike reservasjonene (sperringene) visualiseres i Arena. For registrering av reservasjoner knyttet til brukertilgang, se registrere reservasjoner knyttet til brukertilgang.
Pasientreservasjon
Pasientreservasjoner kan gjelde enkeltpersoner eller alle.
Dersom pasienten er sperret for deg, vil du ikke få lov til å aktivere pasienten. I pasientlister er pasienten filtrert bort. En varsling om at det finnes sperrede pasienter vises med en rød linje nederst i listen.
Dokumentreservasjon
Dokumentreservasjoner kan gjelde enkeltpersoner eller alle.
Dokumentreservasjon gjelder for dokumenter i journalen til en enkeltpasient. Den gjør det mulig å sperre alle dokumenter, enkeltdokumenter eller en dokumenttype slik at alle dokumentene for en dokumenttype blir sperret. Dokumenter kan ikke sperres for journalansvarlig, forfatter og godkjenner av et dokument. Du kan opprette nye dokumenter selv om alle dokumentene i journalen er sperret. Tilgang opprettholdes for den som opprettet dokumentet inntil det godkjennes.
Pasientens sykehussperre
Pasientens sykehussperre gir pasienter mulighet til å reservere seg mot at brukere fra andre sykehus skal få tilgang til hans/hennes pasientopplysninger (Journal, Kontaktdata, Ventelistedata, Laboratoriedata, Psykiatridata, Medisinske data) ved sykehus A, når det er flere sykehus i samme database og det er gitt tilgang på tvers til sykehus A. Pasienten kan reservere seg mot innsyn på et eller flere sykehus i samme database. Pasientens sykehussperre brukes dersom pasienten ønsker å reservere seg mot felles journal på tvers av virksomheter som samarbeider etter Pasientjournallovens § 9.
Forskjeller mellom DIPS Classic og Arena
Tilgangskontrollen "flyttet frem"
EPJ Standarden stiller krav om at det skal angis og lagres en begrunnelse for åpning av pasientens journal.
I dag er dette løst ulikt i Arena og i Classic. I Arena er dette kravet flyttet slik at du allerede ved aktivering av pasient gjør en sjekk på eksisterende beslutninger. Men kun enkelte funksjoner i Classic har samme krav (bl.a. skjermbildet «Alle journaldokumenter»).
Vi anbefaler at dette settes opp likt for begge klientene ved å aktivere Systemoppsett: "BT-Classic: krever begrunnelse v. pasientaktivering" det vil da kreves begrunnelse ved aktivering av pasient i Classic også.
Pasientreservasjon
I Arena er sperrede pasienter filtrert bort i sin helhet og det visualiseres med en rød linje nederst i hver pasientlister. I DIPS Classic er sperrede pasienter sladdet eller stjernet ut.
I Classic kan du registrere Gyldig til dato på en pasientsperre, det kan du ikke gjøre i Arena. Dersom det er registrert en Gyldig til dato i Classic, får du aktivert pasienten både i Classic og Arena når Gyldig til dato er passert.
I Classic gjelder registrering av samtykker for pasientsperre per brukerrolle. I Arena gjelder den per bruker. Dersom det er registrert et samtykke for én brukerrolle i Classic, vil Arena tolke at dette gjelder alle brukerrollene. Du får altså aktivert pasienten i Arena fra hvilken som helst brukerrolle dersom det er registrert samtykke på minst én brukerrolle. I Classic får du kun aktivert pasient på den brukerrollen som det er gitt samtykke til. Dersom du åpner Classic fra Arena med en brukerrolle det ikke er gitt samtykke til, oppfører Classic seg som om den ikke har aktiv pasient. Du får ikke opp pasientrelaterte skjermbilder f.eks. Alle journaldokument (Ctrl+O).
Dokumentreservasjon
Journaldokumenter sperres ikke for journalansvarlig, forfatter og godkjenner i Arena. Før Classic v.7.4.8.0, sperres dokumentene for forfatter og godkjenner. F.o.m. versjon 7.4.8.0, fungerer dette likt med Arena.
I Arena opprettholdes tilgang til dokumentet for brukeren som opprettet det, inntil dokumentet godkjennes. Dette gjelder ikke i Classic.
Når du i Classic åpner journalen til en pasient med sperrede dokumenter vises varselet Det finnes data som er filtrert bort. Varselet vises i «utforsker» og «alle journaldokumenter». Varselet vises både når Classic kjøres "standalone" og "embedded" fra Arena. Et slikt varsel vises ikke i dokumentlister i Arena.
Når du i Classic "standalone" aktiverer en pasient med sperrede dokumenter vises en melding Det er registrert en eller flere journalsperringer på denne pasienten. En slik melding vises ikke i Arena eller i Classic "embedded" fra Arena.
Åpne sperret journal
For å kunne åpne en sperret journal i Classic må brukeren ha tilgang til både elementtypen "Tilgang til alle dokumenter uavhengig av samtykkekrav/sperring". I Arena kreves det ikke tilgang til elementtypen "Tilgang til alle dokumenter uavhengig av samtykkekrav/sperring" for å åpne en sperret journal.
Åpning av sperret journal i Classic gjøres ved å opprette en beslutning av typen "Åpne sperret journal - akutt helsehjelp". I Arena åpnes sperret journal ved å åpne pasientopplysninger / personvern / Reservasjon - Brukertilgang / Åpne sperret journal (se Registrere åpne sperret journal)
Håndtering av beslutninger for brukere som ikke kan gi seg selv tilgang
I DIPS Classic er det mulig å få tilgang ved å fatte en beslutning om tilgang til en arbeidsgruppe som du selv er medlem av, selv om du ikke har tilgang til å gi seg selv tilgang. Dette er ikke mulig i Arena. I Arena vil beslutninger som er fattet av pålogget bruker ikke ha noen effekt dersom beslutningen er tilknyttet en beslutningsmal brukeren ikke er autorisert for å tildele til seg selv. Det avgjørende er om brukeren var autorisert for dette på det tidspunktet da beslutningen ble fattet.
Gi andre tilgang/involvere andre i pasientforløpet
I Classic kunne du "gi" andre tilgang til å aktivere en pasient/åpne pasientens journal ved å sende en beslutning som "Gul lapp" i arbeidsflyt. Dette er ikke mulig i Arena. I Arena må du bruke funksjonaliteten "Involver andre i pasientforløpet" når du har behov for å gi andre tilgang, se Involver andre i pasientforløpet.
Pasientlister
Det skapte mange utfordringer da tilgangskontrollen i pasientlistene ble lagt om til å kreve beslutningsstyrt tilgangskontroll i Arena. Etter mange tilbakemeldinger på at pasienter som bruker har tjenstlig behov bare forsvant fra lista, samt utfordringer med ytelse, så har vi gått tilbake på dette. Flere og flere lister har nå endret til tilgangskontroll uten BT for lesetilgang slik at det ligner med slik det var i Classic. Hvilke lister det gjelder vil være dokumentert i versjonsdokumentasjonen.
Se forøvrig beskrivelse av anbefalt oppsett i admin-dokumentasjon kapittel 4.1.3.
Tilgangskontroll på lokalisering
DIPS Classic har begrenset støtte for tilgangskontroll på lokalisering. Den omfatter støtte for lokalisering i implisitt tilgang til pasient (fra og med DIPS Classic versjon 7.4.1: lokalisering på beslutningsmaler i kapittel Autorisasjon gjennom organisatorisk tilgang) og noen skjermbilder med pasientlister (fra og med 7.3.11/13: operasjonsoversikt, oppmøtelist poliklinikk, oversikt over polikliniske konsultasjoner og ventelista). Det blir imidlertid ikke sjekket lokaliseringstilgang i DIPS Classic på pasientopplysninger på en aktiv pasient i DIPS Classic (f.eks. henvisninger, kontakter, opphold osv.). I Arena støttes lokaliseringstilgang fullt ut i alle pasientlister og pasientopplysninger der lokalisering er angitt basert på krav i autorisasjonsoppsett. Det kan derfor i noen sammenhenger gis mer tilgang i Classic enn i Arena når det ikke er gitt tilgang til alle lokaliseringer.
Tolkning av inkonsistente autorisasjoner
I Classic er det slik at autorisasjoner blir tolket på strengeste måte, ved at tilgangen som er gitt til å endre/slette/skrive ut/opprette ny versjon av data ignoreres dersom lesetilgang mangler.
I Arena har vi forenklet dette ved å tolke det slik at endre/slette/skrive ut/opprette ny versjon også impliserer lesetilgang.
Dersom autorisasjonen er satt opp korrekt, vil Classic og Arena vise samme resultat. Men dersom det finnes inkonsistens i oppsett for autorisasjon, for eksempel at det for Journaldata er gitt endretilgang, uten lesetilgang vil du i Arena få lese data, men ikke i Classic. Det beste er å unngå inkonsistens i oppsett av tilgangskontroll, da det altså vil kunne føre til ulik tilgang i Classic og Arena.
Det finnes en rapport som viser inkonsistente autorisasjoner i databasen, rapport D-10621 "Autorisasjoner - sjekk konsistens". Den kjøres fra DIPS Admin.
Systemoppsett "Adgangskontroll: Filtrer bort psykiatri"
Systemoppsettet støttes ikke i Arena og vil heller ikke bli støttet i fremtiden. Som alternativ kan systemoppsett "Adgangskontroll: Filtrer bort data fra angitt enhet" brukes, inntil Arena får bedre støtte for pasientreservasjon knyttet til brukertilgang (sperrefunksjonalitet). Se nærmere beskrivelse i DIPS Admin.
Systemoppsett "Adgangskontroll: Filtrer bort annet sykehus"
I Arena støttes ikke systemoppsettet med parameterverdi=1. Se nærmere beskrivelse i DIPS Admin.
Systemoppsett "Journalansvarlig kreves før sperring av journal"
I Arena er det ingen sjekk på systemoppsettet "Journalansvarlig kreves før sperring av journal".
Aktivitetslogging
Alle hendelser som besluttede tiltak, begrunnelse for aktivering av pasient og lesing, endring, opprette ny eller sletting av opplysninger logges. Logging har flere formål. Først og fremst for kontroll av hvem som har lest i pasientens journal, der rutiner for etterkontroll er pålagt av myndigheter. I pasientjournalloven § 18 framgår det at retten til innsyn også omfatter innsyn i (logg over) hvem som har hatt tilgang til eller fått utlevert helseopplysninger som er knyttet til pasientens eller brukerens navn eller fødselsnummer. Logging for dette formålet kalles for innsynslogging. Andre behov er muligheten for å rette opp feilregistrereringer hvor tidligere opplysninger feilaktig ble overskrevet, der det er behov for å vite hvem som oppdaterte hva i forbindelse med tvistemål. Det kan også være behov for å vite når det ble logget på en brukerkonto for å finne ut om kontoen er brukt av andre enn eieren selv.
Det er flere typer logger:
Innloggingslogg
All innlogging logges i en egen innloggingslogg. Dette gjelder både vellykkede og mislykkede innloggingsforsøk. I tillegg logges tekniske databaseoppdateringer for eksempel oppgraderinger som endrer data i databasen, eksempelvis endring i/nye kodeverk. (DIPS publiserer sine databaseoppgradering som såkalte DUP-filer, Database Update Pilot).
Følgende informasjon lagres i innloggingslogg:
Dato og klokkeslett
DIPS-brukernavn som ble (forsøkt) brukt
Hvilken DIPS-terminal ble innloggingen / innloggingsforsøket gjort fra hvis kjent
Innloggingstype som ble brukt ved innloggingen
Valgt brukerrolle (kun ved vellykket innlogging)
Feilkode som angir årsak dersom innlogging mislyktes
DIPS-brukernavn kan både være en personlig bruker, men også en systembruker (teknisk bruker) for innlogging gjort av for eksempel DIPS Message Broker eller DIPS Kiosk.
Dersom innloggingen er et databaseoppdatering, vil DIPS-brukernavn inneholde navn på databaseoppgradering i stedet for reelt brukernavn.
Rapport for å hente data fra innloggingslogg: D-9929 Innloggingslogg for brukere.
Logg med begrunnelser for aktivering av pasient
Som beskrevet forutsetter all tilgang til pasient i Arena at det finnes minst ett besluttet tiltak knyttet til pasienten (implisitt eller eksplisitt registrert), og at brukerrolle har de nødvendige autorisasjoner som gir rett til å aktivere og lese pasientopplysninger basert på aktuell beslutningsmal.
Logg med begrunnelser for aktivering av pasient logger hvilket tiltak som ble benyttet som begrunnelse for tilgang til pasientopplysninger ved aktivering av pasienten.
Logg med begrunnelser for tilgang logger blant annet følgende opplysninger:
Navn og stilling på den som aktiverte pasienten i Arena
Besluttet tiltak (m/referanse til pasient) som ble benyttet som begrunnelse
Fritekstbegrunnelse
Tiltakets første loggedato
Tiltakets siste loggedato
I hovedsak vil tilgang gis implisitt ved at systemet selv finner ut om brukeren er involvert i et pasientforløp. Derfor er det typisk flere aktive besluttede tiltak samtidig som kan autorisere brukerrollen for tilgang, f.eks. «åpen henvisningsperiode», «poliklinisk besøk», osv. Tilgang kan også innvilges dersom andre har tildelt deg tilgang via Involver andre i pasientforløpet for eksempel «Tilsyn på annen avdeling», «IT-Systemarbeid», osv.
Dersom flere aktive besluttede tiltak autoriserer bruker, prioriteres tiltakene etter følgende kriterier punkt for punkt inntil du står igjen med ett besluttet tiltak som velges som begrunnelse:
Det besluttede tiltak som har lavest sekvensnummer. Hvis flere kvalifiserer, så …
velges det besluttede tiltak som er opprettet av den aktuelle brukerrollen selv. Hvis flere kvalifiserer, så …
velges det besluttede tiltak som er tilknyttet samme sykehus som brukerrollen tilhører. Hvis flere kvalifiserer, så …
velges det besluttede tiltak som er tilknyttet samme avdeling som brukerrollen tilhører (defaultavdeling). Hvis flere kvalifiserer, så …
velges det besluttede tiltak som ikke er avsluttet. Hvis flere kvalifiserer så …
velges det besluttede tiltak som er aktivt nå (her ser vi bort fra de som påbegynnes i framtiden) Hvis flere kvalifiserer så …
velges det besluttede tiltak med aktivt fra tidspunkt (dato + klokkeslett) nærmest nåtidspunkt.
Dersom det fremdeles finnes flere enn ett besluttet tiltak som kvalifiserer etter siste prioriteringsregel, så vil det være tilfeldig hva som velges.
For begrunnelser som velges automatisk etter reglene over vil fritekstbegrunnelse alltid settes iht. kodeverdi 0 i kodeverket BT-ACCESSREASON.
Dersom det ved aktivering av pasient ikke finnes besluttede tiltak som autoriserer for tilgang, vil bruker få melding «ingen journaltilgang». Da kan det likevel gis tilgang til å aktivere pasient med en eksplisitt beslutning (selvaktualisering), for eksempel når pasienten henvender seg på telefon til behandler eller IT-systemarbeid. Dette er begrunnelser som ikke er knyttet til et pågående pasientforløp. Dersom det er gitt tilgang til eksplisitte beslutningsmaler som kan benyttes for aktivering av pasient (se Aktivering av pasient), så vil en nedtrekksliste vises, samt muligheter for å oppgi fritekstbegrunnelse. Valget av beslutningsmal resulterer da i et besluttet tiltak med tekstlig begrunnelse som logges. Begrunnelser for selvaktualisering er spesielt interessant å overvåke.
Dersom du selv velger å opprette en ny eksplisitt besluttet tiltak til deg selv via grønnlys-funksjonen i Classic, så vil ikke det medføre at ny begrunnelsen logges.
Relevante rapporter:
A-1200 Pasientaktivering
D-9816 Eksplisitte beslutninger
Blålyslogg
I enkelte akutte situasjoner hvor det står om pasientens liv og helse kan det være behov for å kortslutte vanlig tilgangskontroll for de med rettigheter til det. Dette kalles for blålys i DIPS. All bruk av blålys logges i en egen blålyslogg.
Bruk av blålys må begrunnes spesielt med en fritekst-årsak.
Egen rapport for å hente data fra blålyslogg: D-6091 Blålyslogg. Blålys tas også med i rapport A-1200 Pasientaktivering.
Leselogg
Det finnes to typer leselogger i Arena:
Skjermbildelogg som logger hvilke siden som ble åpnet i Arena, se Skjermbildelogg
Dokumentlogg som logger hvilke dokumenter som ble åpnet, se Dokumentlogg
Skjermbildelogg
Skjermbildelogg logger åpning av siden i Arena. Det betyr at det logges hver gang du åpner for eksempel siden for operasjon, vedtak, pasientlister, oppgaver eller dokumentadmin. For sider som er åpne, vil det komme nytt innslag i loggen når man aktiverer ny pasient. Hvis du har flere sider åpne, vil det komme nytt innslag i loggen når du trykker på siden på nytt etter å ha vært på andre sider.
Loggen inneholder blant annet:
Teknisk navn på side
Brukerrolle-id
Tidsstempel
Arbeidsstasjonsnavn
Pasient-id (for pasientspesifikke skjermbilder)
For å se data fra skjermbildeloggen, kan du kjøre rapport A-1161 Innsynslogg sider og arkfaner.
Dokumentlogg
For opplysninger som klassifiseres som journaldokumenter (openEHR/EN ISO 13606 composition), logges det for journalaktivitet i en egen dokumentlogg. Dette gjelder også forhåndsvisning av dokument, feks via Dokumentliste. Loggen inneholder blant annet følgende opplysninger:
Tidspunkt for journalaktivitet
Journalaktivitet: 'Merknad', 'Innsyn', 'Utskrift', 'Slettet', 'Gjenopprettet', 'Godkjent', 'Opprettet', 'Ny versjon', 'Flyttet', 'Kopiert', 'EDI', 'Kopiutskrift', 'Lagret'
Dokument-id, dato, betegnelse på dokument som journalaktivitet gjelder for og avdelingstilknytning
Pasientens fødselsnummer og navn for journalaktivitet
Bruker og brukernavn til den som har foretatt journalaktivitet
Brukerrolle: Betegnelsen på brukerrollen som brukeren var innlogget med ved journalaktivitet
Navn på terminal journalaktivitet ble foretatt på
Det kan i tillegg knyttes en "Innsynsmerknad" til journalaktivitet, eksempelvis "Lytting til diktat" for journalaktivitet "Merknad".
Rapport for hente data fra dokumentlogg: A-1199 Dokumentinnsynslogg
Malvariabler for bruker og brukerrolle
Følgende malvariabler er tilgjengelige:
"BRU.NAVN": Brukernavn
"BRU.AVD": Avdeling
"BRU.INTERNTELEFON": Interntelefon
"BRU.PERSONELLKATEGORI": Personellkategori
"BRU.PERSONSOKER": Personsøker
"BRU.SIGNATUR": Brukersignatur
"SIGNATUR": Brukersignatur
"BRU.STILLING": Stilling
"BRU.BRUKERROLLEID": Brukerrolleid
"BRU.DIPSSIGNATUR": Dipssignatur
"BRU.BRUKERROLLENAVN": Brukerens navn
"BRU.BRUKERROLLEAVD": Brukerens standardavdeling
Vær oppmerksom på at ikke alle malvariablene fra Classic er støttet i Arena.
Sist oppdatert