Versions Compared

Old Version 1

changes.mady.by.user Unknown User (tim.hallgren@capgeminisogeti.dk)

Saved on

compared with

New Version 2

changes.mady.by.user Unknown User (tim.hallgren@capgeminisogeti.dk)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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.

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

  • Indexering (DDS Registry)
  • Fremsøgning (DDS Registry)
  • Hentning (DDS Repository)

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.

Gliffy Diagram
nameDDS Guide Til Anvendere overview
pagePin1

De konkrete snitfladebeskrivelser for indexering og fremsøgning findes i dokumenterne DDS Registry Registering Interface Description og DDS Registry Querying Interface Description.

Snitfladerne til afhentning af dokumenter er dokumenteret i MANGLER.

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:

  • Borger (B): En borger kan forespørge på egne data eller data på en anden borger, som denne har en relation til (værge/forældremyndighedshaver/fuldmagtshaver)
  • Ikke-autoriseret bruger (IA): Kendetegnet ved ikke at være i besiddelse af et autorisationsid, i besiddelse af 0 eller 1 nationale roller
  • Sundhedsfaglig (SF): Kendetegnet ved at være i besiddelse af et autorisationsid

Dokumentdelingsservicens funktioner

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

  • Søgning efter dokumenter via DDS Registry
  • Hentning af dokumenter via DDS Repository

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

  • Det overordnede flow beskrives (evt. flow for hver brugertype)
  • De understøttede user stories i relation til funktionen beskrives – herunder beskrivelse af relevant testcases

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.

  • Dokumenttype (f.eks. aftaler, labsvar, hjemmemålinger eller stamkort)
  • Periode (dokumenter kan være indekseret med oplysninger om en startdato og/eller slutdato)
  • Organsation (hvor dokumentet hører hjemme f.eks SOR kode)

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:

Gliffy Diagram
nameFlowdiagram-søgninger-DDS-B
pagePin1

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:

Gliffy Diagram
nameFlowdiagram-søgninger-DDS-Sundhedsfaglig
pagePin1

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:

  • Logning af søgning: Alle søgninger på data logges i MinLog (se evt afsnittet "Logning i MinLog" for at se, hvordan DDS Registry logger i MinLog)
  • Opslag på spærringer: Ved søgninger laver DDS Registry afvisning af disse/filtrering af svar i forhold til de spærringer, der er registreret for borgeren i MinSpærring. I dette kald tilvejebringer DDS Registry oplysninger om, hvorvidt, der foreligger negativ spærring mod en eller flere sundhedspersoner (forsigtighedsprincippet) eller om der skulle foreligge dataspecifikke spærringer.
  • Bestilling af opfølgning: Ved søgninger bestiller DDS Registry en opfølgning i BRS i forhold til eksistensen af behandlerrelation mellem borgeren og kalderen (se evt. "Kald af BRS" for at se, hvordan DDS Registry anvender dette).
  • Videresend søgninger til backends: DDS Registry vedligeholder i sig selv ikke dokumentregistreringer (dette foregår i de bagvedliggende backends). Søgninger delegeres videre til disse som 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:

  • For ikke-autoriserede brugere foretages der en filtrering på dokumenttyper udfra kalderens nationale rolle (SEB). 
  • Hvis opslag på spærringer viste, at der for den pågældende borger er dataspecifikke spærringer laver DDS Registry endnu et kald til MinSpærring. Denne gang er formålet at filtrere søgeresultatet i henhold til de dataspecifikke spærringer for borgeren.

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

Gliffy Diagram
nameFlowdiagram-søgninger-DDS-SF
pagePin1

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

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:

  • Opslag på spærringer (dette sker ikke, hvis brugeren anvender værdispring): Ved søgninger laver DDS Registry afvisning af disse/filtrering af svar i forhold til de spærringer, der er registreret for borgeren i MinSpærring. I dette kald tilvejebringer DDS Registry oplysninger om, hvorvidt, der foreligger negativ spærring mod kalderen eller om der skulle foreligge dataspecifikke spærringer.
  • Logning af søgning: Alle søgninger på data logges i MinLog (se evt afsnittet "Logning i MinLog" for at se, hvordan DDS Registry logger i MinLog)
  • Bestilling af opfølgning: Ved søgninger bestiller DDS Registry en opfølgning i BRS i forhold til eksistensen af behandlerrelation mellem borgeren og kalderen (se evt. "Kald af BRS" for at se, hvordan DDS Registry anvender dette).
  • Videresend søgninger til backends: DDS Registry vedligeholder i sig selv ikke dokumentregistreringer (dette foregår i de bagvedliggende backends). Søgninger delegeres videre til disse som 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 opslag på spærringer viste, at der for den pågældende borger er dataspecifikke spærringer laver DDS Registry endnu et kald til MinSpærring. Denne gang er formålet at filtrere søgeresultatet i henhold til de dataspecifikke spærringer for borgeren.

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.

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 der er fortaget filtreringer i svaret (consent_filter_applied)
  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 (consent_filter_applied)
  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 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_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 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
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. 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
  6. 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
  3. Brugeren laver søgningen med angivelse af værdispring

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

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.


Gliffy Diagram
nameFlowdiagram-hentning-DDS-SF
pagePin1

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

  • Service til fremsøgning af dokumentreferencer i DDS Registry
  • Service til hentning af dokument via DDS Repository

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: Der foretages ingen opfølgning, da BRS ikke understøtter den type opfølgninger for nuværende
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: Der foretages ingen opfølgning, da BRS ikke understøtter den type opfølgninger for nuværende
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:

  • Service til fremsøgning af dokumentreferencer i DDS Registry
  • Service til hentning af dokumenter via DDS Repository

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

  • SOAP Headers (f.eks. Message ID)
  • Egenskaber fra SOSI IDkort

Auditlogning ved fremsøgning af dokumentreferencer i DDS Registry

Det logges, hvilke dokumentreferencer, der returneres til kalderen.

  • Patientens CPR nummer
  • Brugerens CPR nummer (både kaldende bruger og evt. den bruger, som der bliver arbejdet på vegne af)
  • De dokument typeCodes (dokumenttyper), der blev søgt på
  • Dokumentreferencer i svaret, identificeret på følgende måde:
    • Homecommunity-Id
    • Repository-id
    • Dokumentid
    • TypeCode

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:

  • Patientens CPR nummer
  • Brugerens CPR nummer (både kaldende bruger og evt. den bruger, som der bliver arbejdet på vegne af)
  • Dokumenter i svaret, identificeret på følgende måde:
    • Homecommunity-Id
    • Repository-id
    • Dokumentid

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



Gliffy Diagram
nameDDS Guide Til Anvender DDS Registry Søgning Flow
pagePin1