Versions Compared

Old Version 6

changes.mady.by.user Lene Andersen

Saved on

compared with

New Version Current

changes.mady.by.user Lene Andersen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Navitabs
rootDokumentdelingsservice (DDS)
firsttabDokumentdelingsservice (DDS)
includeroottrue


Table of Contents
maxLevel3

Introduktion

Formål

Vejledning til installation og konfiguration af DDS Registry og Repository.

...

Dokumentet er oprettet med udgangspunkt i 2 seperate separate installationsvejledninger for registry henholdsvis repository. Den videre redigeringshistorik efter dette tidspunkt fremgår af confluence "Page History".

...

MinLogRegistration: En sundhedspersons eller anden borgers adgang, eller forsøg på adgang, til borgers oplysninger via DDS Registry, registreres i MinLogRegistration-servicen.
Følgende service skal blot kunne tilgås fra DDS Registry, men kræver ikke at DDS Registry er på whiteliste:

...

PersonInformation: PersonInformation rest servicen anvendes ved søgning udført af en Borger . Den anvndes anvendes til at tjekke om en Borger har en relation til den borger han søger på vegne af.

Sores: Sores rest servicen anvendes ved søgning udført af en bruger, der ikke er en borger. Den anvendes til at tjekke om en given SOR kode i hsuid headeren findes.

DDS Repository

DDS Repository kalder følgende services og skal være godkendt på whiteliste til at kalde disse services. Disse services kan være installeret lokalt på NSP eller eksternt.

...

MinLogRegistration: En sundhedspersons eller anden borgers adgang, eller forsøg på adgang, til borgers oplysninger via DDS Repository, registreres i MinLogRegistration-servicen.

...

PersonInformation: PersonInformation rest servicen anvendes ved søgning udført af en Borger . Den anvndes til at tjekke om en Borger har en relation til den borger han søger på vegne af.

Sores: Sores rest servicen anvendes ved søgning udført af en bruger, der ikke er en borger. Den anvendes til at tjekke om en given SOR kode i hsuid headeren findes.

Krav til datahåndtering

DDS Registry og Reposiotry foretager udelukkende opslag af data via andre services. De gemmer ikke disse data og dokumenter, men sender dem direkte videre til kalderen.

...

  • DDS registry: I tabellen documentregistry er der konfiguration af hvilke dokument-indeks, der anvendes af registry servicen.
  • DDS repository: Mapning mellem angivet OID i udtræk til aktuelt service endpoint for XDS dokument kilde

I folderen  compose/database ligger sql-scripts, som kan anvendes til at initialisere disse databaser. Script-filerne er præfikset med et løbenummer, som angiver den rækkefølge de skal køres i. Bemærk at nogle scripts indsætter testdata, disse må udelukkende anvendes i testmiljøer.

Oprettelse af whitelist

I testkonfiguration kan whitelist-databasen opdateres med SQL insert.

For DDS Registry:

INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsregistry', '', 'some-cvr-number-here' );

dokumenttype konfiguration: anvendes til for hvert registry at konfigurere, hvilke dokumenttyper (typecode og typescheme) der er relevante. Hermed vil kun disse blive kald når dokumenttypen indgår i en søgning

feature_configuration: anvendes til for hvert registry at angive, hvilken feature det stiller til rådighed. Pt kan feature være querytyperne man anvender i forbindelse med iti-18 kald. Som f.eks. get documents og find documents.

whitelist_config_documentmetadata*: de 4 tabeller anvendes til at opsætte whiteliste filtrering baseret på metadata af, hvad en given anvender må få retur fra servicen.

I folderen  compose/database ligger sql-scripts, som kan anvendes til at initialisere disse databaser. Script-filerne er præfikset med et løbenummer, som angiver den rækkefølge de skal køres i. Bemærk at nogle scripts indsætter testdata, disse må udelukkende anvendes i testmiljøer.

Oprettelse af whitelist

I testkonfiguration kan whitelist-databasen opdateres med SQL insert.

For DDS RegistryFor DDS Repository:

INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsrepositoryddsregistry', '', 'some-cvr-number-here' );

For DDS Repository:

INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsrepository', '', 'some-cvr-number-here' );

I testsetup skal brugeren I testsetup skal brugeren whitelistuser/password have de nødvendige privilegier til whitelist databasen.

Oprettelse

...

af dokumenttype konfiguration af registry

I testkonfiguration kan dokumenttype databasen opdateres med SQL insert.

INSERT INTO documentsources.documenttype_configuration (documentregistryid, typecode_codename, typecode_schemename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"),  "39289-4", "2.16.840.1.113883.6.1");

Hvis ikke man har angivet en unik documentregistryfriendlyname værdi i documentregistry, må man manuelt finde det givne documentregistryid man ønsker at konfigurere en dokumenttype for.

Hvis et givet documentregistry ikke har en opsætning i documenttype_configuration tabellen, er alle dokumenttyper tilladte.

Konfigurationen indlæses automatisk peridisk, som angivet i property documenttype.configuration.refresh.duration.

Når en post slettes fra documentregistry, slettes de relaterede poster i documenttype_configuration automatisk.

Oprettelse af feature konfiguration af registry

Feature databasen kan opdateres med SQL insert. Den angiver, hvilke features, en given registry backend understøtter. 

INSERT INTO documentsources.feature_configuration (documentregistryid, featurename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"),  "GET_DOCUMENTS_QRY");
INSERT INTO documentsources.feature_configuration (documentregistryid, featurename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"),  "FIND_DOCUMENTS_QRY");
INSERT INTO documentsources.feature_configuration (documentregistryid, featurename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"),  "FIND_DOCUMENTS_BY_REFERENCE_QRY");

Hvis ikke man har angivet en unik documentregistryfriendlyname værdi i documentregistry, må man manuelt finde det givne documentregistryid man ønsker at konfigurere en feature for.

Hvis et givet documentregistry ikke har en opsætning i feature_configuration tabellen, anvendes det givne registry ikke når denne feature er i spil.

Konfigurationen indlæses automatisk peridisk, som angivet i property feature.configuration.refresh.duration.

Når en post slettes fra documentregistry, slettes de relaterede poster i feature_configuration automatisk.

Oprettelse af metadata konfiguration af dokument filtrering

For at konfigurere, hvordan dokumenternes metadata skal filtreres for den sundhedsfaglige, skal det konfigureres manuelt af driften i en række whitelist tabeller i databasen:

insert into whitelist.whitelist_config_documentmetadata (cvr, system_name) values ('12345602', 'Service Consumer Test');


insert into whitelist.whitelist_config_documentmetadata_typecode (whitelist_id, typecode_codename, typecode_schemename) 
values ( (select id from whitelist.whitelist_config_documentmetadata where cvr = '12345602' and system_name = 'Service Consumer Test'), '39289-4', '2.16.840.1.113883.6.1');

insert into whitelist.whitelist_config_documentmetadata_eventcode (whitelist_id, eventcode_name, eventcode_schemename)
values ( (select id from whitelist.whitelist_config_documentmetadata where cvr = '12345602' and system_name = 'Service Consumer Test'), 'eventCode1', '1.2.208.176.2.1');

insert into whitelist.whitelist_config_documentmetadata_practicesettingcode (whitelist_id, practicesettingcode_codename, practicesettingcode_schemename)
values ( (select id from whitelist.whitelist_config_documentmetadata where cvr = '12345602' and system_name = 'Service Consumer Test'), '408443003', '2.16.840.1.113883.6.96'); 



Ovenstående er eksempler på sql. Udskift værdierne med relevante værdier for at aktuelle miljø.

Som minimum skal der åbnes op for typecode i whitelist_config_documentmetadata_typecode tabellen. Derudover kan dokumenter returnering indsnævres ved yderligere at angive eventcode og practicesettingcode. Er der for et cvr/system angivet bare een værdi for eventcode, skal dokumentes metadata indeholde denne kode. Tilsvarerende for practicesettingcode. Ellers filtreres metadata fra, og anvenderen får en fejl i svaret.

Der filtreres kun, hvis funktionaliteten er aktiveret. Den kan slåes fra med property whitelisted.document.metadata.active.

Konfigurationen indlæses automatisk  peridisk, som angivet i property whitelisted.document.metadata.refresh.duration.

Actor Query Parameter validering konfiguration

Nogle actors har ikke love til at lave søgninger (ITI-18) på alle værdier i query parametrene. Dette konfigureret i manuelt af driften i en tabel i databasen.



INSERT INTO documentsources.actor_query_parameter_configuration (actor_query_type, typecode_codename, typecode_schemename, formatcode_codename, formatcode_schemename, privilege)

VALUES ("CitizenUserOnBehalfAsProxyHolder","39289-4", "2.16.840.1.113883.6.1", "urn:ad:dk:medcom:apd-v2.0.1:full", "1.2.208.184.100.10", "urn:dk:nspop:sts:dds:read");

INSERT INTO documentsources.actor_query_parameter_configuration (actor_query_type, typecode_codename, typecode_schemename, formatcode_codename, formatcode_schemename, privilege)

VALUES ("CitizenUserOnBehalfAsChildCustodyHolder","39289-4", "2.16.840.1.113883.6.1", null, null, null);

Ovenstående er eksempler på sql. Udskift værdierne med relevante værdier for at aktuelle miljø og anvendere.

For nuværende drejer det sig om følgende brugertyper og de skal konfigureres på følgende måde:

  • Borger med fuldmagt vha. fuldmagtsstrenge og konfiguration for åbning at tilladelse til fremsøgning indsættes i databasen med
    • actor_query_type: skal være CitizenUserOnBehalfAsProxyHolder
    • typecode_codename og typecode_schemename: typecode som reglen gælder for, begge felter skal udfyldes.
    • formatcode_codename og formatcode_schemename: hvis der er krav til formatcode udfyldes begge felter. Blanke felter betyder alle format codes tillades
    • privilege: angiv det fuldmagtsprivilege som borgeren skal have får at måtte fremsøge på typecode og formatcode angivet.
  • Borger med forældremyndighed og konfiguration for åbning at tilladelse til fremsøgning indsættes i databasen med
    • actor_query_type: skal være CitizenUserOnBehalfAsChildCustodyHolder
    • typecode_codename og typecode_schemename: typecode som reglen gælder for, begge felter skal udfyldes.
    • formatcode_codename og formatcode_schemename: hvis der er krav til formatcode udfyldes begge felter. Blanke felter betyder alle format codes tillades
    • privilege: angives ikke for forældremyndighed

Oprettelse af adgang til data i autorisationsregister

DDS Registry og Repository anvender opslag i autorisations register data, der skal være tilgængeligt i stamdata i følgende tabel:

  • autreg

Test note:

I testsetup skal brugeren stamdatauser/password have læse adgang til autreg tabellen i stamdata.

Oprettelse af adgang til SOR-registerdata

DDS Registry og Repository anvender SOR data, der skal være tilgængeligt i stamdata i følgende tabeller:

  • SORRelationer
  • SORYderSHAKRelationer

Indlæsning og synkronisering af SOR databasen sker fra central NSP komponent.


Test note:

Note: I test setup skal brugeren stamdatauser/password have læseadgang til SOR tabellerne i stamdata.

Oprettelse af documentsources skema

Brugeren identificeret i data source-filen (dsuser/password) skal have de nødvendige privileges til documentsource databasen.

DDS registry

Documentsource-databasens documentregistry-tabel opdateres med SQL insert for configuration af et lokalt dokument-indeks.

INSERT INTO documentsource.documentregistry (documentregistryserviceurl, documentregistryfriendlyname, documentregistryservicenamespace, documentregistrylocal, documentregistryservicename) VALUES (' http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls', 'DDS', 'urn:ihe:iti:xds-b:2007', true, '300000', true, 'DocumentRegistry_Service');  

Adressen for indeksets webservice-endpoint er her givet ved http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls, hvilket skal tilpasses konkret placering. Se [Driftsvejledning] for betydning af øvrige kolonner.

DDS repository

Test note:
I testkonfiguration kan documentsource-databasen opdateres med SQL insert.

INSERT INTO `documentsource` (`oid`, `type`, `service_endpoint`, `soap_version`, `timeout`)
VALUES ('{*}some_unique_id{*}','\[{*}unique_id_type\]{*}','{*}some_endpoint{*}','\[{*}SOAP_version{*}\]',\[{*}timeout{*}\]);


  • oid: OID værdien som for den pågældende XDS dokument kilde, som kan være at typen 'repository_unique_id' eller 'home_community_id'
  • type: Angiver hvilken typen af OID der er angivet, og den skal have én af følgende værdier:

[‘repository_unique_id’|’home_community_id’]

  • service_endpoint: Angiver URL til XDS dokument kilde
  • timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.
  • soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:

[’1.1’|’1.2’]

Kombinationen af *oid* og *unique_id_type* skal være unik.
I testsetup skal brugeren dsuser/password

DDS Registry og Repository anvender opslag i autorisations register data, der skal være tilgængeligt i stamdata i følgende tabel:

  • autreg

Test note:

I testsetup skal brugeren stamdatauser/password have læse adgang til autreg tabellen i stamdata.

Oprettelse af adgang til SOR-registerdata

DDS Registry og Repository anvender SOR data, der skal være tilgængeligt i stamdata i følgende tabeller:

  • SORRelationer
  • SORYderSHAKRelationer

Indlæsning og synkronisering af SOR databasen sker fra central NSP komponent.

...

Note: I test setup skal brugeren stamdatauser/password have læseadgang til SOR tabellerne i stamdata.

Oprettelse af documentsources skema

Brugeren identificeret i data source-filen (dsuser/password) skal have de nødvendige privileges til documentsource databasen.

DDS registry

Documentsource-databasens documentregistry-tabel opdateres med SQL insert for configuration af et lokalt dokument-indeks.

INSERT INTO documentsource.documentregistry (documentregistryserviceurl, documentregistryfriendlyname, documentregistryservicenamespace, documentregistrylocal, documentregistryservicename) VALUES (' http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls', 'DDS', 'urn:ihe:iti:xds-b:2007', true, '300000', true, 'DocumentRegistry_Service');  

Adressen for indeksets webservice-endpoint er her givet ved http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls, hvilket skal tilpasses konkret placering. Se [Driftsvejledning] for betydning af øvrige kolonner.

DDS repository

Test note:
I testkonfiguration kan documentsource-databasen opdateres med SQL insert.

INSERT INTO `documentsource` (`oid`, `type`, `service_endpoint`, `soap_version`, `timeout`)
VALUES ('{*}some_unique_id{*}','\[{*}unique_id_type\]{*}','{*}some_endpoint{*}','\[{*}SOAP_version{*}\]',\[{*}timeout{*}\]);

  • oid: OID værdien som for den pågældende XDS dokument kilde, som kan være at typen 'repository_unique_id' eller 'home_community_id'
  • type: Angiver hvilken typen af OID der er angivet, og den skal have én af følgende værdier:

[‘repository_unique_id’|’home_community_id’]

  • service_endpoint: Angiver URL til XDS dokument kilde
  • timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.
  • soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:

[’1.1’|’1.2’]

Oprettelse af Minlog Tekst konfiguration ved søgning (iti-18)

Hvis man ønsker at anvende en mere detaljeret opsætning af tekster, der sendes til minlog, gøres det ved at manuelt at indsætte records i tabellerne minlog_text og minlog_usertype_text. Findes der ikke matchende data heri anvendes de default værdier, der er sat op i servicens property fil.


INSERT INTO minlog_text (typecode_codename, typecode_schemename, formatcode_codename, formatcode_schemename, classcode_codename, classcode_schemename, text) VALUES ('11502-2', '2.16.840.1.113883.6.1', 'urn:ad:dk:medcom:labreports:svareksponeringsservice', '1.2.208.184.100.10', '001', '1.2.208.184.100.9', 'Opslag på labsvar  fra %s');

INSERT INTO minlog_usertype_text (usertype, text) VALUES ('professionalUser', 'sundhedsfaglig');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('professionalUserConsentOverride', 'Sundhedsfaglig hvor samtykker tilsidesættes');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('childCustodyHolder', 'forældremyndighedsindehaver');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('proxyHolder', 'fuldmagtshaver');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('citizen', 'borger');

For minlog_usertype_text skal de angivne usertype anvendes, da disse er kendt af komponenten.

En match ved søgning sker ved at kigge på typecode, classcode og formatcode fra requestet samt anvender rollen og med disse slå op i tabellerne. For en mere detaljeret beskrivelse af denne logik se dds design og arkitektur dokumentet.

Ved hentning af dokumenter (iti-43) anvendes altid værdierne fra property filenKombinationen af *oid* og *unique_id_type* skal være unik.
I testsetup skal brugeren dsuser/password have de nødvendige privileges til documentsource databasen.

Deployment

Dette afsnit beskriver hvordan komponenten deployes.

...

DDS Registry og Repository startes og stoppes med Docker Compose kommandoer.

Logfiler

DDS Registry og Repository kan logge kald til følgende logs: En NSP-SLA-log, en audit-log, en applikations log og en performance log.

I default opsætningen logges der udelukkende fejl til applikationsloggen.

Der er mulighed for at tilkoble en perfomance log, der logger tidsmåling af DDS kald til eksterne services.

Alle logs er beskrevet i driftsvejledningen.

DDS registry

nsputil-sla-ddsregistry.log
dds-audit.log
ddsregistry.log
ddsregistry-performance.log

Kald til DDS Registry, hvor værdispringsreglen anvendes, logges til log filen: ddsregistry-consentoverride.log

ddsregistry-consentoverride.log

Det er muligt at konfigurere placeringen af filerne, samt hvilket niveau de logger på, ved at redigere i ddsregistry.log4j.properties.

DDS repository

.

Logfiler

DDS Registry og Repository kan logge kald til følgende logs: En NSP-SLA-log, en audit-log, en applikations log og en performance log.

I default opsætningen logges der udelukkende fejl til applikationsloggen.

Der er mulighed for at tilkoble en perfomance log, der logger tidsmåling af DDS kald til eksterne services.

Alle logs er beskrevet i driftsvejledningen.

DDS registry

nsputil-sla-ddsregistry.log
dds-audit.log
ddsregistry.log
ddsregistrynsputil-sla-ddsrepository.log
ddsrepository-audit.log
ddsrepository.log
ddsrepository-performance.log

Kald til DDS RepositoryRegistry, hvor værdispringsreglen anvendes, logges til log filen: ddsrepositoryddsregistry-consentoverride.log

ddsrepositoryddsregistry-consentoverride.log

Det er muligt at konfigurere placeringen af filerne, samt hvilket niveau de logger på, ved at redigere i ddsrepository.log4j.properties.

Opgradering af komponenter

Når der kommer opgraderinger til en komponent, vil der medfølge en releasenote, der beskriver hvad opgraderingen består af, samt hvilke handlinger der er nødvendige for at opgradere den deployede komponent.

Afinstallation af servicen

Oprydning i MySQL database:

For DDS registry:

Whiteliste:
DELETE FROM whitelist.whitelist_config 
 WHERE service = 'dk.nsi.ddsregistry'

For DDS repository:

Whiteliste:
DELETE FROM whitelist.whitelist_config WHERE service = 'dk.nsi.ddsrepository'
Documentsources:
DROP SCHEMA documentsources;

logger på, ved at redigere i ddsregistry.log4j.properties.

DDS repository

nsputil-sla-ddsrepository.log
ddsrepository-audit.log
ddsrepository.log
ddsrepository-performance.log

Kald til DDS Repository, hvor værdispringsreglen anvendes, logges til log filen: ddsrepository-consentoverride.log

ddsrepository-consentoverride.log

Det er muligt at konfigurere placeringen af filerne, samt hvilket niveau de logger på, ved at redigere i ddsrepository.log4j.properties.

Opgradering af komponenter

Når der kommer opgraderinger til en komponent, vil der medfølge en releasenote, der beskriver hvad opgraderingen består af, samt hvilke handlinger der er nødvendige for at opgradere den deployede komponent.Fjern eventuelt loFjern eventuelt logfiler