Introduktion

Formål

Vejledning til installation og konfiguration af DDS Registry og Repository.

Afsnit 2 (Krav til miljø) indeholder servicekrav til det omliggende miljø, herunder krav til operativsystem og standardapplikationer, som f.eks. applikationsservere, databaseservere, Java og/eller .Net versioner mm., angivet på version og service pack niveau.

Afsnittene 3 (Oprettelse/konfiguration af databaser og tabeller) og 4.4 (Konfiguration af datasources)  indeholder information om konfiguration af databasen, herunder oprettelse af databaseskemaer.

Afsnit 4 (Deployment) beskriver hvorledes services deployeres, herunder om der er krav om evt. genstart af server eller andre applikationer. Ved opgradering af komponenten beskrives desuden tilstanden, systemet skal være i for at opgraderingen kan finde sted, f.eks. om applikationsserver og/eller databaseserver skal være stoppet.

Læsevejledning

Læseren forventes at have kendskab til National Sundheds-IT’s platform NSP, samt generelt kendskab til WildFly applikation server, MySQL, samt Ubuntu Linux operativ system.

Dokumentet beskriver ikke forhold der berører konfiguration på DoDi, NSP eller centrale ’NSP-lignende miljøer’ eller etablering og konfiguration af distribution af data fra DoDi til øvrige platforme.

Dokumenthistorik

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

Definitioner og referencer

Krav til miljø

Krav til applikationsservere

Komponenterne er udviklet og testet i Docker ved anvendelse af et base-image for NSP platformen.

Komponenternes konfiguration er således tilpasset deployering på WildFly 8.2 applikationsservere med OpenJDK 8.

Krav til operativsystem

Der stilles ingen krav til operativsystemet udover, at det skal være Linux, og docker skal være installeret.

Krav til database

Komponenterne er testet mod MariaDB version 10.3.

Krav til adgang til andre services

DDS Registry

DDS Registry 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.

Behandlingsrelation (BRS): BRS giver mulighed for at forespørge om en given sundhedsperson har en behandlingsrelation til en given borger. Aktivering af kald er konfigurerbart via properties-filen for DDS Registry.

Samtykkeverifikation: Samtykkeverifikationsservicen kaldes for at filtrere de dokumenter fra, som sundhedspersonen ikke har samtykke til at se. Listen af dokumenter fremsøges i DDS-document registry. Filtreringen er baseret på de positive/negative samtykker borgeren har oprettet.

MinLogRegistration: En sundhedspersons 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:

DDS-documentregistry: DDS documentregistry indeholder metadata på dokumenter om borgeres sundhedsoplysninger.

STS: STS anvendes til at trække Sosi idkort på baggrund af DDS Registrys funktionscertifikat. Dette idkort anvendes i kald til BRS, Samtykkeverifikation samt MinLogRegistration.

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.

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.

Behandlingsrelation (BRS): BRS giver mulighed for at forespørge om en given sundhedsperson har en behandlingsrelation til en given borger. Aktivering af kald er konfigurerbart via properties-filen for DDS Repository.

Samtykkeverifikation: Samtykkeverifikationsservicen kaldes for at filtrere de dokumenter fra, som sundhedspersonen ikke har samtykke til at se. Listen af dokumenter fremsøges i DDS-document registry. Filtreringen er baseret på de positive/negative samtykker borgeren har oprettet.

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

STS: STS anvendes til at trække Sosi idkort på baggrund af DDS Repositorys funktionscertifikat. Dette idkort anvendes i kald til BRS, Samtykkeverifikation samt MinLogRegistration.

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.

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 og Repository foretager også registrering af data via andre services.

Krav til hardware

DDS Registry og Repository ressourceforbrug vil afhænge af flere parametre

• Mængden data, antallet af dokumenter og størrelsen af dokumenter i det enkelte opslag
• Antallet af opslag

Oprettelse/konfiguration af databaser og tabeller

Følgende databasekomponenter er tilknyttet servicen:

