1. 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.
1.1. Ordliste
Betegnelse | Beskrivelse | Yderligere dokumentation |
---|---|---|
DDS | Dokumentdelingsservice | |
NSP | National Serviceplatform | |
BRS | Behandlingsrealtionservice | |
CDA | Clinical 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 |
XDS | Cross 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 |
FSK | Fælles Stamkort | |
HSUID | Healthcare Service User Identification | HSUID - Guide til anvendere |
2. Overblik over løsningen
Formålet med Dokumentdelingsservicen er at tilvejebringe adgang til data om patienten, fra forskellige datakilder, via et indeks. Anvendersystemer kan i indekset søge efter informationer om data på en given patient (metadata) og præsentere en oversigt over disse for sundhedsfaglige brugere og borgere. Såfremt en sundhedsfaglig bruger eller borger ønsker at få adgang til de bagvedliggende detaljerede patientdata, skal indekset levere tilstrækkelig information om, hvor og hvordan dette kan hentes.
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Dokumentdelingsservice (DDS) består altså primært 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.
De konkrete snitfladebeskrivelser for fremsøgning og hentning af dokumenter findes i dokumenterne herunder: Documentation Dokumentdelingsservice (snitflader og fejlmeddelelser)
2.1. Overordnede ansvarsområder i DDS
Udover at fungere som proxy for et antal bagvedliggende kilder, så har DDS også følgende ansvarsområder:
- Validering af medsendte sikkerhedsakkredidativer
- Tjek af en borgers spærringer i forhold til adgang til data (via MinSpærring)
- Bestilling af opfølgning på behandlingsrelation mellem borger og kaldende sundhedsprofessionelle (via BRS).
- Auditlogning
- Logning af værdispring
- Logning til MinLog
De overordnede flows er beskrevet i nedenstående afsnit.
2.2. 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 (forældremyndighedshaver/fuldmagtshaver). Via idws-snitfladen er det ikke muligt at forespørge på andet end egne data.
- 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
2.3. 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
2.4. 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.
2.4.1. 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 forældremyndighedshaver eller fuldmagtshaver) vil dette blive logget til MinLog.
Inden svaret returneres logges svaret i auditloggen.
2.4.2. 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:
- 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
2.4.3. 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:
- 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.
2.5. 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.
2.5.1. Borger (B): Flow for hentning af dokumenter via DDS Repository
Det overordnede flow ved en hentning i DDS Repository som en borger ser således ud:
2.5.2. Ikke-autoriseret bruger (IA): Flow for hentning af dokumenter via DDS Repository
Det overordnede flow ved en hentning i DDS Repository som en ikke-autoriseret bruger ser således ud:
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.
2.5.3. Sundhedsfaglig bruger (SF): Flow for hentning af dokumenter via DDS Repository
Det overordnede flow ved en hentning i DDS Repository som en sundhedsfaglig bruger ser således ud:
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.
2.6. Testcases for Dokumentdelingsservicen
I det følgende er beskrevet en række testcases. De dækker både DDS Registry og DDS Repository som en sammenhængende operation, da det er på den måde DDS servicen anvendes i praksis. Hvis søgningen i DDS Registry ikke giver nogle dokument id'er retur, så forespørges der ikke efter dokumenter i DDS Repository, så derfor har nogle af testcases ikke en del vedr. hentning af dokumenter.
2.6.1. Testcases hvor en Borger forespørger efter dokumenter
Brugerhistorier vedr. Borgere er beskrevet her: Borgerforspørgsler
Der findes følgende testcases for disse brugerhistorier:
2.6.1.1. Borger søger alle dokumenter sig selv
Testcases for: Borger søger alle dokumenter på borger | |
---|---|
EGNE_AFTALER |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
2.6.1.2. Borger søger alle dokumenter på anden borger
Testcases for: Borger søger alle dokumenter på borger | |
---|---|
BORGER_FREMSOGER_AFTALER_MED_FULDMAGT |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
BORGER_FREMSOGER_AFTALER_SOM_VAERGE |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
2.6.2. Testcases hvor en ikke-autoriseret bruger forespørger efter dokumenter
Brugerhistorier vedr. ikke-autoriseret bruger er beskrevet her: Ikke-autoriseret bruger
Der findes følgende testcases for disse brugerhistorier:
2.6.2.1. Ikke-autoriseret bruger uden nationale roller
Testcases for: Ikke-autoriseret bruger uden national rolle søger alle dokumenter på borger | |
---|---|
NEG_SPAERRING_EN_SF_ALLE_DOKUMENTTYPER |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Registry Postcondition:
|
NEG_SPAERRING_EN_SF_LABSVAR |
Action: Brugeren foretager en uindskrænket søgning i DDS Registry Postcondition:
|
LABSVAR_INGEN_SPÆRRING |
Action: Brugeren foretager en uindskrænket søgning i DDS Registry Postcondition:
|
STAMKORT_INGEN_SPÆRRING |
Action: Brugeren foretager en uindskrænket søgning i DDS Registry Postcondition:
|
2.6.2.2. Ikke-autoriseret bruger med national rolle 'Lægesekretær'
Testcases for: Ikke-autoriseret bruger med national rolle 'lægesekretær' søger alle dokumenter på borger | |
---|---|
NEG_SPAERRING_EN_SF_ALLE_DOKUMENTTYPER |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Registry Postcondition:
|
NEG_SPAERRING_EN_SF_LABSVAR |
Precondition:
Action: Brugeren foretager en uindskrænket søgning på labsvar i DDS Postcondition:
|
AFTALEDOKUMENTER |
Precondition:
Action: Brugeren foretager en søgning på aftaledokumenter i DDS Postcondition:
|
STAMKORT |
Precondition:
Action: Brugeren foretager en søgning på stamkort i DDS Postcondition:
|
FEJLSCENARIE_I_MISMATCH_I_KONTEKST_OG_SOEGNING_CPR |
Precondition:
Action: Brugeren foretager en søgning på aftaledokumenter i DDS Postcondition:
|
DATASPÆRRING |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
LABSVAR_INGEN_SPÆRRING |
Precondition:
Action: Brugeren foretager en søgning på labsvar i DDS Postcondition:
|
LABSVAR_DATA_SPAERRING |
Precondition:
Action: Brugeren foretager en søgning på labsvar i DDS Postcondition:
|
2.6.2.3. Ikke-autoriseret bruger med national rolle 'Sundhedsassistent'
Testcases for: Ikke-autoriseret bruger med national rolle 'sundhedsassisent' søger alle dokumenter på borger | |
---|---|
NEG_SPAERRING_EN_SF_ALLE_DOKUMENTTYPER |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
NEG_SPAERRING_EN_SF_LABSVAR (se "forsigtighedsprincippet" beskrevet i SDS-2503) |
Precondition:
Action: Brugeren foretager en uindskrænket søgning på labsvar i DDS Postcondition:
|
AFTALEDOKUMENTER_KAN_FREMSØGES |
Precondition:
Action: Brugeren foretager en søgning på aftaledokumenter i DDS Postcondition:
|
STAMKORT_KAN_FREMSØGES |
Precondition:
Action: Brugeren foretager en søgning på stamkort i DDS Postcondition:
|
REP_AFTALEDOKUMENTER_KAN_IKKE_FREMSØGES |
Precondition:
Action: Brugeren foretager en søgning på repeterende aftaledokumenter i DDS Postcondition:
|
DATASPÆRRING |
Precondition:
Action: Brugeren foretager en søgning i DDS efter dokumenter med typen aftaler Postcondition:
|
2.6.3. Testcases hvor en Sundhedsfaglig bruger forespørger efter dokumenter
Brugerhistorier vedr. sundhedsfaglige er beskrevet her: Sundhedsfaglig bruger
Der findes følgende testcases for disse brugerhistorier:
2.6.3.1. Sundhedsfaglig bruger søger efter aftaledokumenter
Testcases for: Sundhedsfaglig bruger søger aftaledokumenter på borger | |
---|---|
INGEN_SPAERRINGER_AFTALER |
Precondition:
Action: Brugeren foretager en søgning på repeterende aftaledokumenter i DDS Postcondition:
|
INGEN_SPAERRINGER_REPETERENDE_AFTALER |
Precondition:
Action: Brugeren foretager en søgning på aftaledokumenter i DDS Postcondition:
|
NEG_SPAERRING_DENNE_SF |
Precondition:
Action: Brugeren foretager en søgning efter aftaledokumenter i DDS Postcondition:
|
NEG_SPAERRING_ANDEN_SF |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS efter dokumenter med typen aftaler Postcondition:
|
DATA_SPAERRING |
Precondition:
Action: Brugeren foretager en søgning i DDS efter dokumenter med typen aftaler Postcondition:
|
2.6.3.2. Sundhedsfaglig bruger søger efter labsvar
Testcases for: Sundhedsfaglig bruger søger labsvardokumenter på borger | |
---|---|
INGEN_SPAERRINGER |
Precondition:
Action: Brugeren foretager en søgning på labsvar i DDS Postcondition:
|
NEG_SPAERRING_DENNE_SF |
Precondition:
Action: Brugeren foretager en søgning efter labsvar i DDS Postcondition:
|
NEG_SPAERRING_DENNE_SF_MED_VAERDISPRING |
Precondition:
Action: Brugeren foretager en søgning efter labsvar i DDS med angivelse af værdispring Postcondition:
|
DATA_SPAERRING |
Precondition:
Action: Brugeren foretager en søgning efter labsvar i DDS Postcondition:
|
DATA_SPAERRING_MED_VAERDISPRING |
Precondition:
Action: Brugeren foretager en søgning efter labsvar i DDS med angivelse af værdispring Postcondition:
|
2.6.3.3. Sundhedsfaglig bruger søger efter alle dokumenttyper
Testcases for: Sundhedsfaglig bruger søger alle dokumenter på borger | |
---|---|
INGEN_SPAERRINGER |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
FEJLSCENARIE_INGEN_SPAERRINGER_MEN_MISMATCH_I_KONTEKST_OG_SOEGNING_CPR |
Precondition:
Action: Brugeren foretager en søgning på aftaledokumenter i DDS Postcondition:
|
INGEN_DOKS |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
NEG_SPAERRING_DENNE_SF |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
NEG_SPAERRING_DENNE_SF_VAERDISPRING |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS med angivelse af værdispring Postcondition:
|
NEG_SPAERRING_DENNE_SF_INGEN_DOKS |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
NEG_SPAERRING_DENNE_SF_INGEN_DOKS_VAERDISPRING |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS med angivelse af værdispring Postcondition:
|
NEG_SPAERRING_ANDEN_SF |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
DATA_SPAERRING |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS Postcondition:
|
DATA_SPAERRING_VAERDISPRING |
Precondition:
Action: Brugeren foretager en uindskrænket søgning i DDS med angivelse af værdispring Postcondition:
|
3. 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.
3.1. 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? |
---|---|
sessionId | Flow-id (som angivet i Medcom headeren i følge DGWS) |
sourceSystemIdentifier | Kaldende system (som angivet i HSUID headeren nsi:SystemName) |
eventDateTime | Tidsstempel 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" Værdierne der er angivet her er default værdierne. |
personCivilRegistration | Borgerens CPR nummer (som opslaget drejer sig om) |
userIdentifier | Kaldende brugers CPR nummer (som angivet i HSUID headeren nsi:ActingUserCivilRegistrationNumber) |
userIdentifierOnBehalfOf | Ansvarlige brugers CPR nummer (som angivet i HSUID headeren nsi:ResponsibleUserCivilRegistrationNumber) |
healthcareProfessionalOrganisation | Organisationen (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)" |
3.2. 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? |
---|---|
sessionId | Flow-id (som angivet i Medcom headeren i følge DGWS) |
sourceSystemIdentifier | Kaldende system (som angivet i HSUID headeren nsi:SystemName) |
eventDateTime | Tidsstempel 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" Værdierne der er angivet her er default værdierne. |
personCivilRegistration | Borgerens CPR nummer (som opslaget drejer sig om) |
userIdentifier | Kaldende brugers CPR nummer (som angivet i HSUID headeren nsi:ActingUserCivilRegistrationNumber) |
userIdentifierOnBehalfOf | Ansvarlige brugers CPR nummer (som angivet i HSUID headeren nsi:ResponsibleUserCivilRegistrationNumber) |
healthcareProfessionalOrganisation | Organisationen (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)" |
4. 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
4.1. 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 TreatmentRelationRequest | Hvor stammer oplysningen fra i kald mod DDS? |
---|---|
PatientCpr | Borgerens 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). |
AuthorisationIdentifer | Hvis kaldet indeholder en autorisationskode (som angivet i HSUID headeren nsi:ResponsibleUserAuthorizationCode), så medsendes denne |
OrganisationIdentifier | Organisationen (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:
|
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:
|
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 den værdi der modtages i id-kortet fra attributten medcom:ITSystemName. Nuværende værdi: Dette er en variable værdi baseret på input. Hvis medcom:ITSystemName ikke er angivet i id-kortet, så sættes værdien til "intet_idkort_itsystem". 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 |
4.2. 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.
5. 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
5.1. 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.
5.2. 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
6. 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.
Den udstilles både som DGWS og IDWS snitflade:
- DGWS snitflade wsdl endpoints
- http://<nsp miljø>/ddsregistry?wsdl
- http://<nsp miljø>/ddsrepository?wsdl
- IDWS snitflade wsdl endpoints:
- http://<nsp miljø>/ddsregistry/idws?wsdl
- http://<nsp miljø>/ddsrepository/idws?wsdl
Når man kalder idws snitfladerne skal audience værdien sættes til "https://audience.nspop.dk/dds".
6.1. DocumentRegistry_RegistryStoredQuery og DocumentRegistry_Idws_RegistryStoredQuery (ITI-18)
Request parametre | Opt | Beskrivelse |
---|---|---|
$XDSDocumentEntryTypeCode | O |
Her kan angives en liste over mere finkornede dokumenttyper. Skal være på formen: '<Kode dokumenttype>^^<standard>' Eksempel: '53576-5^^2.16.840.1.113883.6.1' Dokumenttypen angives som PHMR Koden 53576-5 angiver et PHMR-dokument i standarden Logical Observation Identifiers Names and Codes (LOINC) identificeret ved 2.16.840.1.113883.6. Ud over PHMR (Personal Health Monitoring Record) kan der eksempelvis angives en af disse typekoder:
|
$XDSDocumentEntryPatientId | R |
Her angives CprNr for patienten. Skal være på formen: '<Cpr Nr>^^^&<OID>&ISO' hvor <OID> er en Object Identifier for udsteder af danske Cpr numre. |
$XDSDocumentEntryType | O | Her kan angives en liste over on-demand dokumenter. |
$XDSDocumentEntryStatus | R |
Her angives at man vil søge på gældende metadata og i dette tilfælde skal den have værdien: 'urn:oasis:names:tc:ebxml-regrep:StatusType:Approved' Det er også muligt at søge på forældede metadata og så skal den have værdien: 'urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated' |
6.2. DocumentRepository_RetrieveDocumentSet og DocumentRepository_Idws_RetrieveDocumentSet (ITI-43)
Request parametre | Beskrivelse |
---|---|
RepositoryUniqueId |
Global unik ID for det repository hvor dokumentet skal hentes fra. |
DocumentUniqueId |
Global unik ID for det dokument der skal hentes. |
7. Eksempler
Eksempler på request of response til de SOAP operationer der udstilles. De enkelte elementer er beskrevet under snitfladebeskrivelse.
Det er en forudsætning at der tilføjes gyldig sikkerhedsheader - bla. et gyldigt ID-kort.
7.1. DGWS eksempler
Det første eksempel (iti-18) indeholder sikkerhedsheadere. De 2 andre eksempler har dem klippet ud.
7.1.1. Fremsøgning af metadata dokumentoplysninger (ITI-18)
Brugerhistorie: sundhedsfaglig bruger søger efter alle dokumenttyper - INGEN_SPAERRINGER.
7.1.2. Fremsøning af dokumentoplysninger gennem Aftaleoversigt (ITI-18)
7.1.3. Hentning af dokument (ITI-43)
7.2. IDWS eksempel
Eksemplet er med sikkerhedsheadere.
7.2.1. Fremsøgning af metadata dokumentoplysninger (ITI-18)
Brugerhistorie: Borger søger alle dokumenter sig selv - EGNE_AFTALER