...

• 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'

Anchor
DDS-forretningsregel-brugertyper DDS-forretningsregel-brugertyper

Forretningsregler brugertypers adgange til dokumenttyper

Denne tabel viser den faktiske konfiguration i forhold til DDS regel DDK10, se DDS - Design- og Arkitekturbeskrivelse

...

Overblik over brugerhistorier

...

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

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 en liste tilbage med de korrekte dokumentreferencer fra DDS RegistryFår de korrekte dokumenter tilbage fra DDS Repositoryfø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

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

...

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
med de korrekte dokumentreferencer
4. fra DDS Registry med dokumentreferencer på dokumenter, der tilhører borgeren der ageres på vegne af og matcher søgekriterierne anvendt
5. Får de
korrekte
6. dokumenter tilbage fra DDS Repository der matcher dokumentreferencerne fra DDS Registry
7. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

*) Se også anvender guide for disse reglerDer er beskrevet en række testcases der dækker ovenstående brugerhistorier vedr. Borger forespørgsler her: Testcases Borger

Ikke-autoriseret bruger

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
en liste tilbage med de korrekte dokumentreferencer fra DDS Registry
3. følgende fejlbesked tilbage ved kald til DDS Registry: "urn:dk:nsi:Unauthorized Role"
4. Der foretages ikke kald til DDS Repository
5. Kaldet til DDS Registry resulterer i en loglinje i MinLog
Får de korrekte dokumenter tilbage fra DDS Repository

Forespørgsel med national rolle

...

1. Brugeren autentificerer sig med en gyldigt sikkerhedsbillet
2. Får en liste tilbage med de korrekte dokumentreferencer dokumentreferencer på dokumenter der tilhører borgeren og matcher søgekriterier og frabedelser fra DDS Registry
3. Får de korrekte dokumenter tilbage der tilhører borgeren fra DDS Repository

...

1. Kald til DDS Registry og DDS Repository resulterer hver i en loglinje i MinLog

Sundhedsfaglig bruger

Forespørgsel uden værdispring

...

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

Forespørgsel med værdispring

...

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

Der er beskrevet en række testcases der dækker ovenstående brugerhistorier vedr. forespørgsler fra en sundhedsfaglig bruger her: Testcases sundhedsfaglig bruger

Sundhedsfaglig bruger på vegne af

Denne beskrivlese bør laves samtidig med at der laves integrationstest af scenarierne.

1. resulterer hver i en loglinje i MinLog

Sundhedsfaglig bruger på vegne af

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

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

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. 

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.
  • Man skal være opmærksom på at den dokumentspecifikke tekst kun kommer såfremt man søger på en enkelt dokumenttype, angives flere dokumenttyper eller ingen dokumenttype, så vil der komme en generisk besked 

Brugertype-minlog tekst mapningstabel:

Minlog tekst tabel for registry - søgninger alias ITI18 kald:

Repository - ITI-43 - hent af dokumenter

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

Minlog tekst tabel for repository:

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>"

...