...

...

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å). 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 (anvendes i forbindelse med MinLog)
• Ikke-autoriseret bruger
  
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • hvis ingen national rolle sættes rollen "ingen_idkort_rolle"
  • titel bliver sat til at være national rolle - ellers anvendes konfigurerbar default værdi (anvendes i forbindelse med MinLog)
  Borger
  • værd
• Sundhedsfaglig på vegne af:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • titel bliver sat
med konfigurerbar default værdi (anvendes i forbindelse med MinLog)
• • 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 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
  • 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 endelige brugertype må ikke være af typen System

...

...

• B1: borger_soeg_egne.feature
• B2: borger_soeg_andre_fuldmagt.feature
• B2: borger_soeg_andre.featureSF1
• B2: sfBORGER_SOEG_ANDRE_SRP_FORAELDREMYNDIGHED
• SF1: sf_soeg_aftalersoeg_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.

...

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 driftvejldningendriftvejldning.

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

...

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.

...

DDSRepository 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].

Service business logik

DDS

...

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

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 Removed

...

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.
• 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

...

• 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 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

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

Generel struktur af invoker

...

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 PDC dokumentergraviditetsmappe 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.

...

• professionalUser
• professionalUserConsentOverride
• childCustodyHolder
• proxyHolder
• citizen

Eksempler på scenarier og deres konkret tekst udfald.

...