1. Introduktion

1.1. Formål

Formålet med dette dokument er at beskrive de brugerhistorier (user stories) der understøttes af Samtykkeservicen. 

Brugerhistorier er overordnede beskrivelser af funktionalitet og mål set fra brugeren/anvenderens synsvinkel. Brugerhistorierne er ikke beskrevet udfra en teknisk synsvinkel med udfra en forretningsmæssig brug af Samtykkeservicen.

For en teknisk gennemgang af de i dette dokument skitserede brugerhistorier henvises til Samtykkeservicen - Anvenderguide.

Den første del af dokumentet beskriver de forskellige brugertyper/aktører af Samtykkeservicen.

Derefter listes de enkelte brugerhistorier med en overblikstegning, der viser, hvilke aktører, der optræder i de enkelte brugerhistorier.

Hver brugerhistorie gennemgås derefter - herunder en gennemgang af acceptkriterier. Der gives eksempler på konkrete instanser af brugerhistorien i form af scenarier.

1.2. Læsevejledning

Læseren af dette dokument kan være forretningskonsulenter og/eller arkitekter fra NSP anvenderorganisationer, der ønsker at vide, hvordan Samtykkeservicen kan anvendes til at opfylde forretningsmæssige behov.

Læseren forventes at være bekendt med spærring og samtykke som koncept.


2. Brugertyper i Samtykkeservicen

I Samtykkeservicen arbejdes der med følgende brugertyper:

  • Borger
  • Borger på vegne af borger - fuldmagt (for nuværende deaktiveret)
  • Systembruger
  • Medarbejder på sundhedsområde med National rolle: SpaerAdminR8

Den tekniske definition af disse i forhold til, hvordan de i praksis valideres er bekrevet detaljeret i Samtykkeservicen - Arkitektur og Design.

Overordnet set, så består Samtykkeservicen af to overordnede områder:

  • Administration: Oprettelse og nedlæggelse af spærringer for en borger - både dataspecifikke og mod sundhedspersoner
  • Verifikation: Filtrering af en liste af data i forhold til dataspecifikke spærringer samt verifikation om, hvorvidt en specifik borger har spærret for en specifik sundhedsperson.


2.1. Overblik over brugerhistorier

brugerhistorie overblik


3. Brugerhistorier: Samtykke og Frabedelse Administration

3.1. Administration Brugertyper

  • Borger
  • Borger og borger på vegne af borger - fuldmagt (for nuværende deaktiveret)
  • Medarbejder på sundhedsområde med National rolle: SpaerAdminR8

3.2. Borger

En borger kan agere på vegne af en borger med næsten samme betingelser som borgeren selv, så længe vedkommende har en fuldmagt. Nedenfor er der for hvert borger historie noteret, hvis en borger agerer med fuldmagt under andre forudsætninger.

3.2.1. - Borger: Oprette frabedelse

Som Borger

ønsker jeg at kunne oprette en frabedelse 

så jeg kan sikre at mit sundhedsdata ikke deles

  1. med en specifik sundhedsfaglig,
  2. fra et bestemt behandlingssted, 
  3. fra en bestemt periode

Acceptkriterier

  • Frabedelsen vises på brugergrænsefladen
  • Uanset frabedelses type kan borger selv se eget data 
  • Der logges ikke til minlog
  • Der oprettes en adviseringer (se Nas besked)
  • Oprettelse af frabedelse fremgår i auditlog med tidsstempel 

  • Specielt for borger på vegne af borger med fuldmagt:
    • Der logges til minlog

3.2.2. - Borger: Slette frabedelse

Som Borger

ønsker jeg at kunne slette en frabedelse 

så mit sundhedsdata igen er synligt

Acceptkriterier

  • Data er synligt for alle sundhedsfaglige
  • Der logges ikke til minlog
  • Der oprettes en adviseringer (se Nas besked)
  • Sletning af frabedelse fremgår i auditlog med tidsstempel

  • Specielt for borger på vegne af borger med fuldmagt:
    • Der logges til minlog

3.2.3. - Borger: Se frabedelse(r)

Som Borger

ønsker jeg at kunne se min(e) frabedelse(r) 

så jeg har overblik over, hvad jeg har frabedt mig

Acceptkriterier

  • Frabedelser vises på brugergrænsefladen
  • Der logges ikke til minlog
  • Der oprettes ikke en advisering
  • Hentning af frabedelse fremgår i auditlog med tidsstempel

  • Specielt for borger på vegne af borger med fuldmagt:
    • Der logges til minlog

