Indledning

Dette dokument er en vejledning til brug for anvendere af Dokumentdelingsservice (DDS). Formålet med dokumentet er at give anvendere et overblik over løsningen samt en oversigt over, hvilke User Stories, der er understøttet af DDS og hvordan disse er implementeret (flows).

Da DDS består af to logiske service, DDS Registry og DDS Repository samt en række backends, der dækker forskellige formål, så starter vi dette dokument med at give et overblik over opbygningen af DDS.

Dernæst dokumenteres de understøttede user stories.

Ordliste

BetegnelseBeskrivelseYderligere dokumentation
DDSDokumentdelingsservice
NSPNational Serviceplatform
BRSBehandlingsrealtionservice
CDAClinical Document Architecture (CDA) er en XML baseret  HL7 standard der specificerer encoding, struktur og semantik for kliniske dokumenter. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
XDSCross Enterprise Document Sharing (XDS) er en række IHE standarder, der specificerer, hvordan dokumenter (f.eks. CDA) deles mellem sundhedsorganisationer.https://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing
FSKFælles Stamkort

Overblik over løsningen

Dokumentdelingsservice (DDS) består af to logiske services DDS Registry og DDS Repository, der tilsammen understøtter funktionerne

af dokumenter på NSP. Et dokument er i denne sammenhæng et CDA dokument.

Indexeringsservicen er en teknisk service, der stilles til rådighed for eksterne XDS repositories og er derfor ikke interessant for anvenderne af DDS. Denne service behandles ikke yderligere i dette dokument.

De to komponenter DDS Registry og DDS Repository fungerer som proxyindgang til flere bagvedliggende datakilder (backends). Dette er illustreret i tegningen nedenfor.

De konkrete snitfladebeskrivelser for indexering, fremsøgning og hentning af dokumenter findes i dokumenterne herunder: Documentation Dokumentdelingsservice (snitflader og fejlmeddelelser)

Overordnede ansvarsområder i DDS

Udover at fungere som proxy for et antal bagvedliggende kilder, så har DDS også følgende ansvarsområder:

  1. Validering af medsendte sikkerhedsakkredidativer
  2. Tjek af en borgers spærringer i forhold til adgang til data (via MinSpærring)
  3. Bestilling af opfølgning på behandlingsrelation mellem borger og kaldende sundhedsprofessionelle (via BRS).
  4. Auditlogning
  5. Logning af værdispring
  6. Logning til MinLog

De overordnede flows er beskrevet i nedenstående afsnit.

Brugertyper i DDS

Der findes følgende brugertyper i DDS:

Dokumentdelingsservicens funktioner

DDS funktioner og overordnede ansvarsområder blev gennemgået i det foregående afsnit. I dette afsnit dokumenteres følgende funktioner:

Funktionerne gennemgåes på følgende måde:

Funktion: Søgning efter dokumenter via DDS Registry

Overordnet set faciliterer DDS Registry søgninger i de bagvedliggende registries (se illustration ovenfor).

Formålet med en søgning er at få en liste tilbage med dokument-id'er, der matcher forespørgslen. En forespørgsel skal som minimum indeholde et CPR nummer, men det kan også være relevant at begrænse søgningen med hensyn til f.eks.:

Da der er stor forskel på DDS flow for de forskellige brugertyper vil de konkrete flows beskrives enkeltvist i de følgende afsnit.

Borger (B): Flow for søgning efter dokumenter via DDS Registry

Det overordnede flow ved en søgning i DDS Registry som en borger ser således ud:

Flowet for borgere er det simpleste af de tre tilfælde. DDS Registry validerer medsendte akkreditiver, hvorefter søgningen sendes videre til DDS Backends. I de tilfælde, hvor en borger søger på en anden borger (ved relation i form af værge, forældremyndighedshaver eller fuldmagtshaver) vil dette blive logget til MinLog.

Inden svaret returneres logges svaret i auditloggen.

