...

...

• Fremsøgning (DDS Registry)
  • Der etableres med løsningen en DDS Registry web service, som giver mulighed for opslag i DDS Registry for både sundhedspersoner og borgere.
  • Opslag gennemføres med operationen Reqistry Stored Query, der er IHE XDS.b’s operation til fremsøgning af metadata i et IHE registry. DDS Registry viderestiller fremsøgning af metadata til IHE Repository, der med produktet Healthshare er en implementation af netop IHE registry.
  • DDS understøtter pt følgende 3 query typer: FindDocuments, FindDocumentsByReferenceId, GetDocuments
• Hentning (DDS Repository)
  • Der etableres med løsningen en DDS Repository web service, som giver mulighed for både sundhedspersoner og borgere at udtrække dokumenter på baggrund af metadata registreret i dokumentdelingsservice.
  • DDS Repository benyttes som intelligent proxy for en eller flere dokumentkilder.
  • Udtræk gennemføres med operationen Retrieve Document Set, der er IHE XDS.b’s operation til udtræk af dokumenter fra et IHE repository.

...

• Logning i Min-log-servicen
• Igangsættelse af check af behandlingsrelation mellem borger og sundhedsfaglig
• Kontrol af samtykke herunder filtrering inden returnering af data
• Mulighed for værdispring
• For registry tjekkes om et givet registry er gældende matcher evt medsendt dokumenttype
• For repository også bestemmelse af dokumentkildes webservice-endpoint
• Se DDS guide til anvendere, afsnit søgning og hentning hvor denne logik er udførligt beskrevet for registry henholdsvis repository blandt andet for forskellige brugertyper.

...

DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stille stiller forskellige krav til autentifikations- og kaldkontekst. Derudover er anvendelsen af de eksterne services (samtykke, behandlingsrelation, minlog) forskellig for de forskellige adgangsscenarier.

...

...

Transformation af brugertyper

En system bruger giver ikke mening i sig selv, og skal mappes over til en rigtig bruger. Andre brugertyper kan også mappes til andre typer på baggrund af hsuid header information. En borger kan mappes til en borger på vegne af hva. cprFromPayload. Der findes følgende tranformationer:

Transformation af brugertyper

En systembruger giver ikke mening i sig selv, og skal mappes over til en anden brugertype. Andre brugertyper kan også mappes til andre typer på baggrund af hsuid header information. En borger kan mappes til en borger på vegne af ved hjælp af cprFromPayload (det vil sige det cprnummer, som der forespørges på).

Den følgende figur viser i venstre side, hvilke brugertypr man kan blive på baggrund af modellen i security api'et. I højre side viser de brugertyper, det er muligt at få tildelt i dokumentdelingsservicen. Pilene imellem venstre og højre side, viser de mulige transformationer, der kan ske mellem brugertyperne baseret på indhold af hsuid header/cprnr i payload. System brugeren er ikke en tilladt brugertype og returneres som en fejl.

...

...

De forskellige brugertyper bliver beriget med følgende:

• Sundhedsfaglig alm og på vegne af:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • titel bliver sat til at være educationCode
• Ikke-autoriseret bruger
  
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • hvis ingen antional national rolle sættes rollen "ingen_idkort_rolle"

...

• • titel bliver

...

• • sat til at være national rolle - ellers anvendes konfigurerbar default værd
• Sundhedsfaglig på vegne af:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • titel bliver sat til at være educationCode eller national rolle afhængig af den brugertype man arbejder på vegne af har
  • onbehalfof titel bliver sat til educationCode
• Borger
  • titel bliver sat med konfigurerbar default værdi (anvendes i forbindelse med MinLog)

Titel anvendes i forbindelse med MinLog, og bliver i forbindelse med berigelsen konverteret til en mere sigende tekst end educationCode/national rolle.

Brugertyperne bliver til sidst valideret for:

• Alle roller, hvis hsuid header medsendt:
  
  • hsuid rollen skal matche den på security context
  • hsuid acting user cpr skal matche den aktøren