3.2.4. Borger: Ret frabedelse(r) 

Som Borger

ønsker jeg at kunne rette en mine frabedelser

så jeg kan ændre i mine frabedelser 

Acceptkriterier

  • Rettelsen fremgår på brugergrænseflade 
  • Logges til minlog med teksten "Borger har opdateret frabedelser"
  • Rettelse af frabedelse fremgår i auditlog med tidsstempel

  • Specielt for borger på vegne af borger med fuldmagt:
    • Der logges til minlog

3.3. Medarbejder - med national rolle

3.3.1. - Bruger: Oprette en frabedelse

Som Medarbejder på sundhedsområde med National rolle: SpaerAdminR8

ønsker jeg at kunne oprette en frabedelse på vegne af en borger

så udfordret af det digitale borgere kan få hjælp til at oprette en frabedelse 

Acceptkriterier

  • Der oprettes en frabedelse af Administrativ sundhedsfaglig på vegne af borgeren
  • Frabedelsen vises på brugergrænsefladen for borgen
  • Frabedelsen vises på brugergrænsefladen for Admin i NADM
  • Borger kan selv se eget data
  • Frabedelsen gælder alt borgerens sundhedsdata indenfor den angivne periode 
  • Der logges til minlog med teksten "Sundhedsperson har tilføjet spærringer for en borger"
  • Der oprettes en adviseringer (se Nas besked)
  • Oprettelse af frabedelse fremgår i auditlog med tidsstempel 

3.3.2. - Bruger: Slette en frabedelse

Som Medarbejder på sundhedsområde med National rolle: SpaerAdminR8

 ønsker jeg at kunne slette en frabedelse på vegne af en borger

så udfordret af det digitale borgere kan få hjælp til at slette en frabedelse 

Acceptkriterier

  • Frabedelsen fremgår ikke længere på brugergrænseflade for borger
  • Frabedelsen fremgår ikke længere på brugergrænseflade for Admin NADM
  • Borgerens sundhedsdata er nu igen mulig at se for alle sundhedsfaglige
  • Der logges til minlog med teksten "Sundhedsperson har ophævet spærringer for en borger"
  • Der oprettes en adviseringer (se Nas besked)
  • Sletning af frabedelse fremgår i auditlog med tidsstempel 

3.3.3. Bruger: Se borgers frabedelse(r) 

Som Medarbejder på sundhedsområde med National rolle: SpaerAdminR8

ønsker jeg at kunne se borgers frabedelser

så udfordret af det digitale borgere kan få hjælp til at se deres frabedelser 

Acceptkriterier

  • Frabedelsen fremgår på brugergrænseflade for Admin NADM
  • Logges til minlog med teksten "Sundhedsperson har indhentet oplysninger om spærringer for en borger"
  • Hentning af frabedelse fremgår i auditlog med tidsstempel 

3.3.4. Bruger: Ret borgers frabedelse(r) 

Som Medarbejder på sundhedsområde med National rolle: SpaerAdminR8

ønsker jeg at kunne rette en borgers frabedelser

så udfordret af det digitale borgere kan få hjælp til at rette deres frabedelser 

Acceptkriterier

  • Rettelsen fremgår på brugergrænseflade for Admin NADM
  • Logges til minlog med teksten "Sundhedsperson har opdateret frabedelser for en borger"
  • Rettelse af frabedelse fremgår i auditlog med tidsstempel



4. Brugerhistorier: Samtykke og Frabedelse Verifikation

4.1. Verifikation Brugertyper

  • Systembruger

4.2.  Bruger Verifikation

4.2.1. Verifikation - systembruger - sundhedsfaglig med autorisation

Som Systembruger 

ønsker jeg at verificere om en sundhedsfaglig med autorisation har adgang til data

så jeg kan sikre at der kun udleveres data som ikke er spærret for den sundhedsfaglige med autorisation

Acceptkriterier

  1. Findes der en frabedelse på en specifik sundhedsfaglig, udleveres der ikke dokumenter til denne sundhedsfaglige
  2. Findes der en frabedelse fra en bestemt periode, udleveres der ikke dokumenter inden for denne periode

4.2.2. Verifikation - systembruger - uden autorisation med national rolle 

Som Systembruger 

ønsker jeg at verificere om en sundhedsfaglig uden autorisation med national rolle har adgang til data

så jeg kan sikre at der kun udleveres data som ikke er spærret for den sundhedsfaglige uden autorisation med national rolle 