Ikke-autoriseret bruger (IA): Flow for søgning efter dokumenter via DDS Registry

Det overordnede flow ved en søgning i DDS Registry som en ikke-autoriseret bruger ser således ud:

Diagrammet viser, hvorledes DDS Registry starter med at validere de medsendte akkreditiver (se evt. DDS Registry Querying Interface Description).

DDS Registry igangsætter dernæst en række asynkrone kald:

Hvis svaret fra MinSpærring angiver, at der er en negativ spærring en eller flere sundhedspersoner, returnerer DDS Registry et svar til kalderen uden dokument-id'er men med en angivelse af, at der er sket en filtrering pga spærring (forsigtighedprincippet).

Hvis svaret fra MinSpærring ikke gav anledning til en direkte afvisning af søgningen kan det komme på tale, at DDS Registry foretager en filtrering af svarene fra backends udfra følgende kriterier:

Til sidst foretager DDS Registry en auditlogning af resultatet (se evt. afsnittet "Auditloging" nedenfor), inden svaret sendes tilbage til brugeren

Sundhedsfaglig bruger (SF): Flow for søgning efter dokumenter via DDS Registry

Diagrammet viser, hvorledes DDS Registry starter med at validere de medsendte akkreditiver.

Hvis de medsendte akkreditiver er gyldige, kigger DDS på, om den kaldende bruger anvender værdispring.

Hvis søgningen foretages med værdispring (dvs. tilsidesættelse af spærringer i forbindelse med en nødssituation) logges dette i en særlig værdispringslog.

DDS Registry igangsætter dernæst en række asynkrone kald:

Hvis brugeren ikke anvender værdispring, så vil DDS Registry afvente, at kaldet til MinSpærring er færdigt.

Hvis svaret fra MinSpærring angiver, at der er en negativ spærring mod den kaldende ansvarlige sundhedsperson, returnerer DDS Registry et svar til kalderen uden dokument-id'er men med en angivelse af, at der er sket en filtrering pga spærring.

Hvis svaret fra MinSpærring ikke gav anledning til en direkte afvisning af søgningen kan det komme på tale, at DDS Registry foretager en filtrering af svarene fra backends udfra følgende kriterie:

Hvis brugeren anvender værdispring, vil de forgående skridt springes over.

DDS Registry vil afvente, at kaldet til BRS returnerer.

Til sidst foretager DDS Registry en auditlogning af resultatet (se evt. afsnittet "Auditloging" nedenfor), inden svaret sendes tilbage til brugeren.

User stories: Søgning efter dokumenter via DDS Registry

I det følgende afsnit beskrives de konkrete user stories i forhold til søgning efter dokumenter.

Borger søger alle dokumenter sig selv

Userstory: Borger søger alle dokumenter på sig selv
IDB_SOEG_ALLE_DOK
Beskrivelse

Som en borger

ønsker jeg at lave en uindskrænket søgning i DDS Registry

så jeg kan få en liste over mine registrerede dokumenter

Testcases for:  Borger søger alle dokumenter på borger
DOKS

Precondition:

  1. Borgeren har et eller flere dokumenter

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste retur med ider på alle dennes dokumenter
  2. Der kommer en linje i DDS auditlog

Borger søger alle dokumenter på anden borger

Userstory: Borger søger alle dokumenter på anden borger
IDB_SOEG_ALLE_DOK_ANDEN_B
Beskrivelse

Som en borger

ønsker jeg at lave en uindskrænket søgning i DDS Registry

så jeg kan få en liste over en anden borgers (som jeg har relation til) dokumenter

Testcases for:  Borger søger alle dokumenter på borger
DOKS

Precondition:

  1. Den borger, som brugeren vil tilgå data på har et eller flere dokumenter

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste retur med ider på alle dennes dokumenter
  2. Der kommer en linje i DDS auditlog
  3. Der kommer en linje i MinLog