• Borger på vegne af
  • Alle roller, hvis hsuid header medsendt:
    
    • hsuid rollen skal matche den på security context
    • hsuid acting user cpr skal matche den aktøren
  • Borger på vegne af
    • Der skal være en relation
  • Sundhedsfaglig og Sundhedsfaglig på vegne af
    • hsuid authorisationkode skal matche den på aktøren
    • hsuid OrganizationId valideres mod Sores, hvis organizationIdSource er SOR
  • Ikke-autoriseret bruger
    
    • hsuid OrganizationId valideres mod Sores, hvis organizationIdSource er SOR
  • Den Den endelige brugertype må ikke være af typen System

  ...

  	Samtykkeservice	MinLog Service	Behandlingsrelationservice
  B1 + B2	Ikke relevant (samtykkeservice omhandler kun samtykke i forhold til sundhedspersoner og disses organisationer)	Logges ikke Ja	Ikke relevant
  SF1 + SF3	Kaldes for at se, om der skulle foreligge et negativt samtykke mod den sundhedspersonen eller den organisations, som vedkommende repræsenterer. I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der tjekkes. Ved værdispring springes samtykketjek over	Ja I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der logges.	Ja I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der tjekkes.
  IA-1	Kaldes med USPECIFICERET. Samtykke tjekkes herved altid udfra forsigtighedsprincippet: Det tjekkes, om den relevante borger har givet negativt samtykke mod nogen person og eller organisation overhovedet (se SDS-2503 - Adgang for ikke aut. sundhedspersoner på DDS via trust ARKIVERET for detaljer)	Ja	Ja. Kaldes med '-' i stedet for autorisationskode. Se i øvrigt SDS-2990 - Ikke autoriserede brugere skal fremsende bindestreg til BRS som autorisationskode ARKIVERET for detaljer.

  ...

  • B1: borger_soeg_egne.feature
  • B2: borger_soeg_andre_fuldmagt.feature
  • B2: borger_soeg_andre.feature
  • B2: BORGER_SOEG_ANDRE_SRP_FORAELDREMYNDIGHED
  • SF1: sf_soeg_aftaler.feature
  • SF1: sf_soeg_alle_dokumenttyper.feature
  • SF1: sf_soeg_alle_dokumenttyper_byreferenceid.feature
  • SF1: sf_soeg_labsvar.feature
  • S3: <der findes ingen test>SF3: Samme features som SF1
  • IA1: ia_ingen_national_rolle.feature
  • IA1: ia_laege_sekraetaer.feature
  • IA1: ia_sundhedsassistent.feature

  ...

  ITI-18: foretag auditlogning af patient-id, bruger-id, på-vegne-af-id samt hsuid-header og for hver DocumentEntry (DE) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode.

  ITI-43: foretag auditlogning af patient-id, bruger-id, på-vegne-af-id samt huisd-header og for hver DocumentResponse (DR) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DR.uniqueId, DR.repositoryUniqueId, DR.homeCommunityId.

  ...

  Det påhviler anvendersystemet at sikre, at der kun forespørges om udtræk for samme patient.

  Arkitekturdesign

  Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.

  Overblik

  DDS Registry

  Den generelle servicestruktur er at servicen implementeres som en webservice, der implementerer det webinterface, der er genereret fra DDS Registry WSDL. Webservicen DDSRegistryWS er en tynd skal, der for sin eneste weboperation til opslag i DDS Registry blot kalder den faktiske implementation DDSRegistryQueryImpl.

  Image Removed

  Figur 3a: Implementationen af webservice-interfaces

  Der findes to alternative WSDL filer for operationen ITI-18 på DDS Registry og ITI-43 for DDS Repository, der gør de muligt at kalde DDS med en OIO IDWS billet. Forretningslogikken for disse snitflader er den samme som de klassiske DGWS snitflader.

  Behandling af opslag

  DDSRegistryQueryImpl forestår autentifikation og autorisation af anvendersystem vha. DGWSProvider. Som forberedelse til autentifikation og autorisation af bruger af webservicen foretager DDSRegistryImpl parsning og validering af SOAP-headerens HSUID-header vha. ValidatedHsuidAttributes.

  Autentifikation og autorisation af bruger varetages af UserCheck, der som input tager den skabte instans af ValidatedHsuidAttributes. Er brugeren en sundhedsperson og er der anført ansvarlig sundhedsperson cpr- og autorisationsnummer (fra Sundhedsstyrelsen), foretager UserCheck desuden kontrol af sammenhængen mellem cpr- og autorisationsnummeret.

  Til behandling af opslaget kaldes DDSRegistryQueryLogic, som beskrevet i afsnit DDS Registry Query Logic.

  DDSRegistryQueryImpl foretager fejlhåndtering ved at omdanne exceptions til SOAP fault med indhold som beskrevet i [DDS Registry query snitflade]. En undtagelse herfra er dog ved exception pga. negativt samtykke mod en sundhedsperson, hvor der dannes en advarsel i et tomt svar, også beskrevet i [DDS Registry query snitflade].

  DDS Repository

  Den generelle servicestruktur er at servicen implementeres som en webservice, der implementerer det webinterface, der er genereret fra DDS Repository WSDL [ITI-43++ SOAP 1.1 WSDL]. Webservicen er en tynd skal, der for sin eneste weboperation (til udtræk) blot kalder den faktiske implementation DDSRepository.

  Image Removed

  Figur 3b Implementationen af webservice-interfacet

  DDSRepository forestår autentifikation og autorisation af anvendersystem vha. DGWSProvider.

  Som forberedelse til autentifikation og autorisation af bruger af webservicen foretager DDSRepository parsning og validering af SOAP-headerens HSUID-header vha. ValidatedHsuidAttributes. Autentifikation og autorisation af bruger varetages af UserCheck, der som input tager den skabte instans af ValidatedHsuidAttributes. Er brugeren en sundhedsperson og er der anført ansvarlig sundhedsperson cpr- og autorisationsnummer (fra Sundhedsstyrelsen), foretager UserCheck desuden kontrol af sammenhængen mellem cpr- og autorisationsnummeret.

  Til behandling af udtræk kaldes DDSRetrieveDocumentLogic, som beskrevet i afsnit 4.2.

  DDSRepository foretager fejlhåndtering ved at omdanne exceptions til SOAP fault med indhold som beskrevet i [DDS Repository snitflade]. En undtagelse herfra er dog ved exception pga. negativt samtykke mod en sundhedsperson, hvor der dannes en advarsel i et tomt svar, også beskrevet i [DDS Repository snitflade].

  Service business logik

  DDS Registry

  DDSRegistryQueryLogic implementerer den sekvens af kald af services og håndtering af fejlsituationer, der er beskrevet i afsnit 2.3.1.1. Dog håndteres autentificering og autorisation beskrevet i afsnittet af DDSRegistryQueryImpl som beskrevet ovenfor.

  Image Removed

  Figur 4a DDSRegistryQueryLogic får dependency injected et antal delegates, der varetager kald til de forskellige services.

  DDSRegistryQueryLogic forestår orkestrering af kald til de forskellige services, hvor kaldene er pakket ind i ”invokere”:

  • ConsentVerificationServiceInvoker indkapsler kald af ConsentUserCheck og ConsentDataCheck på samtykkeverifikationsservicen. Se [ConsentVerificationService ws] for beskrivelse af kaldte webservice-snitflade.
  • DocumentRegistryInvoker forestår videresendelse af opslaget til IHE Registry-servicen. Dette sker gennem et webservice-interface beskrevet i [IHE WSDL] og [IHE XSD].
  • MinLogRegistrationInvoker indkapsler kaldet til MinLogRegistration-servicen. Se [MinLogService ws] for beskrivelse af kaldte webservice-snitflade.
  • TreatmentRelationInvoker laver kaldet til behandlingsrelationsservicen. Se [Behandlingsrelationsservice ws] for beskrivelse af kaldte webservice-snitflade.
  • ConsentOverrideLoggingInvoker indkapsler den måde, logning af værdispring er implementeret.

  Derudover gør DDSRegistryQueryLogic brug af ConsentFilter, der implementerer den betingede filtrering af metadata i resultatet fra opslaget på IHE Registry. ConsentFilter kommer kun i anvendelse, når en sundhedsperson laver opslag uden anvendelse af værdispring og når sundhedspersonen er omfattet af data-specifikke samtykker.

  Image Removed

  Figur 5a UML Sekvensdiagram for DDSRegistryQueryLogic

  I Figur 5a er vist et sekvensdiagram for DDSRegistryQueryLogic ved opslag foretaget af en sundhedspersons uden anvendelse af værdispring, hvor: der ikke er personligt negativt samtykke mod sundhedspersonen eller den ansvarlige sundhedsperson; der er data-specifikt negativt samtykke.

  DDS Repository

  ...

  Filtrering af registry kald vha. dokumenttype

  I praksis er følgende situationer opstået:

  • Der kan returnerres fejlkoder for indekses/registries som ikke indeholder dokumenter på de forespurgte dokumenttyper
  • Nedbrud i enkelte registries/repositories har indvirkning på alle forespørgsler uanset dokumenttype
  • Lange svartider i enkelte registries har i dag indvirkning på alle forespørgsler uanset dokumenttype

  For at forbedre disse punkter er det blevet lavet muligt at konfiguerere hvilke dokumenttyper et givet registry er interessant for. Når en iti-18 søgning (Registry Stored Query) indeholder dokumenttype, kan man hermed vidersende kaldet til et udvalg af registries istedet for alle. For opsætning af dette, se driftvejldningen.

  Filtrering af registry kald vha. feature toggling

  Da behovet for at undersøtte FindDocumentsByReferenceId query typen for iti-18  opstod blev DDS udvidet med denne mulighed. Desværre understøtter alle DDS'ens backends ikke denne mulighed. Så for at undgå at introducere en række fejlsvar fra disse backends, er det blevet gjort muligt at konfigure, hvilke query typer de forskellige registry backends understøtter. Database delen er lavet så generisk, at det istedet for "query typer" hedder "features" så man i fremtiden også kan anvende den til andre filtreringer på ting, som de forskellige registry backends understøtter eller ikke understøtter. For opsætning af dette, se driftvejldning.

  Filtrering af dokumenter vha. typecode, eventcode og practicesettingcode

  For at kunne differentiere på et højere niveau, end at man som sundhedfaglig har adgang til alle eller ingen dokumenter på en patient, er der oprettet muligheden for at lave et metadata filter. For et givet CVR nummer og systemnavn kan man angive vha. metadata, hvad den sundhedsfaglige må se.

  Pt. er det muligt at filtrere på typecode (dokumenttype), eventcode og practicesettingcode. Som minimum skal et dokument matche en konfigureret typecode. Og er der for en konfiguration sat eventcode og practicesettingcodes på, skal disse også indgå i metdata for dokumtet for at de kommer med.

  Der filtreres kun, hvis der ikke er valgt værdispring. Og filtreres dokumenter fra, giver det anledning til en fejltekst i svaret.

  For opsætning se driftvejledningen.

  Validering af Actor Query Parametre

  Nogle actors har ikke love til at lave søgninger (ITI-18) på alle værdier i query parametrene.  Derfor kan man begrænse nogle actor/bruger typer på det parameter værdier de laver i søgningerne.

  For nuværende drejer det sig om følgende brugertype:

  • Borger på vegne af, med relationen fuldmagt, hvor fuldmagten kommer fra en fuldmagtstreng. Der skal være givet tilladelse til denne fuldmagtstreng for den anvendte typecode og formatcode værdi.
  • Borger med forældremyndighed. Det skal være givet tilladelse til de anvendte typecode og formatcode værdier for denne brugertype.

  For opsætning se driftvejledningen.

  Arkitekturdesign

  Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.

  Overblik

  DDS Registry

  Den generelle servicestruktur er at servicen implementeres som en webservice, der implementerer det webinterface, der er genereret fra DDS Registry WSDL. Webservicen DDSRegistryWS er en tynd skal, der for sin eneste weboperation til opslag i DDS Registry blot kalder den faktiske implementation DDSRegistryQueryImpl.

  Image Added

  Figur 3a: Implementationen af webservice-interfaces

  Der findes to alternative WSDL filer for operationen ITI-18 på DDS Registry og ITI-43 for DDS Repository, der gør de muligt at kalde DDS med en OIO IDWS billet. Forretningslogikken for disse snitflader er den samme som de klassiske DGWS snitflader.

  Behandling af opslag

  DDSRegistryQueryImpl forestår autentifikation og autorisation af anvendersystem vha. DGWSProvider. Som forberedelse til autentifikation og autorisation af bruger af webservicen foretager DDSRegistryImpl parsning og validering af SOAP-headerens HSUID-header vha. ValidatedHsuidAttributes.

  Autentifikation og autorisation af bruger varetages af ServiceActorProvider, der som input tager den skabte instans af SecurityContext og ValidatedHsuidAttributes.  Der foretages en række check og valideringer, se ovenfor under afsnittet brugertyper.

  Til behandling af opslaget kaldes DDSRegistryQueryLogic, som beskrevet i afsnit DDS Registry Query Logic.

  DDSRegistryQueryImpl foretager fejlhåndtering ved at omdanne exceptions til SOAP fault med indhold som beskrevet i [DDS Registry query snitflade]. En undtagelse herfra er dog ved exception pga. negativt samtykke mod en sundhedsperson, hvor der dannes en advarsel i et tomt svar, også beskrevet i [DDS Registry query snitflade].

  DDS Repository

  Den generelle servicestruktur er at servicen implementeres som en webservice, der implementerer det webinterface, der er genereret fra DDS Repository WSDL [ITI-43++ SOAP 1.1 WSDL]. Webservicen er en tynd skal, der for sin eneste weboperation (til udtræk) blot kalder den faktiske implementation DDSRepository.

  Image Added

  Figur 3b Implementationen af webservice-interfacet

  DDSRepository forestår autentifikation og autorisation af anvendersystem vha. DGWSProvider.

  Som forberedelse til autentifikation og autorisation af bruger af webservicen foretager DDSRepository parsning og validering af SOAP-headerens HSUID-header vha. ValidatedHsuidAttributes. Autentifikation og autorisation af bruger varetages af UserCheck, der som input tager den skabte instans af ValidatedHsuidAttributes. Er brugeren en sundhedsperson og er der anført ansvarlig sundhedsperson cpr- og autorisationsnummer (fra Sundhedsstyrelsen), foretager UserCheck desuden kontrol af sammenhængen mellem cpr- og autorisationsnummeret.

  Til behandling af udtræk kaldes DDSRetrieveDocumentLogic, som beskrevet i afsnit 4.2.

  DDSRepository foretager fejlhåndtering ved at omdanne exceptions til SOAP fault med indhold som beskrevet i [DDS Repository snitflade]. En undtagelse herfra er dog ved exception pga. negativt samtykke mod en sundhedsperson, hvor der dannes en advarsel i et tomt svar, også beskrevet i [DDS Repository snitflade].

  Service business logik

  DDS Registry

  DDSRegistryQueryLogic implementerer den sekvens af kald af services og håndtering af fejlsituationer, der er beskrevet i afsnit 2.3.1.1. Dog håndteres autentificering og autorisation beskrevet i afsnittet af

  ...

  DDSRegistryQueryImpl som beskrevet ovenfor.

  ...

  ...

  
  

  Image Added

  Figur

  ...

  4a DDSRegistryQueryLogic får dependency injected et antal delegates, der varetager kald til de forskellige services.

  ...

  DDSRegistryQueryLogic forestår orkestrering af kald til de forskellige services, hvor kaldene er pakket ind i ”invokere”:

  • ConsentVerificationServiceInvoker indkapsler kald af ConsentUserCheck og ConsentDataCheck på samtykkeverifikationsservicen. Se [ConsentVerificationService ws] for beskrivelse af kaldte webservice-snitflade.
  • DocumentRetrieveInvoker DocumentRegistryInvoker forestår videresendelse af udtræk til et kildesystems ITI-43 snitfladeopslaget til IHE Registry-servicen. Dette sker gennem et webservice-interface beskrevet i [IHE Document Repository WSDL] og [ITI TF-2IHE XSD].
  • MinLogRegistrationInvoker indkapsler kaldet til MinLogRegistration-servicen. Se [MinLogService ws] for beskrivelse af kaldte webservice-snitflade.
  • TreatmentRelationInvoker laver kaldet til behandlingsrelationsservicen. Se [Behandlingsrelationsservice ws] for beskrivelse af kaldte webservice-snitflade.
  • ConsentOverrideLoggingInvoker indkapsler den måde, logning af værdispring er implementeret.

  I Figur 5b er vist et sekvensdiagram for DDSRepository.

  Image Removed

  Figur 5b Sekvensdiagram for DDSRetrieveDocumentLogic

  Generel struktur af invoker

  Fælles for de service-invokere, der er beskrevet i foregående afsnit er at de hver især har ansvar for:

  • at indhente krævede konfigurationsparametre (fx URL for kaldte service)
  • at etablere og om nødvendigt genetablere kontakt til servicen
  • at gennemføre kald af den eller de operationer
  • at håndtere og indkapsle alle fejl

  Der er overordnet to typer af invokers: Dem med og dem uden DGWS sikkerhed.

  Invoker med anvendelse af DGWS

  Når der laves kald af ConsentVerificationServiceInvoker og TreatmentRelationInvoker skal det foregå med et SOSI Idkort. Det er DDS's ansvar at anskaffe et system idkort således, at dette kald kan gennemføres.

  Der er lavet generel håndtering af disse system idkort herunder caching.

  Der er også tilfælde, hvor backends for enten DDS Registry eller DDS Repository forventer at få akkreditiver med i kaldet. Her er det som udgangspunkt den samme sikkerhedsbillet, som blev anvendt til DDS selv, der delegeres videre til den modtagende backend. Hvis DDS Registry eller DDS Repository bliver kaldt med en IDWS billet er videre delegering ikke muligt p.g.a Holder-of-key constraint. I dette tilfælde vil DDSens eget system idkort anvendes, som beskrevet ovenfor for kald til MInSpærring og BRS.

  Invoker uden anvendelse af DGWS

  Der er backends for både DDS Registry og DDS Repository, der ikke foreventer en sikkerhedsbillet. NXRG er et eksempel på dette. Til dette formål anvendes en serviceinvoker uden DGWS.

  ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.

  SLA logning

  SLA loggeren sørger for at foretage SLA logning af alle servicekald.

  ...

  Derudover gør DDSRegistryQueryLogic brug af ConsentFilter, der implementerer den betingede filtrering af metadata i resultatet fra opslaget på IHE Registry. ConsentFilter kommer kun i anvendelse, når en sundhedsperson laver opslag uden anvendelse af værdispring og når sundhedspersonen er omfattet af data-specifikke samtykker.

  Image Added

  Figur 5a UML Sekvensdiagram for DDSRegistryQueryLogic

  I Figur 5a er vist et sekvensdiagram for DDSRegistryQueryLogic ved opslag foretaget af en sundhedspersons uden anvendelse af værdispring, hvor: der ikke er personligt negativt samtykke mod sundhedspersonen eller den ansvarlige sundhedsperson; der er data-specifikt negativt samtykke.

  DDS Repository

  DDSRepository implementerer den sekvens af kald af services og håndtering af fejlsituationer, der er beskrevet i afsnit 2.1.1. Dog håndteres autentificering og autorisation af DDSRepository som beskrevet ovenfor. 

  Image Added

  Figur 4b DDSRetrieveDocumentLogic får dependency injected et antal delegates, der varetager kald til de forskellige services.

  DDSRepository forestår orkestrering af kald til de forskellige services, hvor kaldene er pakket ind i ”invokere”:

  • ConsentVerificationServiceInvoker indkapsler kald af ConsentUserCheck på samtykkeverifikationsservicen. Se [ConsentVerificationService ws] for beskrivelse af kaldte webservice-snitflade.
  • DocumentRetrieveInvoker forestår videresendelse af udtræk til et kildesystems ITI-43 snitflade. Dette sker gennem et webservice-interface beskrevet i [IHE Document Repository WSDL] og [ITI TF-2].
  • MinLogRegistrationInvoker indkapsler kaldet til MinLogRegistration-servicen. Se [MinLogService ws] for beskrivelse af kaldte webservice-snitflade.
  • TreatmentRelationInvoker laver kaldet til behandlingsrelationsservicen. Se [Behandlingsrelationsservice ws] for beskrivelse af kaldte webservice-snitflade.
  • ConsentOverrideLoggingInvoker indkapsler den måde, logning af værdispring er implementeret.

  
  

  I Figur 5b er vist et sekvensdiagram for DDSRepository.

  Image Added

  Figur 5b Sekvensdiagram for DDSRetrieveDocumentLogic

  Overblik over konfigurationsmuligheder for dokumentsøgning og hentning

  Dette afsnit giver først, vha. en figur et helt overordnet overblik over, hvor der er muligheder for at påvirke det resultat, som en anvender fremsøger/henter af dokumenter. Efterfølgende er der i en tabel en mere detaljeret beskrivelse af disse. 

  Overordnet overblik

  I DDS registry og DDS repository, er der flere steder, hvor det er muligt at konfigurere opsætning, som påvirker, hvordan og hvad en anvender får tilbage af fremsøgning (iti-18 registry) og hentning (iti-43 repository).

  I den følgende figur er dette illustreret for DDS registry henholdsvis DDS repository for de 2 går søjler: ITI-18 og ITI-43. Detaljer omkring de forksellige konfigurationer kan findes i afsnittet efter.

  Figuren viser 4 logiske knudepunkter i DDS servicen og hvilke konfiguration der anvendes hvor:

  • Validering af forespørgsel: valideres på vej ind i servicen og anvender får en fejl uden der faktisk foretaget søgning. Undtagelse: frabedelsescheck effektueres først efter fremsøgning.
  • Opsæt af muligheder: fremfinding af det grundlag, som dokumenterne skal søges i
  • Filtering af muligheder: filtrering/begrænsning af det datagrundlag, som søges i.
  • Filtrering af dokumenter: når søgningen er foretaget, kan dokumenter, som ikke må returneres blive filtreret fra

  
  

  Gliffy Diagram
  displayName konfigurationsoverblik name konfigurationsoverblik pagePin 4

  Figur: konfigurationsoverblik

  Detaljer omkring konfigurationerne

  Nedenfor er hver konfiguration beskrevet.  Tabellen indeholder følgende kolonner:

  Analysen er dokumenteret vha. en tabel med følgende kolonner:

  • Id: id og navn som konfigurationen er kendt under
  • Formål: formålet med konfigurationen.
  • Brugertype: hvilke brugertyper gælder konfigurationen for. Der anvendes brugertyperne fra sourcekoden, som kan mappes som følger
    • Citizen - Borger
    • CitizenOnBehalfOf - BorgerPåVegneAf med undertyperne
      • proxyHolder - fuldmagtshaver
      • childCustodyHolder - forældremyndighedshaver
    • HealthCareProfessionalWithAuthorization - Sundshedsfaglig med authorisation
    • HealthCareProfessionalWithoutAuthorization - Sundshedsfaglig uden authorisation
    • HealthCareProfessionalOnBehalfOf - Sundhedsfaglig på vegne af
  • Aktivering: hvor "møder" anvenderen begrænsningen. Mulighederne er som angivet i ovenstående figur.
  • Kald: Er der tale om fremsøgning i registry (iti18) eller hentning i repository (iti43)
  • Muligheder: hvilke konfigurationsmuligheder er der, og hvor er det defineret.
  • Udtryk: hvordan kommer begrænsningen til udtryk? Fejlbesked, filtrering etc
    • SoapFault: bruger får en "hård" fejl (intet ihe svar og dermed ingen dokumenter)
    • Fejl: brugeren får en fejl i ihe svaret og 0 eller flere dokumenter
    • Advarsel: brugeren får en eller flere advarsler i ihe svaret og 0 eller flere dokumenter
    • Alt ok: brugeren får 0 eller flere dokumenter
  • Faktisk konfiguration: link til hvordan drift faktisk er sat op

  
  

  Id	Formål	Brugertype	Aktivering	Kald	Muligheder	Udtryk	Faktisk konfiguration
  DDK10 Aktør modellering og andet "teknisk" request validering:
  	Kontrol  af brugertyper og deres indhold.	HealthCareProfessionalOnBehalfOf HealthCareProfessionalWithAuthorization HealthCareProfessionalWithoutAuthorization Citizen CitizenOnBehalfOf variant proxyHolder - vha. fuldmagtsstreng childCustodyHolder	Validering af forespørgsel	ITI18 ITI43	Fast defineret i Aktørmodelleringen  (ServiceActorProvider) i servicen	SoapFault med fejlbeskeden flere forskellige fejlbeskeder afhængig af problemet	Se DDS - Brugerhistorier
  DDK11 Aktør søge parameter validering:
  	At begrænse specifikke brugertyper fra specifikke søge værdier.	CitizenOnBehalfOf variant proxyHolder - vha. fuldmagtsstreng childCustodyHolder	Validering af forespørgsel	ITI18	I klassen DDSRegistryQueryImpl kaldes  DDSActorQueryParameterValidator der undersøger om en given brugertype, anvender lovlige værdier i søgeparametrene. Ved opslag i db tabel actor_query_parameter_configuration: typecode fra req skal matche db formatcode fra req skal matche hvis udfyldt i db For Fuldmagt gælder yderligere: fuldmagtssteng fra req skal matche db privilege	SoapFault, med en af følgende fejlbeskeder: En borger med fuldmagt skal angive typecode som søgeparameter De(n) anvendte fuldmagtstreng(e) tillader ikke de anvendte søgeparametre værdier for typecode og formatcode En borger med forældremyndighed skal angive typecode som søgeparameter En borger med forældremyndighed må ikke søge med de anvendte søgeparametre værdier for typecode og formatcode	Se DDS - Brugerhistorier
  DDK12 Frabedelser - userCheck:
  	Kontrol af dataadgang	HealthCareProfessionalOnBehalfOf HealthCareProfessionalWithAuthorization HealthCareProfessionalWithoutAuthorization	Validering af forespørgsel	ITI18 ITI43	I klasserne DDSRegistryQueryLogic og DDSRetrieveDocumentLogic laves der kald til samtykke servicen, hvis der ikke er anvendt værdispring.	Fejl i almindeligt response med fejlbeskeden: urn:dk:nsi:Consent Filter Applied	Afhængig af den enkelte borgeres person (who) frabedelser. Disse kan ses på Sundhed.dk for den pågælende borger, i NADM eller via DRG (kun testmijøer)
  DDK20 Backend registries:
  	Opsæt af registries	na	Opsæt af muligheder	ITI18	I klassen DocumentRegistryFinderImpl findes de registries, det er muligt at lave søgninger i. Dette gøres ved at hente de registries i db tabel documentregistry hvor documentregistryactive er true	na	Se Dokumenttyper interne og eksterne
  DDK21 Backend repositories:
  	Opsæt af repositories	na	Opsæt af muligheder	ITI43	Fremfinder alle repositories i db tabel documentsource som er relevante for de dokumenter, som ønskes hentet.	na	Se Dokumenttyper interne og eksterne
  DDK30 Forespørge dokumenttype relevante registries:
  	Begrænsning i opslag pga performance og fejlmuligheder	na	Filtrering af muligheder	ITI18	I klassen DocumentRegistryFinderImpl hentes registries fra db documentregistry og DocumentTypeConfiguration kaldes, som ved opslag i db tabel documenttype_configuration tjekker hvert registry om relevant: documentregistryid fra db documentregistry skal matche typecode fra req skal matche Hvis ingen typecode i req eller ingen records fundet for registry medtages registry i søgningen	Hvis filtrering giver en tom liste af registries så SoapFault med fejlbeskeden "Ingen aktive registries"	Se Dokumenttyper interne og eksterne
  DDK31 Forespørge querytype relevante registries:
  	Begrænsning forskellige måder at lave  opslag pga. performance og fejlmuligheder.	na	Filtrering af muligheder	ITI18	I klassen DocumentRegistryFinderImpl hentes registries fra db documentregistry og RegistryFeatureConfiguration kaldes, som ved opslag i db tabel feature_configuration tjekker hvert registry om relevant: documentregistryid fra db documentregistry skal matche featurename quertytype fra request skal matche enabled skal være 1 Hvis ingen match fravælges registry i søgningen Tabellen fortæller om en eller flere af nedenstående queries understøttes:  FIND_DOCUMENTS_QRY,  GET_DOCUMENTS_QRY, FIND_DOCUMENTS_BY_REFERENCE_QRY Der henvises til https://profiles.ihe.net/ITI/TF/Volume2/ITI-18.html#3.18 for en beskrivelse af de forskellige queries	Hvis et registry fravælges så en advarsel i almindeligt response med advarselsteksten: Registryname og XDSUnknownStoredQuery Hvis filtrering giver en tom liste af registries så SoapFault med fejlbeskeden "Ingen aktive registries"	Afhænger af hvor registry befinder sig. Som udgangspunkt understøtter alle NSP registries alle de tre nævnte queries, NSP registries er dem som er markeret med NXRG i listen: Dokumenttyper interne og eksterne Øvrige registries understøtter kun:  FIND_DOCUMENTS_QRY
  DDK42 Nationale rolle check:
  	Kontrol af dataadgang	HealthCareProfessionalWithoutAuthorization	Filtrering af dokumenter	ITI18	Klassen DDSRegistryQueryLogic kalder TrustedRoleFilter, som tjekker brugerens rolle mod filen trusted_roles.txt Der gives kun adgang til de typecodes er angivet for rolle Er typecode "*" tillades alle typecodes	Fejl i almindeligt response med fejlbeskeden: urn:dk:nsi:Unauthorized Role Dokumenter er filtreret fra	Se DDS - Brugerhistorier
  DDK43 Whitelist af cvr/system:
  	Kontrol af dataadgang	HealthCareProfessionalOnBehalfOf HealthCareProfessionalWithAuthorization HealthCareProfessionalWithoutAuthorization	Filtrering af dokumenter	ITI18	Klassen DDSRegistryQueryLogic kalder  WhitelistBasedOnMetadataFilter, som hvis whitelisting er slået til (whitelisted.document.metadata.active) og der ikke er lavet værdispring udføre følgende logik: Ved opslag i db tabellerne, whitelist_config_documentmetadata,  whitelist_config_documentmetadata_typecode, whitelist_config_documentmetadata_eventcode og whitelist_config_documentmetadata_practicesettingcode tjekkes de fremfundne dokumenters metadata for, om de er whitelistet  med cvr fra request* skal matche systemnavn fra request* skal matche typecode fra request skal matche, er udfyldt i db eventcode fra request skal matche hvis udfyldt i db practicesettingcode fra request skal matche hvis udfyldt i db *cvr: securityContext.getOrganisation().get().getIdentifier(), hvis formatet er CVR *systemnavn: securityContext.getClient().get().getName().get() 2025-07-02: ikke merget ind på main branch i skrivende stund	Fejl i almindelig response med fejlbeskeden: urn:dk:nsi:Metadata Whitelist Filter Applied Dokumenter er filtreret fra	Endnu ikke defineret
  DDK40 Frabedelser - datacheck:
  	Kontrol af dataadgang	HealthCareProfessionalOnBehalfOf HealthCareProfessionalWithAuthorization HealthCareProfessionalWithoutAuthorization	Filtrering af dokumenter	ITI18	I klassen DDSRegistryQueryLogic  kaldes ConsentFilterImpl som laver kald til samtykke servicen, hvis der ikke er anvendt værdispring.	Advarsel i almindeligt response med advarselstekten: urn:dk:nsi:Consent Filter Applied Dokumenter der er frabedelser på er filtreret fra	Afhængig af den enkelte borgeres data (what) frabedelser. Disse kan ses på Sundhed.dk for den pågælende borger, i NADM eller via DRG (kun testmijøer)
  			Filtrering i dokument	ITI43	I klassen DDSRetrieveDocumentLogic laver kald til samtykke servicen, hvis der ikke er anvendt værdispring.	Fejl i almindeligt response med fejlbeskeden: urn:dk:nsi:Consent Filter Applied Dokumentindhold der er frabedelser på er filtreret fra	Afhængig af den enkelte borgeres data (what) frabedelser. Disse kan ses på Sundhed.dk for den pågælende borger, i NADM eller via DRG (kun testmijøer)
  DDK41 Frabedelser - datacheck udvidet:
  	Kontrol af dataadgang	HealthCareProfessionalOnBehalfOf HealthCareProfessionalWithAuthorization HealthCareProfessionalWithoutAuthorization	Filtrering af dokumenter	ITI18	Klassen DDSRegistryQueryLogic kalder PrecautionaryFilter, hvis der bare er een frabedelse. Her spærres for alle dokumenter med typecodes konfigureret i filen precautionary_filter.txt	Advarsel i almindeligt response med advarselsteksten: urn:dk:nsi:Consent Filter Applied Dokumenter er filtreret fra	Afventer afklaring

  
  

  
  

  Generel struktur af invoker

  Fælles for de service-invokere, der er beskrevet i foregående afsnit er at de hver især har ansvar for:

  • at indhente krævede konfigurationsparametre (fx URL for kaldte service)
  • at etablere og om nødvendigt genetablere kontakt til servicen
  • at gennemføre kald af den eller de operationer
  • at håndtere og indkapsle alle fejl

  Der er overordnet to typer af invokers: Dem med og dem uden DGWS sikkerhed.

  Invoker med anvendelse af DGWS

  Når der laves kald af ConsentVerificationServiceInvoker og TreatmentRelationInvoker skal det foregå med et SOSI Idkort. Det er DDS's ansvar at anskaffe et system idkort således, at dette kald kan gennemføres.

  Der er lavet generel håndtering af disse system idkort herunder caching.

  Der er også tilfælde, hvor backends for enten DDS Registry eller DDS Repository forventer at få akkreditiver med i kaldet. Her er det som udgangspunkt den samme sikkerhedsbillet, som blev anvendt til DDS selv, der delegeres videre til den modtagende backend. Hvis DDS Registry eller DDS Repository bliver kaldt med en IDWS billet er videre delegering ikke muligt p.g.a Holder-of-key constraint. I dette tilfælde vil DDSens eget system idkort anvendes, som beskrevet ovenfor for kald til MInSpærring og BRS.

  Invoker uden anvendelse af DGWS

  Der er backends for både DDS Registry og DDS Repository, der ikke foreventer en sikkerhedsbillet. NXRG er et eksempel på dette. Til dette formål anvendes en serviceinvoker uden DGWS.

  ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.

  SLA logning

  SLA loggeren sørger for at foretage SLA logning af alle servicekald.

  SLA loggeren er implementeret som et servlet filter defineret i webapplikationens web.xml-fil.

  MinLog

  På et tidspunkt blev alle ITI-18 søgninger logget i MinLog med den samme konfigurerbare sætning. Dette er nødvendigt hvis søgningen returnerer flere forskellige dokumenttyper. Hvis en søgning er begrænset med en enkelt kendt TypeCode kan man dog godt konkludere at anvenderen kun har fået adgang til en bestemt slags dokumenter, hvilket kan afspejles i den sætning der logges i MinLog. Derfor udvides løsningen med denne mulighed, samt yderligere detaljeringsgrad ved også at kigge på formatcode og classcode i bestemmelse af minlog teksten.

  Ved at sammenligne en ITI-18 søgnings søge parametre med opsætning i en database findes en mere detaljeret tekst til logningen. Hvis det ikke er muligt, at finde en detaljeret tekst, anvendes den oprindelige default opsætning. Der kan være flere grunde til Ikke at kunne finde en detaljeret tekst; flere forskellige værdier af de forskellige koder i kaldet, f.eks. at der både søges på aftaler og graviditetsmappe dokumenter, at der ikke er angivet nogen af de søgekriterier vi undersøger på, eller at der ikke er sat noget konfiguration op, på det anvendte søge kriterie. I sidstnævnte logges dette som en warning.

  Anvendes parametren %s i den detaljerede tekst, findes en erstatnings tekst i en brugertype tabel baseret, på den rolle, der har lavet kaldet. 

  
  

  De detaljerede tekster findes i følgende tabeller

  minlog_text:

  	Felt	Type	Andet
  1	id	int(10)	not null, auto inc, primary key
  2	typecode_codename	varchar(64)	unique key samme med 2-7
  3	typecode_schemename	varchar(64)	unique key samme med 2-7
  4	classcode_codename	varchar(64)	unique key samme med 2-7
  5	classcode_schemename	varchar(64)	unique key samme med 2-7
  6	formatcode_codename	varchar(64)	unique key samme med 2-7
  7	formatcode_schemename	varchar(64)	unique key samme med 2-7
  8	text	varchar(128)	not null

  
  minlog_usertype_text:

  	Felt	Type	Andet
  1	id	int(10)	not null, auto inc, primary key
  2	usertype	varchar(256)	not null, unique key
  3	text	varchar(128)	not null

  
  

  Mulige roller i feltet "usertype" til fremfinding af erstatningstekst er:

  • professionalUser
  • professionalUserConsentOverride
  • childCustodyHolder
  • proxyHolder
  • citizen

  
  

  Eksempler på scenarier og deres konkret tekst udfald.

  
  

  Gliffy Diagram
  displayName minlogtext name minlogtext pagePin 8

  Eksempel 1: der søges kun på een typecode. I minlog_text findes: "Opslag på aftale"

  Eksempel 2: der søges kun på een typecode. I minlog_text findes: "Opslag på labsvar fra %s". proxyholder rollen slåes op i minlog_usertype_text og teksten bliver: "Opslag på labsvar fra fuldmagtshaver"

  Eksempel 3: der søges på to typecodes. Default værdi for proxyholder anvendes og teksten bliver: "Opslag af oplysninger fra fuldmagtshaver"

  Eksempel 4: der søges på en typecode, der ikke findes i databasen. Default værdi for childCustodyHolder anvendes og teksten bliver: "Opslag af oplysninger fra forældremyndighedsindehaver"

  Integration og test

  Integrationsstrategi

  ...