1. Introduktion
1.1. Formål
Formålet med dette dokument er at beskrive de brugerhistorier (user stories) der understøttes af MinSpærring.
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 MinSpærring.
For en teknisk gennemgang af de i dette dokument skitserede brugerhistorier henvises til MinSpærring - Guide til anvendere.
Den første del af dokumentet beskriver de forskellige brugertyper/aktører af MinSpærring.
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 MinSpærring 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 MinSpærring
I MinSpærring arbejdes der med følgende brugertyper:
Brugertype | Security-api | Hsuid |
---|---|---|
Borger (Citizen) | ActingUser er udfyldt: Sikkerhedsbillettens UserType skal være "Citizen" Audience fra sikkerhedsbilletten skal kunne verificeres | ActingUser er ikke udfyldt: Der skal være en valid HsuidHeader der beskriver en "Citizen" Tilhørende organisation skal være whitelistet. |
Borger på vegne af anden borger
| Findes ikke pt. i Minspærring | |
Sundhedsfaglig (HealthcareProfessional) | ActingUser er udfyldt: Sikkerhedsbillettens UserType skal være "HealthcareProfessional" | ActingUser er ikke udfyldt: Der skal være en valid HsuidHeader der beskriver en "HealthcareProfessional" Tilhørende organisation skal være whitelistet. |
Sundhedsfaglig på vegne af anden sundhedsfaglig | Findes ikke pt. i Minspærring | |
Administrativ | ActingUser er udfyldt: Sikkerhedsbillettens UserType skal være "HealthcareProfessional" RequiredNationalRole skal være udfyldt (og den må ikke være slået fra vha. TURN_NATIONAL_ROLE_OFF) | |
Systembruger (idkort niveau 3) | Findes ikke pt. i Minspærring |
Kolonnen "Hsuid" er på vej til at blive udfaset og bliver ikke vedligeholdt fremadrettet.
3. Brugerhistorier til MinSpærring Verifikation
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.
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 Minspærring verification.
Hierarkiet falder lidt sammen når det ses med SKAK 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 MinSpærring 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.
3.1. Brugerhistorie: Filtrer liste med dataelementer
Som et Sunhedsfagligtsystem ø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:
- Listen af dataelementer uden spærringer på returnes til Sundhedsfagligtsystem
4. Scenarier til MinSpærring Verifikation
4.1. 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å indholder listen dataelementer fra SOR enhed E |
4.2. 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å indholder listen ingen dataelementer fra SOR enhed C, D og E |
4.3. 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å indholder listen dataelementer fra SOR enhed E |
4.4. 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.5. 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å indholder listen dataelementer fra SOR enhed F |