Ikke-autoriseret bruger med national rolle søger alle dokumenter på borger

Userstory: Ikke-autoriseret bruger med national rolle søger alle dokumenter på borger
IDIA_NATIONAL_SOEG_ALLE_DOK
Beskrivelse

Som en ikke-autoriseret bruger med national rolle

ønsker jeg at lave en uindskrænket søgning i DDS Registry

så jeg kan få en liste over en given borgers registrerede dokumenter, som min rolle giver adgang til

Testcases for:  Ikke-autoriseret bruger med national rolle søger alle dokumenter på borger
NAT_ROLLE_INGEN_DOKTYPER

Precondition:

  1. Brugerens nationale rolle giver ikke adgang til nogen dokumenttyper
  2. En borger med et eller flere dokumenter
  3. Borgeren har ingen spærringer i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en tom liste af dokumentreferencer
  2. Brugeren får en meddelelse om, at rollen ikke giver adgang til dokumenterne (unauthorized_role)
  3. Der kommer ikke en linje i MinLog
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog
NAT_ROLLE_VISSE_DOKTYPER

Precondition:

  1. Brugerens nationale rolle giver adgang til visse dokumenttyper
  2. En borger med et eller flere dokumenter, der falder indenfor de dokumenttyper, som brugerens rolle giver adgang til
  3. Borgeren har også dokumenter, der falder udenfor de dokumenttyper, som brugerens rolle giver adgang til
  4. Borgeren har ingen spærringer i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste med dokumentider retur (se pkt 2 i precondition) retur
  2. Brugeren får en meddelelse om, at der er fortaget filtreringer i svaret (unauthorized_role)
  3. Der kommer en linje i MinLog som konsekvens af søgningen
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog
NAT_ROLLE_ALLE_DOKTYPER

Precondition:

  1. Brugerens nationale rolle giver adgang til alle dokumenttyper
  2. En borger med et eller flere dokumenter, der falder indenfor de dokumenttyper, som brugerens rolle giver adgang til
  3. Borgeren har ingen dokumenter, der falder udenfor de dokumenttyper, som brugerens rolle giver adgang til
  4. Borgeren har ingen spærringer i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste med dokumentider retur (se pkt 2 i precondition) retur
  2. Der kommer en linje i MinLog som konsekvens af søgningen
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog

NEG_SPAERRING_SF

(se "forsigtighedsprincippet" beskrevet i SDS-2503)

Precondition:

  1. Brugerens nationale rolle giver adgang til alle dokumenttyper
  2. Borgeren har et eller flere dokumenter
  3. Borgeren har registreret negativ spærring mod en sundhedsfaglig person i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en tom liste retur
  2. Brugeren får en meddelelse om, at der er fortaget filtreringer i svaret (consent_filter_applied)
  3. Der kommer en linje i MinLog
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog
DATA_SPAERRING

Precondition:

  1. Brugerens nationale rolle giver adgang til alle dokumenttyper
  2. Borgeren har et eller flere dokumenter
  3. Borgeren har dataspecifikke spærring i MinSpærring, der dækker et eller flere af dokumenterne i pkt 2

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste af dokumentid retur, hvor de referencer, der vedrører de dokumneter, der er dækket af dataspecifik spærring er filtreret fra
  2. Brugeren får en meddelelse om, at der er fortaget filtreringer i svaret (consent_filter_applied)
  3. Der kommer en linje i MinLog
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog


Sundhedsfaglig bruger søger alle dokumenter på borger

Userstory: Sundhedsfaglig bruger søger alle dokumenter på borger
IDSF_SOEG_ALLE_DOK
Beskrivelse

Som en sundhedsfaglig bruger

ønsker jeg at lave en uindskrænket søgning i DDS Registry

så jeg kan få en liste over en given borgers registrerede dokumenter

Testcases for:  Sundhedsfaglig bruger søger alle dokumenter på borger
INGEN_SPAERRINGER