whitelist: whitelist der indeholder godkendte CVR numre, som skal have adgang til servicen.
 Alle CVR-numre i databasen, der skal gælde for DDS skal have service key, der matcher komponenten:

• DDS Registry, skal have ’service key’ sat til ’dk.nsi.ddsregistry’.
• DDS Repository, skal have 'service key' sat til 'dk.nsi.ddsrepository'

autorisation: Anvender stamdata-tabellen autreg, der indeholder CPR-nummer og autorisationsnummer for sundhedspersoner med gyldige og gældende dansk autorisation opført i Sundhedsstyrelsens autorisationsregister.

sor: Mapning mellem SOR-koder og SHAK-koder/ydernumre, som anvendes til opslag i forbindelse med samtykkeverifikationer.

documentsources:

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

For DDS Repository:

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

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.

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.

• 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 have de nødvendige privileges til documentsource databasen.

Deployment

Dette afsnit beskriver hvordan komponenten deployes.

Jenkins

DDS bygges med NSP's Jenkins server via følgende jobs:

• DDS_build - Bygger koden (sker automatisk ved commits)
• DDS_push_snapshot - Pusher det nyeste snapshot image til NSP Docker Registry

NSP er selv ansvarlige for at pushe release versioner af DDS til NSP Docker Registry gennem Jenkins.

Docker

DDS består af to docker images som pushes til NSP Docker Registry under navnene:

• registry.nspop.dk/components/dds/ddsregistry:snapshot

• registry.nspop.dk/components/dds/ddsrepository:snapshot
  
  

Docker-compose

DDS leveres samtidig som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/svn/components/dds/trunk/compose.

For release x.y.z af BivWSP findes Docker Compose filerne i folderen https://svn.nspop.dk/svn/components/dds/tags/release-x.y.z/compose

Compose folderen indeholder 5 underfoldere:

Konfiguration af datasources

Under configuration/datasources findes en række datasources, som volume-mappes ind i komponenten. Disse skal konfigureres inden opstart.

Konfiguration af adgang til stamdata-databasen sker i auth-ds.xml, adgang til whitelist-databasen i whitelist-wildfly-ds.xml, adgang til SOR-databasen i sor-ds.xml, adgang til CRA-databasen i crasts-ds.xml, mens adgang til Data sources konfigureres i documentsources-ds.xml.

Konfiguration af properties

Al konfiguration foregår ved redigering af de relevante properties filer, som ligger under compose/configuration. Disse filer volume-mappes ind i komponenten. Ved konfigurationsændringer bør servicen genstartes.

Indholdet af de enkelte konfigurationsfiler, er beskrevet og forklaret i [Driftsvejledning].

Konfiguration af managed executor service

DDS bruger en managed executor service til at foretage samtidige kald af eksterne services, hvilket gælder både interne NSP services (minlog, samtykke osv.) og andre registre.

DDS bruger sin egen instans af en managed executor service, som opsættes automatisk når docker-imaget bygges. For yderligere beskrivelse af parametrene for managed executor services henvises til JBoss dokumentationen (https://docs.jboss.org/author/display/WFLY8/EE+Subsystem+Configuration).

Konfiguration af NSP SLA log

NSP-util anvendes som en del af servicen og skal konfigureres. Eksempel på konfiguration fil findes i

for DDS registry

For DDS repository:

Whitelisting af services

Adgang til DDS styres på CVR-niveau via konfigurationen i whitelist.whitelist_config tabellen. Se også afsnit 3.1.

Konfiguration af DKS

Konfigurationsfil til det svar, DDS returnerer ved forespørgsel mod dens DKS-snitflade opsættes ved tilpasse:

For DDS registry:

For DDS repository:

Start/genstart af service

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

Kald til DDS Registry, hvor værdispringsreglen anvendes, logges til log filen: 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

Kald til DDS Repository, hvor værdispringsreglen anvendes, logges til log filen: 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.

Afinstallation af servicen

Oprydning i MySQL database:

For DDS registry:

For DDS repository:

Fjern eventuelt lo

Fjern eventuelt logfiler