1. Introduktion

1.1. Formål

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

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 DDS.

For en teknisk gennemgang af de i dette dokument skitserede brugerhistorier henvises til DDS - Guide til anvendere

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

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

DDS Servicen har en Registry-snitflade (Søgning efter dokumenter) og en Repository-snitflade (Hentning af dokumenter). Hver brugerhistorie dækker et samlet flow bestående af både et kald til Registry og bagefter et kald til Repository, da det er sådan DDS servicen anvendes i praksis.

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 DDS kan anvendes til at opfylde forretningsmæssige behov.

Læseren forventes at være bekendt med dokumentdeling som koncept - herunder IHE XDS.

2. Brugertyper i DDS

I DDS arbejdes der med følgende brugertyper:

• Borger: En borger der forespørger på egne data
• Borger på vegne af: En borger der forespørger data på en anden borger, som denne har en relation til (forældremyndighedshaver/fuldmagtshaver). (Værge relation er blevet udfaset sommer 2024)
• Sundhedsfaglig: Kendetegnet ved at være i besiddelse af en autorisation. 
• Sundhedsfaglig på vegne af: Kendetegnet ved at  være en person på vegne af en anden person, som er i besiddelse af en autorisation.
• Ikke autoriseret bruger: Kendetegnet ved ikke at være i besiddelse af en autorisation. I stedet kan de have angivet en national rolle der kan være en af følgende: ingen rolle, national rolle 'lægesekretær' eller national rolle 'sundhedsassistent'

2.1. Forretningsregler

Gerne med link til lovgivning eller relevant rfc (Se forældre på Diagnoser)

3. Overblik over brugerhistorier

I den følgende tegning vises et overblik over de enkelte brugerhistorier, og hvorledes disse relaterer sig til hinanden og til de ovenfor beskrevne brugertyper:

4. Brugerhistorier

I det følgende gennemgåes 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.

4.1.  Borger forspørgsler

4.1.1. Forespørgsel på egne dokumenter

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

1. Brugeren autentificerer sig med en gyldig sikkerheds billet
2. Får en liste tilbage fra DDS Registry med dokumentreferencer på dokumenter, der tilhører borgeren og matcher søgekriterierne anvendt
3. Får de dokumenter tilbage fra DDS Repository der matcher dokumentreferencerne fra DDS Repository
4. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

4.1.2. Forespørgsel på anden borgers dokumenter

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

1. Brugeren autentificerer sig med en gyldig sikkerheds billet
2. Får følgende fejlbesked tilbage ved kald til DDS Registry: "Der opstod en fejl med følgende beskrivelse (Der kunne ikke findes en relation mellem borgerne via PersonInformation)"
3. Der foretages ikke kald til DDS Repository
4. Der oprettes ikke loglinjer i MinLog

4.1.3. Forespørgsel på anden borgers dokumenter, hvor der er en relation

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

1. Brugeren autentificerer sig med en gyldig sikkerheds billet
2. Brugeren anvender gyldig typecode og formatcode jf vedkommens fuldmagtadgang *
3. Får en liste tilbage fra DDS Registry med dokumentreferencer på dokumenter, der tilhører borgeren der ageres på vegne af og matcher søgekriterierne anvendt
4. Får de dokumenter tilbage fra DDS Repository der matcher dokumentreferencerne fra DDS Registry
5. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

*) Se også anvender guide for disse regler

4.2. Ikke-autoriseret bruger

4.2.1. Forespørgsel uden nationale roller

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

1. Brugeren autentificerer sig med en gyldig sikkerhedsbillet
2. Får følgende fejlbesked tilbage ved kald til DDS Registry: "urn:dk:nsi:Unauthorized Role"
3. Der foretages ikke kald til DDS Repository
4. Kaldet til DDS Registry resulterer i en loglinje i MinLog

4.2.2. Forespørgsel med national rolle

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

1. Brugeren autentificerer sig med en gyldigt sikkerhedsbillet
2. Får en liste tilbage med dokumentreferencer på dokumenter der tilhører borgeren og matcher søgekriterier og frabedelser fra DDS Registry
3. Får de dokumenter tilbage der tilhører borgeren fra DDS Repository
4. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

4.3. Sundhedsfaglig bruger

4.3.1. Forespørgsel uden værdispring

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

1. Brugeren autentificerer sig med en gyldigt sikkerhedsbillet
2. Får en liste tilbage fra DDS Registry med dokumentreferencer på dokumenter, der tilhører borgeren og matcher anvendte søgekriterier og eventuelle frabedelser.
3. Får de dokumenter tilbage fra DDS Repository der matcher dokumentreferencerne fra DDS Registry
4. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