Precondition:

  1. Borgeren har et eller flere dokumenter
  2. Borgeren har ingen spærringer i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste retur med ider på alle borgerens dokumenter
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
INGEN_DOKS

Precondition:

  1. Borgeren har ingen dokumenter registreret i DDS
  2. Borgeren har ingen spærringer i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får tom liste retur
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
NEG_SPAERRING_DENNE_SF

Precondition:

  1. Borgeren har et eller flere dokumenter
  2. Borgeren har negativ spærring mod den kaldende bruger i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en tom liste retur
  2. Brugeren får en meddelelse om, at der er fortaget filtreringer i svaret (consent_filter_applied)
  3. Der kommer en linje i MinLog
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog

NEG_SPAERRING_ANDEN_SF

(illustration af, at "forsigtighedsprincippet" beskrevet i SDS-2503 ikke gælder for sundhedsfaglige)

Precondition:

  1. Borgeren har et eller flere dokumenter
  2. Borgeren har negativ spærring mod en anden sundhedsfaglig end den kaldende bruger i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste retur med ider på alle borgerens dokumenter
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
NEG_SPAERRING_DENNE_SF_INGEN_DOKS

Precondition:

  1. Borgeren ingen dokumenter registreret i DDS
  2. Borgeren har negativ spærring mod den kaldende bruger i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en tom liste retur
  2. Brugeren får en meddelelse om, at der er fortaget filtreringer i svaret (consent_filter_applied)
  3. Der kommer en linje i MinLog
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog
DATA_SPAERRING

Precondition:

  1. Borgeren har et eller flere dokumenter
  2. Borgeren har dataspecifikke spærring i MinSpærring, der dækker et eller flere af dokumenterne i pkt 1

Action: Brugeren foretager en uindskrænket søgning i DDS Registry

Postcondition:

  1. Brugeren får en liste af dokumentid retur, hvor de referencer, der vedrører de dokumneter, der er dækket af dataspecifik spærring er filtreret fra
  2. Brugeren får en meddelelse om, at der er fortaget filtreringer i svaret (consent_filter_applied)
  3. Der kommer en linje i MinLog
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog


Sundhedsfaglig bruger søger alle dokumenter på borger med angivelse af værdispring

Userstory: Sundhedsfaglig bruger søger alle dokumenter på borger med angivelse af værdispring
IDSF_SOEG_ALLE_DOK_VAERDISPRING
Beskrivelse

Som en sundhedsfaglig bruger

ønsker jeg at lave en uindskrænket søgning i DDS Registry med angivelse af værdispring

så jeg kan få en liste over en given borgers registrerede dokumenter uanset borgerens spærringer

Testcases for: Sundhedsfaglig bruger søger alle dokumenter på borger med angivelse af værdispring
NEG_SPAERRING_DENNE_SF_INGEN_DOKS

Precondition:

  1. Borgeren ingen dokumenter registreret i DDS
  2. Borgeren har negativ spærring mod den kaldende bruger i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry med angivelse af værdispring

Postcondition:

  1. Brugeren får en tom liste retur
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
  5. Der kommer en linje i DDS værdispringslog
NEG_SPAERRING_DENNE_SF_VAERDISPRING

Precondition:

  1. Borgeren har et eller flere dokumenter
  2. Borgeren har negativ spærring mod den kaldende bruger i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry med angivelse af værdispring

Postcondition:

  1. Brugeren får en liste retur med ider på alle borgerens dokumenter
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
  5. Der kommer en linje i DDS værdispringslog
DATA_SPAERRING_VAERDISPRING

Precondition:

  1. Borgeren har et eller flere dokumenter
  2. Borgeren har dataspecifikke spærring i MinSpærring, der dækker et eller flere af dokumenterne i pkt 1

Action: Brugeren foretager en uindskrænket søgning i DDS Registry med angivelse af værdispring