Acceptkriterier

  1. Findes der en frabedelse på en specifik sundhedsfaglig, udleveres der ikke dokumenter til denne sundhedsfaglige
  2. Findes der en frabedelse fra en bestemt periode, udleveres der ikke dokumenter inden for denne periode 

4.3.  Data Verifikation

4.3.1. Data baggrund for scenarierne

Følgende tegning viser et udsnit af SOR hierarkiet. Hver kasse i diagrammet skal repræsentere en SOR enhed hvor data på borgeren er hjemmehørende.

SOR enhed B er spærret af borgeren, den er markeret med rød på tegningen.

Bemærk i følge anvenderquiden: spærringen på B medfører at A også ses som spærret da A er "forældre" organisation til B.  

SOR hieraki

Som et konkret eksempel for ovenstående hierarki er Akutafdeling på Aarhus Universitetshospital.

SOR id'er:

A: 441531000016008     -   Akutafdeling

B: 441541000016001     -   Akutafdeling Akutafsnit

C: 943171000016001     -  MEM afsnit Akutafdeling

D: 885611000016001     -  AKUT Voksenafsnit Akutafdeling

E: 1024291000016004   -  AKUT COVID Klinik Akutafdeling

F: 569361000016008    -  Ydernummer 403202

Enheden F er taget med for at kunne teste mapningen af ydrenumre til sorid i Samtykkeservice verification.

Hierarkiet falder lidt sammen når det ses med SHAK id'er

A: 662037 - Akutafdeling

B: 6620371 - Akutafdeling Akutafsnit

C: 6620371 - MEM afsnit Akutafdeling

D: 6620371 - AKUT Voksenafsnit Akutafdeling

E: 6620376 - AKUT COVID Klinik Akutafdeling


I det følgende gennemgås brugerhistorierne enkeltvis. Hver brugerhistorie beskrives med de acceptkriterier der hører til, og som skal være opfyldt for en succesfuld gennemførelse af brugerhistorien.

Hvor det er relevant gives konkrete eksempler på brugerhistorien i form af scenariebeskrivelse.

I det følgende anvendes ikke værdispring. Brugerhistorierne beskrives ud fra den Sundhedsfaglig bruger der aktiverer systemet og derfor starter historien. Men accepten af historien går på borgeren da Samtykkeservicens Verifikation skal spærre data hvis borgeren ønsker dette.

På en spærret SOR enhed kan der sættes et flag SOR-suborganisations. Når det er sat gælder spærringen også for underliggende SOR enheder.


4.3.2. Verifikation - system bruger - Filtrer liste med dataelementer

Som et Sundhedsfagligt system

ønsker jeg at få filtreret listen af  dataelementer

så jeg kan vide at eventuelle spærrede dataelementer er sorteret fra

For en succesfuld gennemførelse af brugerhistorien skal følgende acceptkriterier være opfyldt:

  1. Listen af dataelementer uden spærringer på returneres til Sundhedsfagligt system

4.3.3. Scenarie: Filtrer dataelementer, spærring med markering

Givet borger har spærring på SOR enhed B

og SOR-suborganisations markering er sat på spærringen

Når Filtrering af dataelementer er kørt

så indeholder listen dataelementer fra SOR enhed E

4.3.4. Scenarie: Filtrer dataelementer, spærring uden markering

Givet borger har spærring på SOR enhed B

og SOR-suborganisations markering ikke er sat på spærringen

Når Filtrering af dataelementer er kørt

så indeholder listen ingen dataelementer fra SOR enhed  C, D og E

4.3.5. Scenarie: Filtrer dataelementer, spærring med markering mapning SHAK id

Givet borger har spærring på SOR enhed B

og SOR-suborganisations markering er sat på spærringen

og dataelementer angives med SHAK id'er

Når Filtrering af dataelementer er kørt

så indeholder listen dataelementer fra SOR enhed E

4.3.6. Scenarie: Filtrer dataelementer, spærring uden markering mapning SHAK id

Givet borger har spærring på SOR enhed B

og SOR-suborganisations markering ikke er sat på spærringen

og dataelementer angives med SHAK id'er

Når Filtrering af dataelementer er kørt

så indeholder listen ingen dataelementer fra SOR enhed  C, D og E

4.3.7. Scenarie: Filtrer dataelementer, spærring med markering mapning Ydernummer

Givet borger har spærring på SOR enhed B

og SOR-suborganisations markering er sat på spærringen

og dataelementer angives med ydernummer

Når Filtrering af dataelementer er kørt

så indeholder listen dataelementer fra SOR enhed F








  • No labels