...

TODO: tjek alias fra orig dokument og se hvad der stadig er i spil

TODO: dds var meget konkret i link ind til dokumenter.

...

Det er fortsat DDS egen opgave at validere, at den kaldende brugers kald er lovlige/giver mening og overholder de i DDS gældende forretningsregler.

Kontrol af data-specifikke samtykker foretages af kildesystem

Alternativer:

1. Kontrol fra DDS Repository via ekstra metadata om dokumenter/dokument-dele
2. Kontrol fra DDS Repository ved anvendelse af standardformat(er)

Betinget mapning til SOR-kode for sundhedspersons organisation

Når data-specifikke samtykker skal kontrolleres ved kald af Samtykkeverifikationsservicen skal sundhedspersonens organisation gives ved dennes kode i SOR-klassifikationen.

Ved kald af DDS Repository er der som beskrevet i [DDS Repository snitflade] mulighed for i HSUID-header at angive sundhedspersonens organisation ved:

• enten ydernummer, SHAK-kode eller SOR-kode
• enten a) ydernummer og tilhørende SOR-kode, eller b) SHAK-kode og tilhørende SOR-kode

Er SOR-koden ikke givet ved kaldet af DDS Repository, foretages mapning til SOR-kode ud fra organisation angivet HSUID-headeren. Den fremfundne SOR-kode tilføjes til HSUID-header brugt ved kaldet til kildesystemet, således at kildesystemet ikke skal foretage mapningen.

Anvendelse af SOAP 1.1 for DDS Repository webservices

TODO: kan denne generaliseres?

Snitfladen for DDS Repository skal indeholde SOAP-headere fra DGWS 1.0.1 og SOAP-header samt SOAP-body med indhold specificeret af IHE XDS.

DGWS 1.0.1 specificerer anvendelse af SOAP 1.1, mens webservices for IHE XDS er baseret på SOAP 1.2.

Det er valgt, at DDS Repository skal udstille services med SOAP 1.1-binding af hensyn til overholdelse af DGWS.

Konsekvensen af valget er, at MTOM-anvendelse sker med SOAP 1.1-binding [MTOM SOAP 1.1] og ikke [MTOM SOAP 1.2].

Angivelse af patient-identifikation i DDS Repository

Både DDS Repository og kildesystemet har behov for at kende identifikation af den borger, der udtrækkes dokumenter om (patient-id). DDS Repository har behovet i kraft af, at denne skal kalde Samtykkeverifikationsservicen, Behandlingsrelationsservicen og MinLogRegistreringsservicen, hvor patient-id er krævet information. Tilsvarende skal kildesystemet kende patient-id, når data-specifikke samtykker kontrolleres ved kald af Samtykkeverifikationsservicen.

Patient-id indgår ikke i den request-struktur, der anvendes ved ITI-43 RetrieveDocumentSet.

Det er valgt, at tilføje en attribut til et enkelt patient-id til HSUID-headeren. Det er dermed anvendersystemets ansvar at specificere det korrekte patient-id. Med RetrieveDocumentSet er det muligt at udtrække dokumenter for flere dokument-id. Support blot for et enkelt patient-id har den konsekvens, at kald af RetrieveDocumentSet kun må anvendes, når alle specificerede dokument-id gælder samme patient. Det påhviler anvendersystemet at sikre, at dette er tilfældet.

Alternative løsninger:

1. ITI-18 opslag på register (foretaget i DDS Repository) ved brug af query’en GetDocuments. Denne er fravalgt grundet øget latens og manglende garanti for succes.
2. Tilføjelse af patient-id til ekstra, specifik header
3. Ved undersøgelse af fremhentede dokument(er). Fravalgt da det ikke er givet, at patient-id kan fremfindes utvetydigt.

Supplerende løsninger til valgte løsning:

1. Kontrol af patient-id ved ITI-18 opslag på register. Fravalgt af samme grunde som ITI-18 opslag beskrevet ovenfor.

Ingen sikring af overensstemmelse mellem angivet patient-id og patient-id i dokumenter