Postcondition:

  1. Brugeren får en liste retur med ider på alle borgerens dokumenter
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
  5. Der kommer en linje i DDS værdispringslog
DATA_SPAERRING_VAERDISPRING_INGEN_DOKS

Precondition:

  1. Borgeren ingen dokumenter registreret i DDS
  2. Borgeren har dataspecifikke spærring i MinSpærring

Action: Brugeren foretager en uindskrænket søgning i DDS Registry med angivelse af værdispring

Postcondition:

  1. Brugeren får en tom liste retur
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
  5. Der kommer en linje i DDS værdispringslog


Sundhedsfaglig bruger søger labsvardokumenter på borger

Userstory: Sundhedsfaglig bruger søger labsvardokumenter på borger
IDSF_SOEG_LABSVAR
Beskrivelse

Som en sundhedsfaglig bruger

ønsker jeg at søge efter labsvar i DDS Registry

så jeg kan få en liste over en given borgers labsvar

Testcases for:  Sundhedsfaglig bruger søger labsvardokumenter på borger
INGEN_SPAERRINGER

Precondition:

  1. Borgeren har ingen spærringer i MinSpærring

Action: Brugeren foretager en søgning på labsvar i DDS Registry

Postcondition:

  1. Brugeren får en liste retur med 1 dokumentreference
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
NEG_SPAERRING_DENNE_SF

Precondition:

  1. Borgeren har negativ spærring mod den kaldende bruger i MinSpærring

Action: Brugeren foretager en søgning efter labsvar i DDS Registry

Postcondition:

  1. Brugeren får en tom liste retur
  2. Brugeren får en meddelelse om, at der er fortaget filtreringer i svaret (consent_filter_applied)
  3. Der kommer en linje i MinLog
  4. Der bestilles en opfølgning i BRS
  5. Der kommer en linje i DDS auditlog
DATA_SPAERRING

Precondition:

  1. Borgeren har dataspecifikke spærring i MinSpærring, på en afdeling, der har registerede labsvar for den pågældende bruger

Action: Brugeren foretager en søgning efter labsvar i DDS Registry

Postcondition:

  1. Brugeren får en liste retur med 1 dokumentreference
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog

Sundhedsfaglig bruger søger labsvar på borger med angivelse af værdispring

Userstory: Sundhedsfaglig bruger søger labsvar på borger med angivelse af værdispring
IDSF_SOEG_LABSVAR_VAERDISPRING
Beskrivelse

Som en sundhedsfaglig bruger

ønsker jeg at lave en søgning efter labsvar i DDS Registry med angivelse af værdispring

så jeg kan få en liste over en given borgers registrerede labsardokumenter uanset borgerens spærringer

Testcases for: Sundhedsfaglig bruger søger labsvar på borger med angivelse af værdispring
NEG_SPAERRING_DENNE_SF_VAERDISPRING

Precondition:

  1. Borgeren har negativ spærring mod den kaldende bruger i MinSpærring

Action: Brugeren foretager en søgning efter labsvar i DDS Registry med angivelse af værdispring

Postcondition:

  1. Brugeren får en liste retur med 1 dokumentreference
  2. Der kommer en linje i MinLog
  3. Der bestilles en opfølgning i BRS
  4. Der kommer en linje i DDS auditlog
  5. Der kommer en linje i DDS værdispringslog


Funktion: Hentning af dokumenter via DDS Repository

Overordnet set faciliterer DDS Repository hentning af dokumenter i de bagvedliggende registries (se illustration ovenfor).

Formålet er at få en liste tilbage af dokumenter, der svarer til de dokument-id'er, som der blev bedt om i forespørgslsen.

En dokumenthentning sker altid efter en søgning, der tilvejebringer relevante dokument-id'er udfra een eller flere søgeparametre.

Nedenstående diagram viser flowdiagrammet illusterer flowet for sundhedsfaglige, som er det mest komplicerede.

