Versions Compared

Key

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

...

Gliffy Diagram
displayNameFlowdiagram-søgninger-DDS-B
nameFlowdiagram-søgninger-DDS-B
pagePin35

Flowet for borgere er det simpleste af de tre tilfælde. DDS Registry validerer medsendte akkreditiver, hvorefter søgningen sendes videre til DDS Backends. 

Er der tale om en borger med fuldmagt på vegne af en anden, undersøges de adspurgte søge parameter værdier. Og er de ulovlige returneres en fejl istedet for kald til DDS Backends. I de tilfælde, hvor en borger søger på en anden borger (ved relation i form af forældremyndighedshaver eller fuldmagtshaver) vil dette blive logget til MinLog.

Inden svaret returneres logges svaret i auditloggen.

...

Gliffy Diagram
displayNameFlowdiagram-søgninger-DDS-Sundhedsfaglig
nameFlowdiagram-søgninger-DDS-Sundhedsfaglig
pagePin34

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

...

Gliffy Diagram
displayNameFlowdiagram-søgninger-DDS-SF
nameFlowdiagram-søgninger-DDS-SF
pagePin34

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

...

Gliffy Diagram
displayNameFlowdiagram-hentning-DDS-B
nameFlowdiagram-hentning-DDS-B
pagePin56

Ikke-autoriseret bruger (IA): Flow for hentning af dokumenter via DDS Repository

...

Gliffy Diagram
displayNameFlowdiagram-hentning-DDS-IA2
nameFlowdiagram-hentning-DDS-IA2
pagePin1112

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.

...

Gliffy Diagram
displayNameFlowdiagram-hentning-DDS-SF
nameFlowdiagram-hentning-DDS-SF
pagePin1415

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.

...

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

Precondition:

  1. Borgeren har et eller flere dokumenter

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

Postcondition:

  1. Søgning i DDS Registry:
    1. Brugeren får en liste retur med id'er på alle dennes dokumenter
    2. Der kommer en linje i DDS auditlog
    3. Der kommer en linje i MinLog
  2. Hentning af dokumenter i DDS Repository:
    1. Brugeren får dokumenter retur svarende til de fremsøgte id'er
    2. Der kommer en linje i DDS auditlog
    3. Der kommer en linje i MinLog
EGNE_AFTALER_UKENDT_DOKUMENTTYPE

Precondition:

  1. Borgeren har 0 eller flere dokumenter

Action: Brugeren foretager en søgning efter ukendt (fejltastet) dokumenttype i DDS

Postcondition:

  1. Søgning i DDS Registry:
    1. Brugeren får en fejl retur: "Ingen aktive registries"
    2. Der kommer ikke en linje i DDS auditlog
    3. Der kommer ikke en linje i MinLog

Denne testcase udføres også med søgning på reference id

...

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

minlog.query.consentoverride = "Opslag af oplysninger, hvor samtykker tilsidesættes"

Borgeropslag kan angives i følgende konfigurationsparametre (relationen er angivet i HSUID headeren nsi:CitizenUserRelation):

minlog.query.childcustodyholder = "Opslag af oplysninger fra forældremyndighedsindehaver"

minlog.query.proxyholder = "Opslag af oplysninger fra fuldmagtshaver"

minlog.query.citizen=Opslag/Hentning af oplysninger fra borger

Værdierne der er angivet her er default værdierne.

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

...

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 

...

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 = "Hentning af oplysninger"

minlog.query.consentoverride = "Hentning af oplysninger, hvor samtykker tilsidesættes"

Borgeropslag kan angives i følgende konfigurationsparametre (relationen er angivet i HSUID headeren nsi:CitizenUserRelation):

minlog.query.childcustodyholder = "Opslag af oplysninger fra forældremyndighedsindehaver"

minlog.query.proxyholder = "Opslag af oplysninger fra fuldmagtshaver"

minlog.query.citizen=Opslag af oplysninger fra borger

Værdierne der er angivet her er default værdierne.

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

...

  • 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


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


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 i IHE XDS dokumentationen.

...