Med RetrieveDocumentSet er det muligt at udtrække dokumenter for flere dokument-id. Som beskrevet i forrige afsnit angives et enkelt patient-id i HSUID-headeren.

Det er valgt, at der ikke foretages kontrol af overensstemmelse mellem patient-id angivet i HSUID-header og patient-id for de dokumenter, der ønskes udtræk af.

Det påhviler anvendersystemet at sikre, at der er overensstemmelse mellem angivne patient-id og patient-id for de dokumenter, der ønskes udtræk af.

Ingen sikring af udtræk for enkelt patient ad gangen

Med RetrieveDocumentSet er det teknisk muligt med et kald at udtrække dokumenter for flere forskellige patienter. Af hensyn til patient-sikkerhed må der dog kun udtrækkes dokumenter for samme patient.

Det er valgt, at der ikke foretages kontrol af, at alle dokumenter, der ønskes udtræk af, vedrører samme patient.

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.

TODO: lav tegning til gliffy

Image Modified

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.

TODO: lav tegning til gliffy

Image Modified

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.

TODO: lav tegning til gliffy

Image Modified

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.

TODO: lav tegning til gliffy (udgangspunkt fra figur i anvenderguide)

Image Modified

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 Modified

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-2b].
• 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.

TODO: lav tegning til gliffy

Image Modified

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

Invoker med implicit DGWSConsumer-anvendelse

Når der laves kald af ConsentVerificationServiceInvoker, MinLogRegistrationInvoker og TreatmentRelationInvoker genanvendes det indkommende ID-kort anvendt ved dokumentanvenders kald af DDS. Der skabes en kopi af indkommende Medcom-header, dog med nyt MessageId.

Ved kald til samtykkeverifikationsservicen, der i tilgift forventer en HSUID-header, genbruges HSUID-headeren fra DDS Registry-opslaget.

TODO kan de skrives sammen? Nedenståend og ovenstående -----------

Fra repository dokumentet:

For ConsentVerificationServiceInvoker, MinLogRegistrationInvoker og TreatmentRelationInvoker anvendes serviceklienter, der arver fra SosiService. Derved får de ved instantiering automatisk en DGWSConsumer-instans og altså også cached ID-kort-håndtering. Når der laves kald af disse services bliver et ID-kort, der stadig er gyldigt, genbrugt fra tidligere kald, og om nødvendigt bliver nyt ID-kort indhentet automatisk fra STS.

Ved de tre invokere’s kald af operationer på hhv. samtykkeverifikationsservicen, MinLogRegistration-servicen og behandlingsrelationsservicen benyttes DGWSConsumer til at skabe de nødvendige DGWS-headere (Medcom- og sikkerhedsheader).

Ved kald til hhv. samtykkeverifikationsservicen og MinLogRegistration-servicen, der begge i tilgift forventer en HSUID-header, genbruges HSUID-headeren modtaget med kaldet af DDS Repository.

Invoker uden DGWSConsumer eller STS-anvendelse

DocumentRegistryInvoker henholdsvis DocumentRetrieveInvoker er specielle derved, at IHE Registry ikke overholder DGWS og derfor ikke kræver ID-kort indhentet fra STS for at kunne kaldes.

ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.

TODO figur i respository afsnit 4.3.2 skal den med?

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.

Integration og test

Integrationsstrategi

Der er ikke nogen specifik rækkefølge hvori DDS Registry og Repository og de services, den kalder, skal integreres.

I kraft af dens fejlhåndtering kan opslag gennemføres når blot datasources, servicen til IHE Registry, et kildesystems ITI-43-snitflade og samtykkeverifikationsservicen er tilgængelige.

For succesfuld gennemførelse af integrationstests skal alle services, DDS er afhængig af dog være tilgængelige.

For en beskrivelse af byggeprocessen og eksterne/interne afhængigheder for servicen, se [DDS udvikling].

Unit test og Integrationstests

Se testvejledningen for detaljer omkring dette [DDS Test]