Flowet for dokumenthentning ligner på mange måder flowet for søgninger. Den største forskel er i forhold til filtreringen i forhold til dataspecifikke spærringer. Ved søgninger kunne dokumenternes metadata (som returneret af DDS backends) anvendes i filtreringen, da man her kunne finde information om, hvilken afdeling dokument entry'et tilhørte. Denne information er ikke tilgængelig i forhold til hentning af dokumentet, da det eneste metadata, der er i spil her er dokumentets id. Filtreringen af dokumentindholdet sker således kun for dokumenter, der indeholder en PIH (Privacy Information Header). Dette gør sig i skrivende stund kun gældende for labsvar. Alle andre dokumenter vil således ikke kunne filtreres/udelades på baggrund af borgerens dataspecifikke spærringer. Blandt andet derfor er det nødvendigt altid at lave en søgning efter dokument-id'er først (hvorved de dataspecifikke spærringer kan bringes i spil). Anvendere må således ikke cache dokument-id'er eller "genbruge" søgeresultater på tværs af brugere og/eller sessioner.

Logning i MinLog

I de nedenstående tabeller kan det ses, hvorledes kald til DDS Registry (søgning) og DDS Repository (hentning) anvendes i logninger i MinLog.

Logninger i MinLog i forbindelse med søgninger mod DDS Registry

Ved søgning i DDS Registry vil der i tilfælde med sundhedsfaglige brugere og ikke-autoriserede brugere komme en linje i MinLog. Følgende tabel viser, hvor oplysningerne i kaldet til MinLog stammer fra:

Felt i MinLogs LogDataEntry Hvor stammer oplysningen fra i søgninger mod DDS Registry?
sessionIdFlow-id (som angivet i Medcom headeren i følge DGWS)
sourceSystemIdentifierKaldende system (som angivet i HSUID headeren nsi:SystemName)
eventDateTimeTidsstempel for kaldet (genereres af DDS Registry)
activity

Udfyldes med defaultværdi for DDS Registry (som angivet i konfigurationsparameteren minlog.query.default eller minlog.query.consentoverride, hvis værdispring anvendes).

Nuværende værdier:

minlog.query.default = "Opslag på dokumentdelingsservice"

minlog.query.consentoverride = "Opslag på dokumentdelingsservice, hvor samtykker tilsidesættes"

For borgeropslag står der

"Opslag/udtræk på dokumentdelingsservicen af forældremyndighedsindehaver / fuldmagtshaver / værge" alt efter, hvordan relationen er (som angivet i HSUID headeren nsi:CitizenUserRelation)

personCivilRegistrationBorgerens CPR nummer (som opslaget drejer sig om)
userIdentifierKaldende brugers CPR nummer (som angivet i HSUID headeren nsi:ActingUserCivilRegistrationNumber)
userIdentifierOnBehalfOfAnsvarlige brugers CPR nummer (som angivet i HSUID headeren nsi:ResponsibleUserCivilRegistrationNumber)
healthcareProfessionalOrganisationOrganisationen (som angivet i HSUID headeren nsi:OrgUsingID)
healthcareProfessionalOrganisationName