4.3.2. Forespørgsel med værdispring

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

1. Brugeren autentificerer sig med en gyldigt sikkerhedsbillet
2. Værdispring er aktiveret
3. Får en liste tilbage fra DDS Registry med dokumentreferencer på dokumenter, der tilhører borgeren og matcher anvendte søgekriterier uanset frabedelser.
4. Får de dokumenter tilbage fra DDS Repository der matcher dokumentreferencerne fra DDS Registry
5. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

4.4. Sundhedsfaglig bruger på vegne af

4.4.1. Forespørgsel uden værdispring

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

1. Brugeren autentificerer sig med en gyldigt sikkerhedsbillet
2. Får en liste tilbage fra DDS Registry med dokumentreferencer på dokumenter, der tilhører borgeren og matcher anvendte søgekriterier og eventuelle frabedelser.
3. Får de dokumenter tilbage fra DDS Repository der matcher dokumentreferencerne fra DDS Registry
4. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

4.4.2. Forespørgsel med værdispring

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

1. Brugeren autentificerer sig med en gyldigt sikkerhedsbillet
2. Værdispring er aktiveret
3. Får en liste tilbage fra DDS Registry med dokumentreferencer på dokumenter, der tilhører borgeren og matcher anvendte søgekriterier uanset frabedelser.
4. Får de dokumenter tilbage fra DDS Repository der matcher dokumentreferencerne fra DDS Registry
5. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

5. Registreringer i MinLog i forbindelse med fremsøgning og hent af dokumenter

Det følgende dokumenterer, hvad der skrive som tekst i minlog i forbindelse med fremsøgning og hent af dokumenter. 

5.1. Registry - ITI-18 - fremsøgning af dokumenter

Et ITI-18 kald/forespørgsel indeholder søgeparametre, og disse anvendes til at beslutte, hvilken minlog tekst der skal logges.

I nedenstående "minlog tekst tabel for registry" skal kolonnerne tolkes som følgende:

• Dokument:
  • En læsevenlig version af dokumenttypen
• Typecode, classcode og formatcode:
  • Indholdet, som kommer ind i forespørgslen (søgeparametre) for det respektive felt, skal matche det, som er angivet i tabellen. 
  • Der skal være præcis match med værdi. Står der blank, må feltet heller ikke være udfyldt i forespørgslen.
• Minlog tekst:
  • Den tekst, som vil blive anvendt til logning i minlog. 
  • I disse tekster kan værdien "<brugertype>" indgå. Her skal man erstatte <brugertype> med den tekst, man finder i "brugertype-brugertype tekst mapningstabellen nedenfor ud fra brugertypen på den anvender, som har lavet forespørgslen.
  • Default minlog teksterne, dem som anvendes, når der ikke er match på typecode, classcode og formatcode, kan af ordlyd varierer efter brugertype. Disse er derfor specificeret per brugertype.

Brugertype-brugertype tekst mapningstabel:

Minlog tekst tabel for registry:

5.2. Repository - ITI-43 - hent af dokumenter

Et ITI-43 kald/forespørgsel indeholder IKKE søgeparametre, hvorfor minlog tekst alene bestemmes af brugertypen

Minlog tekst tabel for repository:

5.3. Opdatering af dokumentationen

Hvis der kommer en ny type dokument til, skal der typisk, som opsætningen anvendes pt, laves 2 nye indgange i database tabellen "minlog_text":

• En hvor typecode_codename og typecode_schemename indgår. 
• En hvor typecode_codename og typecode_schemename samt formatcode_codename og formatcode_schemename indgår

For disse angiv relevant tekst i feltet "text", det vil ofte være den samme tekst, der skal stå her, kig på de øvrige indgange for inspiration.

Ovenstående dokumentation for registry og repository skal holdes opdateret med kørende drift opsætning.

I følgende tabel kan ses, hvordan en ændring i en opsætning ("Der rettes i...) kræver rettelse i relateret dokumentation ovenfor (Følgende af ovenstående tabeller skal rettes...):

Skulle der komme en ny brugertype til (kræver tilsvarende ændringer i sourcekoden) skal der rettes i alle tabellerne.

Hvis en tekst i "text" feltet i databasetabellen "minlog_text" indeholder "%s" erstattes "%s" med "<brugertype>". Så teksten fra databasen ""Opslag på aftaler fra %s", i ovenstående tabel f.eks. bliver til "Opslag på aftaler fra <brugertype>"