Page History
...
- 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. Dette kan parameterstyres, se driftvejledning.
- Ikke-autoriseret bruger
- hsuid OrganizationId valideres mod Sores, hvis organizationIdSource er SOR. Dette kan parameterstyres, se driftvejledning.
- Den endelige brugertype må ikke være af typen System
...
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.
Udover ovenstående logges også eventuelle fejl fundet af ihe valideringen i request eller response for ITI-18 og ITI-43. Denne validering/logning foretages kun hvis valideringen er aktiveret (se detaljer i driftsvejledningen)
Statisk konfiguration i propertyfil
...
For opsætning se driftvejledningen.
Anvendelse af IHE framework
Oprindelig blev DDS lavet med egen implementation af IHE snitfladerne og kode genering af disse - noget komplekse strukturer. Siden er dette lagt om til anvendelse af maven dependency org.openehealth.ipf.commons/ipf-commons-ihe-xds. Dette muliggør både at arbejde med en noget mindre kompleks/abstrakt java model samt introduktion af standard IHE validering af request og responses. For sidstnævnte se detaljer i driftsvejledningen, hvor konfiguration af denne er beskrevet.
Arkitekturdesign
Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.
...
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.
Figur 3a: Implementationen af webservice-interfaces
...
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.
Figur 4a DDSRegistryQueryLogic får dependency injected et antal delegates, der varetager kald til de forskellige services.
...
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.
Figur 5a UML Sekvensdiagram for DDSRegistryQueryLogic
...
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.
Figur 4b DDSRetrieveDocumentLogic får dependency injected et antal delegates, der varetager kald til de forskellige services.
...
I Figur 5b er vist et sekvensdiagram for DDSRepository.
Figur 5b Sekvensdiagram for DDSRetrieveDocumentLogic
...
| 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 variantvarianter
| Validering af forespørgsel | ITI18 ITI43 | Fast defineret i Aktørmodelleringen (ServiceActorProvider) i servicen | SoapFault med fejlbeskeden
| Se DDS - Brugerhistorier | |
| DDK11 Aktør søge parameter validering: | |||||||
| At begrænse specifikke brugertyper fra specifikke søge værdier. | CitizenOnBehalfOf variant
| 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:
For Fuldmagt gælder yderligere:
| SoapFault, med en af følgende fejlbeskeder:
| 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:
| 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:
| Hvis filtrering giver en tom liste af registries så SoapFault med fejlbeskeden
| 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:
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:
Hvis filtrering giver en tom liste af registries så SoapFault med fejlbeskeden
| 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:
| 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: securityContext.getOrganisation().get().getIdentifier(), hvis formatet er CVR 2025-07-02: ikke merget ind på main branch i skrivende stund | Fejl i almindelig response med fejlbeskeden:
| 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:
| 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:
| 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:
| Afventer afklaring | |
...