Udfyldes med defaultværdi for DDS Registry (som angivet i konfigurationsparameteren registration.log.organisation_name for DDS Registry

Nuværende værdi: "(organisationsnavn blev ikke udfyldt på registreringstidspunktet)"

Logninger i MinLog i forbindelse med hentning af dokument i DDS Repository

Ved hentning af dokumenter i DDS Repository vil der i tilfældene med sundhedsfaglige brugere og ikke-autoriserede brugere komme en linje i MinLog. Følgende tabel viser, hvor oplysningerne i kaldet til 

MinLog stammer fra:

Felt i MinLogs LogDataEntry Hvor stammer oplysningen fra i søgninger mod DDS Repository?
sessionIdFlow-id (som angivet i Medcom headeren i følge DGWS)
sourceSystemIdentifierKaldende system (som angivet i HSUID headeren nsi:SystemName)
eventDateTimeTidsstempel for kaldet (genereres af DDS Repository)
activity

Udfyldes med defaultværdi for DDS Repository (som angivet i konfigurationsparameteren minlog.query.default eller minlog.query.consentoverride, hvis værdispring anvendes).

Nuværende værdier:

minlog.query.default = "Dataudtræk på dokumentdelingsservice"

minlog.query.consentoverride = "Dataudtræk på dokumentdelingsservice, hvor samtykker tilsidesættes"

For borgeropslag står der

"Opslag/udtræk på dokumentdelingsservicen af forældremyndighedsindehaver / fuldmagtshaver / værge" alt efter, hvordan relationen er (som angivet i HSUID headeren nsi:CitizenUserRelation)

personCivilRegistrationBorgerens CPR nummer (som opslaget drejer sig om)
userIdentifierKaldende brugers CPR nummer (som angivet i HSUID headeren nsi:ActingUserCivilRegistrationNumber)
userIdentifierOnBehalfOfAnsvarlige brugers CPR nummer (som angivet i HSUID headeren nsi:ResponsibleUserCivilRegistrationNumber)
healthcareProfessionalOrganisationOrganisationen (som angivet i HSUID headeren nsi:OrgUsingID)
healthcareProfessionalOrganisationName

Udfyldes med defaultværdi for DDS Registry (som angivet i konfigurationsparameteren registration.log.organisation_name for DDS Registry

Nuværende værdi: "(organisationsnavn blev ikke udfyldt på registreringstidspunktet)"

Kald af BRS

Anvendelsen af Dokumentdelingsservicen har sideeffekter i forhold til bestilling af opfølgninger i BRS. I det følgende beskrives sideeffekterne ved anvendelsen af

Anvendelse af BRS i forbindelse med fremsøgning af dokumentreferencer i DDS Registry

Ved søgninger i DDS Registry vil der i søgninger foretaget med brugertyperne sundhedsfaglig og ikke-autoriseret blive bestilt en opfølgning i BRS.

Online svaret fra BRS anvendes ikke til at spærre for søgninger, da det ikke er sikkert, at evidensgrundlaget er på plads i BRS på opslagstidspunktet.

Følgende tabel viser, hvor oplysningerne i bestillingen af opfølging i BRS stammer fra:

Felt i TreatmentRelationRequestHvor stammer oplysningen fra i kald mod DDS?
PatientCprBorgerens CPR nummer (som opslaget drejer sig om)
HealthcareProfessionalCpr

Hvis opslaget stammer fra en bruger, der arbejder på vegne af en sundhedsprofessionelle bruger, så anvendes det CPR nummer, der arbejdes på vegne af (som angivet i HSUID headeren nsi:ResponsibleUserCivilRegistrationNumber).

Ellers anvendes CPR nummeret fra brugeren selv (som angivet i HSUID headeren nsi:ActingUserCivilRegistrationNumber).

AuthorisationIdentiferHvis kaldet indeholder en autorisationskode (som angivet i HSUID headeren nsi:ResponsibleUserAuthorizationCode), så medsendes denne
OrganisationIdentifierOrganisationen (som angivet i HSUID headeren nsi:OrgUsingID)
ExternalReferenceId

Udfyldes med defaultværdi for DDS (som angivet i konfigurationsparameteren treatment.relation.external.reference.id)

Nuværende værdi: tom

QueryableCvr

Udfyldes med defaultværdi for DDS (som angivet i konfigurationsparameteren treatment.relation.queryable.cvr)

Nuværende værdi: 30808460

AcceptableRelations

Der anvendes følgende værdier alt efter, hvilken organisationstype (som angivet i HSUID headeren nsi:OrgUsingID), der er tale om. Følgende mapning anvendes:

  • Organisationer af typen SHAK: DDS konfigurationsparameteren treatment.relation.acceptable.relations.hospital (nuværende værdi: A,B,C)
  • Organisationer af typen DEA: treatment.relation.acceptable.relations.doctor (nuværende værdi: All)
  • Organisationer af typen SOR: DDS konfigurationsparameteren treatment.relation.acceptable.relations.organization (nuværende værdi: A,B,C)
FollowupRelations

Der anvendes følgende værdier alt efter, hvilken organisationstype (som angivet i HSUID headeren nsi:OrgUsingID), der er tale om. Følgende mapning anvendes:

  • Organisationer af typen SHAK: DDS konfigurationsparameteren treatment.relation.followup.relations.hospital (nuværende værdi: All)
  • Organisationer af typen DEA: treatment.relation.followup.relations.doctor (nuværende værdi: All)
  • Organisationer af typen SOR: DDS konfigurationsparameteren treatment.relation.followup.relations.organization(nuværende værdi: All)
RelationLookupTimeInterval

Fradato sættes til tidspunktet for opslaget + et offset i antal dage (som angivet i konfigurationsparameteren for DDS treatment.relation.lookup.timeinterval.start.offset)

Nuværende værdi: -1

Tildato sættes til tidspunktet for opslaget + et offset i antal dage (angivet i konfigurationsparameteren for DDS treatment.relation.lookup.timeinterval.end.offset)

Nuværende værdi: 1

TimeLimit

Sættes til konfigurationsparameteren for DDS treatment.relation.lookup.timeinterval.timelimit.offset)

Nuværende værdi: 90

ServiceProvider

Name sættes til konfigurationsparameteren for DDS treatment.relation.serviceprovider.name

Nuværende værdi: TODO

Vendor sættes til konfigurationsparameteren for DDS treatment.relation.serviceprovider.vendor

Nuværende værdi: TODO

Version sættes til konfigurationparameteren for DDS treatment.relation.serviceprovider.version

Nuværende værdi: TODO

Anvendelse af BRS i forbindelse med hentning af dokumenter via DDS Repository

Ved hentning af dokumenter via DDS Repository vil der i tilfælde med brugertyperne sundhedsfaglig og ikke-autoriseret blive bestilt en opfølgning i BRS.

Online svaret fra BRS anvendes ikke til at spærre for hentninger, da det ikke er sikkert, at evidensgrundlaget er tilstede i BRS på kaldstidspunktet.

Selve mapningen af oplysninger fra DDS Repository til parametrene i BRS er den samme for hentning af dokument via DDS Repository, som den var for fremsøgning af dokumentreferencer i DDS Registry, hvorfor der henvises til tabellen i forgående afsnit. 

Auditlogning

DDS auditlogger, hvilke oplysning, der kommer retur i kaldene. I det følgende beskrives den overordnede logningsstrategi ved anvendelsen af:

DDS anvender NSP Audit API til auditlogning. Dette betyder, at auditlog linjer altid indeholder informationer vedrørende blandt andet:

Auditlogning ved fremsøgning af dokumentreferencer i DDS Registry

Det logges, hvilke dokumentreferencer, der returneres til kalderen.

Se evt. Driftsvejledning DDS Registry for detaljeret beskrivelse af auditlog entries.

Auditlogning ved hentning af dokument via DDS Repository

Ved hentning af dokumenter via DDS Repository auditlogges oplysninger om:



Snitfladebeskrivelse

Snitfladen for både DDS Registry og DDS Repository  skal indeholde SOAP-headere fra DGWS 1.0.1 og SOAP-body med indhold specificeret af IHE XDS.



Eksempler

Eksempler på request of response til de SOAP operationer der udstilles. De enkelte elementer er beskrevet under snitfladebeskrivelse.


Fremsøgning af metadata dokumentoplysninger (ITI-18)


Fremsøning af dokumentoplysninger gennem Aftaleoversigt (ITI-18)


Hentning af dokument (ITI-43)