Introduktion

Formål

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

...

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

Læsevejledning

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

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

Brugertyper i DDS

I DDS arbejdes der med følgende brugertyper:

• Borger (B): En borger kan forespørge der forespørger på egne data
• Borger på vegne af: En borger der forespørger eller data på en anden borger, som denne har en relation til (værge/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: Ikke autoriseret person (IA): Kendetegnet ved ikke at være i besiddelse af et autorisationsiden autorisation. I stedet kan de have angivet en national rolle der kan være en af følgende: ingen rolle, national rolle type 1(lægesekretær?) eller rolle type 2 (sundhedsassistent?)Sundhedsfaglig person (SF): Kendetegnet ved at være i besiddelse af et autorisationsid.'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

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:

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.

 Borger forspørgsler

...

Brugerhistorie: Forespørgsel på eget aftaledokument (=> dokument)

Brugerhistorie: Forespørgsel på anden borgers aftaledokument (=> fejl)

Brugerhistorie: Forespørgsel på anden borgers aftaledokument med fuldmagt (=> dokument)

Brugerhistorie: Forespørgsel på anden borgers aftaledokument som værge (=> dokument)

Ikke-autoriserede bruger uden nationale roller

Brugerhistorie: Forespørgsel på borgers aftaledokument med negativ spærring (=> fejl)

Brugerhistorie: Forespørgsel på borgers labsvar dokument med negativ spærring (=> fejl)

Ikke-autoriserede bruger med nationale roller

Brugerhistorie: Forespørgsel på borgers aftaledokument med negativ spærring  (=> fejl)

Brugerhistorie: Forespørgsel på borgers labsvar med negativ spærring (=> fejl)

Brugerhistorie: Forespørgsel på borgers aftaledokument (=> dokument)

Brugerhistorie: Forespørgsel på borgers aftaledokument med forkert kontekst (=> fejl)

Brugerhistorie: Forespørgsel på borgers aftaledokumenter, hvor en er spærret (flere dokumenter + 1 fejl for spærret dokument)

Brugerhistorie: Forespørgsel på borgers labsvar (=> dokument)

Brugerhistorie: Forespørgsel på borgers labsvar, hvor en er spærret (=> dokument + ingen fejl?? - passer det?)

Sundhedsfaglig 

Brugerhistorie: Forespørgsel på en borgers aftaledokument

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

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

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

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

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

Sundhedsfaglig bruger

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

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

...