Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.
Driftsvejledningen indeholder information om DDS Registry med hensyn til eksterne afhængigheder, standard placering af logfiler og konfigurationsfiler, og evt. krav til genstart af applikationer hvis komponenten ikke er responsiv.
I afsnit 2 er beskrevet hvilke komponenter, der indgår i DDS Registry og deres forventede placering med hensyn til platform.
Afsnit 4 beskriver aktuelle konfigurationsparametre for DDS Registry, samt eksempler på konfigurationsparameter-filer.
Afsnit 5.1, 5.2 og 5.3 beskriver hvorledes DDS Registry komponenterne overvåges.
I afsnit 5.4 er DDS Registry-relaterede logfiler beskrevet, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning.
Beskrivelse af standard fejlsøgning og start/stop vejledning for komponenterne er beskrevet i afsnit 6.
Specielle krav til backup er beskrevet i afsnit 7, ligesom procedure ved reetablering af komponenten ud fra backup beskrives.
Læseren forventes at have kendskab til National Sundheds-IT’s platform NSP, samt generelt kendskab til WildFly applikationsserver, MySQL, samt Ubuntu Linux operativ system.
Dette dokument er oprettet med udgangspunkt i dokumentet OHB0003 Driftsvejledning DDS Registry.docx
Definition | Beskrivelse |
---|---|
DCC | Dekoblingskomponenten på NSP |
DDS | Dokumentdelingsservice |
DKS | DCC Konfigurations Service |
ITI | IT Infrastructure, fra Integrating the Healthcare Enterprise (IHE). |
NSI | National Sundheds-IT |
NSP | Den nationale service platform (inden for sundheds-IT) |
SHAK | Sygehusafdelingsklassifikation |
SOR | Sundhedsvæsenets organisationsregister |
STS | Security Token Service |
AP | Almen praksis |
Alias | Beskrivelse |
---|---|
DKS-beskrivelse | https://www.nspop.dk/display/web/DKS+--+DCC+Konfiguration+Service, hentet 02.09.2016. |
Dette dokument dækker følgende komponenter på NSP:
DDS Registry komponenten anvender desuden ConsentVerification-servicen, MinLog Registration-servicen, Behandlingsrelationsservicen, STS’en samt HealthShare Document Registry servicen.
Dette afsnit beskriver den daglige drift af systemet.
DDS Registry afhænger af tilstedeværelsen af en række andre services, og ved fejl i disse vil DDS Registry fejle tilsvarende. Disse services er:
Desuden er DDS Registry afhængig af følgende services, hvor fejl ikke bevirker fejl af DDS Registry:
DDS Registry logger brug af værdispring til consent override loggen (ddsregistry-consentoverride.log). Denne skal kunne indsamles og der skal foretages opfølgning på indholdet af dette. Den skal derfor være tilgængelig for indsamling, og må ikke fjernes andet end i denne forbindelse.
Tjek for postive samtykke for AP bliver automatisk aktiveret, hvis enten property ap.assigning.authorities.filename eller ap.patient.consent.filename er angivet i DDSRegistry.properties.
Hvis man ønsker at aktivere eller de-aktivere tjek for postitiv samtykke, så kræver det ændring af DDSRegistry.properties og genstart af Wildfly.
For AP samtykke konfigurationsfilerne gælder følgende:
Filen der indeholder listen af AP er angivet ved property ap.assigning.authorities.filename.
AP angives som følgende:
ORGANISATION_TYPE=ORGANISATION_ID
Ved flere identifikationer af samme AP, så kan det angives som følgende:
ORGANISATION_TYPE=ORGANISATION_ID[,ORGANISATION_TYPE=ORGANISATION_ID]*
Følgende ORGANISATION_TYPE er tilladte i filen:
Eksempel på indhold i fil med liste over AP:
# #/pack/wildfly8/modules/nsi/ddsregistry/config/main/ap_authorities.txt -> /ddsregistry/war/src/test/conf/ap_authorities.txt # # Flere koder SOR=123123123123,Yder=987987 # En kode SHAK=456456 # Flere koder Yder=789789,Yder=890890 |
Eksempler på linier der godtages:
SOR=1234 Yder=1234 Yder=1234,Yder=2345 |
Eksempler på liner der ikke accepteres:
SOR =1234 YDER=1234 YDER=1234 , SOR=1234 |
Filen der indeholder listen af patienter, der har givet postitiv samtykke til AP, er angivet ved property ap.patient.consent.filename
Samtykket er angivet som følgende:
PATIENT_ID:ORGANISATION_TYPE=ORGANISATION_ID
PATIENT_ID godtages kun, hvis det er et tal.
ORGANISATION_TYPE=ORGANISATION_ID følger samme format, som beskrevet i afsnit "Liste af medvirkende AP".
Ved samtykke til AP med der kan identifiseres med flere koder, så behøves kun samtykke til en af koderne i konfigurationen.
Eksempel på indhold i fil med liste over samtykker:
# #/pack/wildfly8/modules/nsi/ddsregistry/config/main/ap_patients.txt -> /ddsregistry/war/src/test/conf/ap_patients.txt # # 0101010101 giver samtykke til SOR=123123123123 og Yder=987987 0101010101:SOR=123123123123 # 0202020202 giver samtykke til SHAK=456456 0202020202:SHAK=456456 # 0303030303 giver samtykke til Yder=789789 og Yder=890890 0303030303:Yder=890890 |
Hvis der er ændringer til konfigurationsfilerne for samtykke til AP, så kan de genindlæses ved at kalde følgende url:
<serverurl>/ddsregistry/refreshApConsentService
Der kan sættes et eksternt job op (f.eks. cron job, der kalder dette endpoint), hvis man vil genindlæse filerne på bestemte tidspunkter.
Tjek for adgang via Trust for ikke-autoriserede sundhedspersoner bliver aktiveret, hvis property trusted.roles.filename er angivet i DDSRegistry.properties.
Hvis man ønsker at aktivere eller de-aktivere tjekket, så kræver det ændring af DDSRegistry.properties og genstart af Wildfly.
For Trust konfigurationsfilerne gælder følgende:
Filen der indeholder listen af roller, som en ikke autoriseret sundhedsperson kan få adgang til DDS med, er angivet ved property trusted.roles.filename.
Trust rollen er angive som følgende:
ROLLETEKST¤ROLLEID¤POSITIVLISTE AF DOKUMENTTYPER[,]
Tegnet ¤ bruges til at opdele linier i 3 dele:
Eksempel på indhold i fil med Trust roller:
# #/pack/wildfly8/modules/nsi/ddsregistry/config/main/trusted_roles.txt -> /ddsregistry/war/src/test/conf/trusted_roles.txt # # Kendt rolle, lægesekretær, som kan se aftale- og pmhr dokumenter. Kendt rolle¤urn:dk:healthcare:national-federation-role:code:40001:value:lægesekretær¤,53576-5 # Kendt rolle, rengøringsassistent, som ikke kan se nogen dokumenttyper Kendt rolle¤urn:dk:healthcare:national-federation-role:code:12345:value:rengøringsassistent |
Hvis der er ændringer til konfigurationsfilerne for adgang via Trust, så skal WildFly genstartes før ændringerne er aktive.
Komponenten afvikles i et docker-compose setup, som ligger under https://svn.nspop.dk/svn/components/dds/trunk/compose.
Grundlæggende konfiguration foregår ved redigering i filen DDSRegistry.properties. Filen er placeret i compose/configuration/ddsregistry, og er volume-mappet.
I filen skal følgende properties være definerede:
Property | Beskrivelse |
---|---|
idcard.version | Servicen afviser kald, hvor ID-kort i Security-header ikke har versionsnummer opgivet som værdien af denne property. Angives til 1.0.1. |
sts.test.mode | Angiver med værdien true at servicen benytter test-STS. Værdien skal være ’false’ i drift, hvorved den rigtige SOSI-STS anvendes. |
log.config.file | Angiver placering af log4j properties. |
registry.invoker.use.fastinfoset | Angiver med værdien true, at servicen skal tilbyde anvendelse af Fast Infoset ved kommunikation med XDS Registries. Ved værdien false foregår kommunikationen med vanlig XML. |
client.consentverification.properties | Angiver placering af properties til kald af Samtykkeverifikationsservicen. |
client.minlogregistration.properties | Angiver placering af properties til kald af MinLog Registreringsservicen. |
client.documentregistry.properties | Angiver placering af properties til kald af HS Document Registry. |
client.treatment.relation.properties | Angiver placering af properties til kald af behandlingsrelationsservicen. |
treatment.relation.service.invoke | Angiver med værdien true, at behandlingsrelationsservicen skal kaldes. Værdien false bevirker, at behandlingsrelationsservicen ikke kaldes. |
minlog.query.default | Teksten der sendes til MinLog registreringsservicen, når en sundhedsperson laver opslag. |
minlog.query.consentoverride | Teksten der sendes til MinLog registreringsservicen, når en sundhedsperson laver opslag med tilsidesættelse af samtykketjek (værdispring). |
servicestatuscheck.consentverification.failurethreshold | Antal kald til samtykkeverifikationsservicen der må fejle før der meldes 500 på statussnitfladen |
servicestatuscheck.treatmentrelation.failurethreshold | Antal kald til BRS der må fejle før der meldes 500 på statussnitfladen |
servicestatuscheck.minlog.failurethreshold | Antal kald til MinLog der må fejle før der meldes 500 på statussnitfladen |
servicestatuscheck.database.failurethreshold | Antal kald til lokal database der må fejle før der meldes 500 på statussnitfladen |
ap.assigning.authorities.filename | Angiver fil med liste af AP, der indgår i komplekseforløb pilotprojektet. |
ap.patient.consent.filename | Angiver fil med liste af patienter, der har givet samtykke til AP. |
sts.keystore | Keystore, der indeholder DDS Registrys funktionscertifikat |
sts.keystore.password | Password til sts.keystore |
sts.endpoint | Endpointet, hvor DDS Registry skal trække sit SOSI IDkort på baggrund af sts.keystore |
idcard.subject.id.type | Subjecttype for IDKortet |
idcard.subject.id | Subjectid for IDKortet |
idcard.subject.name | Subjectnavn for IDKortet |
idcard.level | Sikkerhedsniveau for IDkortet |
idcard.system.name | Systemnavn i IDkortet |
Bemærk at overstregede properties ikke længere indlæses af DDS Registry, men er hardcodet som følge af ændring i DGWS håndtering. Værdierne skal stadig være tilgængelige i properties filen.
I den/de properties-filer, der udpeges af de forskellige ”client.*.properties” properties skal flg. properties defineres:
Property | Beskrivelse |
---|---|
verification.wsdl.location | Angiver service endpoint for Samtykkeverifikationsservicen |
registration.wsdl.location | Angiver service endpoint for MinLog Registreringsservicen |
registration.log.organisation_name | Angiver standard organisationsnavnet, der bliver sendt til MinLog Registreringsservicen. |
treatment.relation.wsdl.location | Angiver service endpoint for behandlingsrelationsservicen |
treatment.relation.service.timeout | Timeout givet i millisekunder anvendt ved kald til behandlingsrelationsservicen |
verification.invoker.timeout | Timeout givet i millisekunder anvendt ved kald til samtykke verifikationsservicen. |
registration.invoker.timeout | Timeout givet i millisekunder anvendt ved kald til minlog registreringsservicen. |
Udover ovenstående skal følgende angives i den properties fil, der er udpeget i propertien ”client.treatment.relation.properties”. Disse forholder sig til værdier i SOAP requesten til behandlingsrelationsservicen og de følgende beskrivelser refererer til elementer i denne.
Property | Beskrivelse |
---|---|
Indsættes som ’Serviceprovider/Name’ i behandlingsrelationsservicens treatmentRelationRequestBody | |
treatment.relation.serviceprovider.vendor | Indsættes som ’ServiceProvider/Vendor’ i behandlingsrelationsservicens treatmentRelationRequestBody |
treatment.relation.serviceprovider.version | Indsættes som ’ServiceProvider/Version’ i behandlingsrelationsservicens treatmentRelationRequestBody |
treatment.relation.lookup.timeinterval.start.offset | Angiver antallet af dage fra DDSRegistry-kaldtidspunktet, der skal indsættes som tidsstemplet ’RelationLookupTimeInterval/start’ i behandlingsrelationsservicens treatmentRelationRequestBody. Negativt fortegn angiver antal dage før DDSRegistry-kaldtidspunktet. |
treatment.relation.lookup.timeinterval.end.offset | Angiver antallet af dage fra DDSRegistry-kaldtidspunktet, der skal indsættes som tidsstemplet ’RelationLookupTimeInterval/end’ i behandlingsrelationsservicens treatmentRelationRequestBody. Negativt fortegn angiver antal dage før DDSRegistry-kaldtidspunktet. |
treatment.relation.timelimit.offset | Angiver antallet af dage fra DDSRegistry-kaldtidspunktet, der skal indsættes som tidsstemplet ’TimeLimit’ i behandlingsrelationsservicens treatmentRelationRequestBody. |
treatment.relation.queryable.cvr | Indsættes som ’QueryableCvr’ i behandlingsrelationsservicens treatmentRelationRequestBody |
Indsættes som ’ExternalReferenceId’ i behandlingsrelationsservicens treatmentRelationRequestBody | |
treatment.relation.acceptable.relations.hospital | Kommasepareret liste af kategorier, der indsættes som ’AcceptableRelations/Relation’ i behandlingsrelationsservicens treatmentRelationRequestBody, når sundhedspersonens organisation er opført som hospital (ved SHAK-kode). |
treatment.relation.followup.relations.hospital | Kommasepareret liste af kategorier, der indsættes som ’FollowupRelations/Relation’ i behandlingsrelationsservicens treatmentRelationRequestBody, når sundhedspersonens organisation er opført som hospital (ved SHAK-kode). |
treatment.relation.acceptable.relations.doctor | Kommasepareret liste af kategorier, der indsættes som ’AcceptableRelations/Relation’ i behandlingsrelationsservicens treatmentRelationRequestBody, når sundhedspersonens organisation er opført som yder (ved ydernummer). |
treatment.relation.followup.relations.doctor | Kommasepareret liste af kategorier, der indsættes som ’FollowupRelations/Relation’ i behandlingsrelationsservicens treatmentRelationRequestBody, når sundhedspersonens organisation er opført som yder (ved ydernummer). |
I metadata er identifikation af sundhedsorganisationer givet ved et id og anførelse af hvilken assigning authority, der har udstedt det id. I DDSRegistry.properties skal der ved properties givet i Tabel 1 være anført, hvilke object identifiers (OID), der anvendes for assigning authority for sundhedsorganisationers id.
Property | Beskrivelse |
---|---|
consent.check.sor.assigning.authorities.oid | |
consent.check.shak.assigning.authorities.oid | |
consent.check.ynumber.assigning.authorities.oid | |
registering.allowed.sor.assigning.authorities.oid | |
registering.allowed.shak.assigning.authorities.oid | |
registering.allowed.ynumber.assigning.authorities.oid |
Tabel 1 OID for assigning authorities for sundhedsorganisationer
OID-værdier for assigning authorities givet i mønsteret properties consent.check.* (fx consent.check.sor.assigning.authorities.oid) er de, der anvendes ved samtykkekontrol ved opslag på eksisterende metadata. Disse lister af OID-værdier vil vokse over tid og afspejle også evt. historiske assigning authorities.
OID-værdier for assigning authorities givet i mønsteret properties registering.allowed.* (fx registering.allowed.sor.assigning.authorities.oid) er de, der tillades ved dokumentkilders registrering af dokumentmetadata. Disse lister af OID-værdier bør kun afspejle de assigning authorities, der er i anvendelse på registreringstidspunktet.
Eksempel på ”DDSRegistry.properties” fil (bemærk at alle ”client.*.properties” udpeger filen selv, og at klient properties derfor er defineret i samme fil):
idcard.version = 1.0.1 sts.test.mode = true log.config.file=ddsregistry.log4j.properties client.consentverification.properties = DDSRegistry.properties client.minlogregistration.properties = DDSRegistry.properties client.documentregistry.properties = DDSRegistry.properties client.treatment.relation.properties = DDSRegistry.properties treatment.relation.service.invoke=true treatment.relation.service.invoke=true treatment.relation.service.timeout=3000 treatment.relation.wsdl.location = http://localhost:9090/ddsservices-brs-stub/BRSFacadeService/BRSFacadeStub?wsdl verification.wsdl.location=http://localhost:9090/consent-verification/service?wsdl verification.invoker.timeout=30000 registration.wsdl.location=http://localhost:8080/minlog-registration/service?wsdl registration.invoker.timeout=30000 treatment.relation.serviceprovider.name=service provider treatment.relation.serviceprovider.vendor=vendor treatment.relation.serviceprovider.version=version treatment.relation.lookup.timeinterval.start.offset=-1 treatment.relation.lookup.timeinterval.end.offset=1 treatment.relation.timelimit.offset=90 treatment.relation.queryable.cvr=19343634 treatment.relation.external.reference.id= treatment.relation.acceptable.relations.hospital=A,B,C treatment.relation.followup.relations.hospital=All treatment.relation.acceptable.relations.doctor=C,D,E treatment.relation.followup.relations.doctor=All consent.check.sor.assigning.authorities.oid=1.2.208.176.1.1,1.2.208.176.1 consent.check.shak.assigning.authorities.oid= consent.check.ynumber.assigning.authorities.oid= registering.allowed.sor.assigning.authorities.oid=1.2.208.176.1.1,1.2.208.176.1 registering.allowed.shak.assigning.authorities.oid= registering.allowed.ynumber.assigning.authorities.oid= servicestatuscheck.consentverification.failurethreshold = 1 servicestatuscheck.treatmentrelation.failurethreshold = 1 servicestatuscheck.minlog.failurethreshold = 1 servicestatuscheck.database.failurethreshold = 1 ap.assigning.authorities.filename=/pack/wildfly8/modules/nsi/ddsregistry/config/main/ap_authorities.txt ap.patient.consent.filename=/pack/wildfly8/modules/nsi/ddsregistry/config/main/ap_patients.txt idcard.subject.id.type=medcom:cvrnumber idcard.subject.id=46837428 idcard.subject.name=NETS DANID A/S - TU VOCES gyldig idcard.level=3 idcard.system.name=Dokumentdelingsservicen sts.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/sts/services/SecurityTokenService sts.keystore=Statens_Serum_Institut_VOCES.jks sts.keystore.password=Test1234 |
De dokumentindeks, hvortil DDSRegistry videresender opslag og registrering af dokumenter, er konfigureret i tabellen documentregistry i databasen documentsources.
Kolonne | Type | Beskrivelse |
---|---|---|
documentregistryid | int | unikt id for rækken |
documentregistryserviceurl | streng | Adressen for indeksets webservice-endpoint givet som URI. |
documentregistryfriendlyname | streng | Et relativt brugervenligt navn for indekset, der indgår i fejlbeskeden, når indekset ikke svarer rettidigt eller ikke kan tilgås. |
documentregistryservicenamespace | streng | Namespace anvendt af indeksets webservice-endpoint. Standard-værdien er urn:ihe:iti:xds-b:2007. |
documentregistrylocal | boolsk værdi | Hvorvidt indekset er lokalt eller ej. Dokumentdelingsservicen skal have præcis et lokalt indeks, der benyttes ved registrering af dokumenter. Værdien 1 anfører lokalt indeks, 0 ellers. |
documentregistrytimeoutvalue | int | Timeout givet i millisekunder anvendt ved Dokumentdelingsservicens opslag mod indekset, dvs. timeout for kald af indeksets webservice. |
documentregistryactive | boolsk værdi | Hvorvidt indekset anvendes eller ej. Værdien 1 anfører, at indekset anvendes, 0 ellers. |
documentregistryservicename | streng | Navnet på service-gruppen for indeksets webservice. Standard-værdien er DocumentRegistry_Service. |
documentregistryfailurethreshold | int | Grænseværdi for hvor mange kald til indekset der må fejle før monitoreringssnitfladen melder fejl. |
documentregistrysoapversion | streng | Hvorvidt der skal anvendes headere af type HSUID, DGWS (Security og Medcom) og Medcom fra DGWS. |
documentregistryititransaction | streng | Beskrivelse af hvilken ITI transaction, der kan anvendes på dokumentindekset. Understøtter en dokumentindeks flere ITI transactions skal der laves en indgang per ITI transaction. Se Tabel 4 for lovlige værdier, hvoraf der skal anføres en enkelt. |
Tabel 2 Tabellen documentregistry i documentsources-databasen
Værdi | Benytter HSUID udgående | Benytter DGWS udgående | Note |
---|---|---|---|
1.2 | ✓ | ÷ | |
1.2_NO_HSUID | ÷ | ÷ | |
1.2_DGWS | ✓ | ✓ | |
1.2_DGWS_NO_HSUID | ÷ | ✓ | |
1.2_MEDCOM_NO_HSUID | ÷ | (✓) Kun Medcom-header | |
1.2_NO_ADDR | ✓ | ÷ | Kalder uden addressing headers. |
Tabel 3 Værdier for documentregistrysoapversion, der anfører hvilke headere, der anvendes ved udgående kald fra DDS Registry mod XDS-komponenter.
Værdi | Beskrivelse |
---|---|
ITI-18 | Benyttes til opslag på metadata via Registry Stored Query ITI-18 transaktionen. |
ITI-42 | Benyttes til registrering af metadata for dokument(er) med fast (Stable) indhold via Register Document Set-b ITI-42 transaktionen. |
ITI-57 | Benyttes til opdatering af registrerede metadata via Update Document Set ITI-57 transaktionen. |
ITI-61 | Benyttes til registrering af metadata for dokument(er) med dynamisk (On-demand) indhold via Register On-Demand Document Entry ITI-61 transaktionen. |
Tabel 4 Værdier for documentregistryititransaction, der anfører hvilken ITI transaction, den givne indgang kan anvendes med.
Følgende er et eksempel på konfigurering af et lokalt, aktivt indeks:
Kolonne | Værdi |
---|---|
documentregistryid | 1 |
documentregistryserviceurl | http://sv-proj-093:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls |
documentregistryfriendlyname | DDS |
documentregistryservicenamespace | urn:ihe:iti:xds-b:2007 |
documentregistrylocal | 1 (true) |
documentregistrytimeoutvalue | 300000 |
documentregistryactive | 1 (true) |
documentregistryservicename | DocumentRegistry_Service |
documentregistryfailurethreshold | 5 |
documentregistrysoapversion | 1.2_MEDCOM_NO_HSUID |
documentregistryititransaction | ITI-42 |
Tabel 5 Eksempel på konfiguration af indeks
For at tilføje et indeks til konfigurationen, udføres et SQL-statement i stil med:
INSERT INTO documentsource.documentregistry (documentregistryserviceurl, documentregistryfriendlyname, documentregistryservicenamespace, documentregistrylocal, documentregistryservicename, documentregistryfailurethreshold, documentregistryititransaction) VALUES (' http://sv-proj-093:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls', 'DDS', 'urn:ihe:iti:xds-b:2007', true, '300000', true, 'DocumentRegistry_Service', 5, '1.2_MEDCOM_NO_HSUID', 'ITI-42'); |
Log4j konfiguration findes i (hvis ovenstående format anvendes) compose/configuration/ddsregistry/ddsregistry.log4j.properties filen.
Se yderligere opsætning i installationsvejledningen.
SLA-logning på DDS Registry udføres vha SLALoggingInterceptor.
Konfiguration af SLA-log findes i filen compose/configuration/ddsregistry/nspslalog-ddsregistry.properties.
For at tilføje et CVR-nummer til white-list databasen, bruges følgende SQL insert:
INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsregistry', '', 'some-cvr-number-here' ); |
Da DDSRegistry sender Id-kortet videre til samtykkeservice, behandlingsrelationsservice og minlog-registrationservice skal whitelisten også opdateres med følgende værdier:
INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.auth.brs.cvr.list', '', 'some-cvr-number-here' ); INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.consent.verification', '', 'some-cvr-number-here' ); INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.minlog.registration', '', 'some-cvr-number-here' ); |
Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS) for endpointet for RegistryStoredQuery, RegisterDocumentSetB og RegisterOnDemandDocumentEntry, indlæses af DDS Registry fra filen:
/pack/wildfly8/modules/nsi/ddsregistry/config/main/dksConfiguration.xml |
Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS) for endpointet for UpdateDocumentSet, indlæses af DDS Registry fra filen:
/pack/wildfly8/modules/nsi/ddsregistry/config/main/metadataUpdateDksConfiguration.xml |
Filerne skal overholde DKS XML-skemaet og beskriver de webservice-operationer DDS Registry udstiller jf. [DKS-beskrivelse].
Efter konfiguration og deployering af DDS Registry servicen, kan DKS-snitfladerne testes med:
curl –i localhost:9090/ddsregistry/dccconfig/dks curl –i localhost:9090/ddsregistry/metadataupdate/dccconfig/dks |
Succesfuldt svar giver indholdet svarende til filerne nævnt ovenfor.
Det er muligt at konfigurere registry'et til at lede efter HTTP- og SOAP-headere, og videresende dem til bagvedliggende registries. Videresendelse styres af databasetabellen documentsources.documentregistry_forwarded_header. Indholdet af tabellen er som følger:
Feltnavn | Indhold |
---|---|
headername | Navn på header, der ledes efter. Hvis headertype er 'HTTP', ledes i HTTP-headers i requestet. Hvis headertype er 'SOAP', ledes i headere i SOAP-envelopen i requestet. |
headertype | Typen af header der ledes efter. Kan være 'HTTP' eller 'SOAP', skrevet med store bogstaver. |
documentregistryid | Id på documentregistry, som header ønskes videresendt til. Der er opsat en foreign key-constraint, der sikrer at der refereres til et registry i documentregistry-tabellen. |
Til statuscheck af DDSRegistry findes en servicecheck servlet der kalder servicens afhængigheder, samt en statuscheck servlet der monitorerer de kald der foretages fra DDSRegistry. Begge servlets udstiller http-snitflader som melder 500 ved fejl.
Efter konfiguration og deploy af DDS Registry kan versionsnummeret hentes med følgende kommando:
curl localhost:9090/ddsregistry/version |
hvilket giver output i stil med:
Version: 2.0.0 |
I eksemplet kørte servicen på en lokal maskine konfigureret til port 9090.
På grund af en kendt fejl i JBoss 6, logges en række exceptions i server loggen, hvis følgende filer ikke findes (de må gerne være tomme):
/pack/jboss/server/default/conf/props/roles.properties /pack/jboss/server/default/conf/props/users.properties |
Databasemonitoreringen laver en simpel query mod databasen. Denne query er justbar og kan ændres i DDSRegistry.properties
documentsourcesds.statement=SELECT * FROM documentsources.documentregistry LIMIT 1; sords.statement=SELECT * FROM stamdata.sorrelationer LIMIT 1; authds.statement=SELECT * FROM stamdata.autreg LIMIT 1; whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1; |
Til Monitorering af afhængigheder til egen propertyfil, trådmanager, document registry og egen database findes en servlet i DDSRegistry. Bemærk at denne snitflade laver kald til databasen og healthshare registry.Efter konfiguration og deploy af DDSRegistry, kan den testes med:
curl –i localhost:9090/ddsregistry/servicecheck |
Servicen returnerer følgende http koder:
Til Monitorering af forbindelser til BRS, MinLog, SamtykkeVerifikationsservice, registries og egen database findes en servlet i DDSRegistry. Denne service opsamler data på hvor mange kald til de forskellige andre services der er fejlet, og melder fejl hvis det overstiger de threshold-værdier der er defineret i property-filen.
Efter konfiguration og deploy af DDSRegistry, kan den testes med:
curl –i localhost:9090/ddsregistry/status |
Servicen returnerer følgende http koder:
DDS Registry overvåges af en servicespecifik servicechecksnitflade, samt en statussnitflade. Disse to snitfladers url’er kan aflæses i afsnit 2.
Under listen af komponenter først i dette dokument, er der henvisninger til overvågningssiderne.
Alle overvågningssider returnerer enten status 200 hvis de i øjeblikket kører fint, status 404 hvis servicen ikke er deployeret og status 500, hvis der er opstået en fejl, og komponenten derfor ikke virker korrekt.
Simpel webside deployeret på serveren. Som udgangspunkt overvåges følgende:
Alle logfiler er at finde i log/ under WildFly. Herunder findes en liste over alle logfiler med en beskrivelse af hvilke komponenter der skriver til dem. Hvorvidt der anvendes disse default-logfilnavne eller skrives til andre, er afhængig af servicens konfiguration af log4j.
Logfilnavn | Komponenter der skriver til logfilen | Beskrivelse |
---|---|---|
ddsregistry.log | DDS Registry | Generel applikationslog |
dds-audit.log | DDS Registry | Auditlog for indkommende kald af servicens operationer |
nsputil-sla-ddsregistry.log | DDS Registry | SLA-log |
ddsregistry-consentoverride.log | DDS Registry | Log over anvendelse af værdispring ved kald af servicens operationer |
ddsregistry-servicecheck.log | DDS Registry | Logfil for aktivt servicecheck |
ddsregistry-status.log | DDS Registry | Logfil for passivt opsamlet status på webservice- og database-kald. |
ddsregistry-xdserror.log | DDS Registry | Logfil for XDS-fejl indlejret i svar samt fejl ved kald af eksterne XDS-komponenter. |
For alle webservices er der en tilhørende SLA-log, der sørger for at logge udvalgte elementer fra requests til webservicen. For DDS Registry logges alle kald til DDSRegistryWS hvor loggen vil indeholde information om kald til webservicens forskellige serviceoperationer og behandlingstid for kaldet inklusiv kald til kontrolservices.
SLA-logpunkter for indkommende kald til DDS Registry:
SLA-logpunkter for udgående kald fra DDS Registry:
Kaldte service | LogPoint | TargetSOAPOperation |
---|---|---|
Behandlings-relations-service | DocumentRegistry_RegistryStoredQuery.TreatmentRelation | |
MinLog | DocumentRegistry_RegistryStoredQuery.Minlog.LogDataAdd | LogDataAdd |
Samtykke | DocumentRegistry_RegistryStoredQuery.ConsentForUserCheck | urn:dk:nsi:consentservices:verification:service:1#ConsentForUserCheck |
Samtykke | DocumentRegistry_RegistryStoredQuery.ConsentForDataCheck | urn:dk:nsi:consentservices:verification:service:1#ConsentForDataCheck |
XDS Registry | DocumentRegistry_RegistryStoredQuery | urn:ihe:iti:2007:RegistryStoredQuery |
DocumentRegistry_RegisterDocumentSet-b | urn:ihe:iti:2007:RegisterDocumentSet-b | |
DocumentRegistry_RegisterOnDemandDocumentEntry | urn:ihe:iti:2010:RegisterOnDemandDocumentEntry | |
DocumentRegistry_UpdateDocumentSet | urn:ihe:iti:2010:UpdateDocumentSet |
For SLA-logning af udgående kald til XDS Registry:
Auditlogning foretages med det officielle NSP Audit Log modul.
De forskellige ITI-håndtag logges på følgende måde.
ITI-18 søgninger logger patient-id, bruger-id, på-vegne-af-id og for hver DocumentEntry (DE) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode. Se eksempel nedenfor:
{ "time": "2018-09-27T19:55:44.68Z", "category": "dk.sds.nsp.audit.log.dds", "audit": { "timestamp": "2018-09-27T21:55:42.745+02:00", "components": [ { "component": "DDS", "contexts": [ { "context": "documentRegistryAdhocQuery", "information": [ { "key": "patient-cpr", "type": "RPI", "value": "2110979420" }, { "key": "bruger-cpr", "type": "RPI", "value": "0101584160" }, { "key": "on-behalf-of-cpr", "type": "RPI", "value": "0101584160" }, { "key": "queryTypecode", "type": "NPI", "values": [ "('53576-5^^2.16.840.1.113883.6.1')", "('39289-4^^2.16.840.1.113883.6.1')" ] }, { "key": "document_entry.0.homecommunityid", "type": "SPI", "value": "" }, { "key": "document_entry.0.repositoryid", "type": "SPI", "value": "1.3.6.1.4.1.21367.2010.1.2.1125" }, { "key": "document_entry.0.documentid", "type": "SPI", "value": "8352061236760766124.2930903161888816635.1538046332405" }, { "key": "document_entry.0.typecode", "type": "SPI", "value": "53576-5" }, { "key": "document_entry.1.homecommunityid", "type": "SPI", "value": "" }, { "key": "document_entry.1.repositoryid", "type": "SPI", "value": "1.3.6.1.4.1.21367.2010.1.2.1125" }, { "key": "document_entry.1.documentid", "type": "SPI", "value": "4869530052539485342.5952203964580776052.1537974946937" }, { "key": "document_entry.1.typecode", "type": "SPI", "value": "53576-5" } ] } ] } ] }, "access": { "code": 200, "duration": 1826, "httpHeaders": { "Content-Type": "application/soap+xml; charset=UTF-8" }, "httpHost": "localhost", "idCardAttributes": { "medcom:CareProviderID": "30808460", "medcom:CareProviderName": "NETS DANID A/S", "medcom:ITSystemName": "TRUST2408 Systemtest XIX CA", "sosi:AuthenticationLevel": "3", "sosi:IDCardID": "RBW1ZXSm/btA4HnXsGvhpg==", "sosi:IDCardType": "system", "sosi:IDCardVersion": "1.0.1" }, "method": "POST", "path": "/ddsregistry/service", "query": "", "port": 9090, "protocol": "http", "reqSize": 8754, "resSize": 16910, "soapHeaders": { "Issuer": "TEST1-NSP-STS", "MessageID": "AAABZhyZvtFydsMAFNBBgFNPU0k=", "NameID": "SubjectDN={SERIALNUMBER=CVR:30808460-UID:25351738 + CN=NETS DANID A/S - TU VOCES gyldig, O=NETS DANID A/S // CVR:30808460, C=DK},IssuerDN={CN=TRUST2408 Systemtest XIX CA, O=TRUST2408, C=DK},CertSerial={1478025777}", "w3Action": "urn:ihe:iti:2007:RegistryStoredQuery", "w3MessageID": "urn:uuid:9660068c-accb-425e-a350-2dd9cbfcf408", "w3To": "http://localhost:9090/ddsregistry/service" }, "threadId": "default task-1", "time": "2018-09-27T21:55:42.739+02:00", "stats": { "handlerDuration": 90, "bufferAllocated": true, "usedBuffers": 2, "activeBuffersInPool": 2, "idleBuffersInPool": 0 } } } |
ITI-42, ITI-61, ITI-57: foretag auditlogning for hver DocumentEntry (DE) i request DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode. Se eksempel for ITI-42 nedenfor:
{ "time": "2018-09-27T19:35:31.637Z", "category": "dk.sds.nsp.audit.log.dds", "audit": { "timestamp": "2018-09-27T21:35:00.127+02:00", "components": [ { "component": "DDS", "contexts": [ { "context": "documentRegistryRegisterDocumentSetB", "information": [ { "key": "document_entry.0.repositoryid", "type": "SPI", "value": "1.3.6.1.4.1.21367.2010.1.2.1125" }, { "key": "document_entry.0.documentid", "type": "SPI", "value": "8406697653882052301.9182522181609895318.1537976250509" }, { "key": "document_entry.0.typecode", "type": "SPI", "value": "74465-6" } ] } ] } ] }, "access": { "code": 200, "duration": 31504, "httpHeaders": { "Content-Type": "text/xml" }, "httpHost": "localhost", "idCardAttributes": { "medcom:CareProviderID": "30808460", "medcom:CareProviderName": "NETS DANID A/S", "medcom:ITSystemName": "TRUST2408 Systemtest XIX CA", "sosi:AuthenticationLevel": "3", "sosi:IDCardID": "0YlQSQCxdxK41NLE23AsZA==", "sosi:IDCardType": "system", "sosi:IDCardVersion": "1.0.1" }, "method": "POST", "path": "/ddsregistry/service", "query": "", "port": 9090, "protocol": "http", "reqSize": 20796, "resSize": 2419, "soapHeaders": { "Issuer": "TEST1-NSP-STS", "MessageID": "AAABZhrz9QPpy4eB02Sp+lNPU0k=", "NameID": "SubjectDN={SERIALNUMBER=CVR:30808460-UID:25351738 + CN=NETS DANID A/S - TU VOCES gyldig, O=NETS DANID A/S // CVR:30808460, C=DK},IssuerDN={CN=TRUST2408 Systemtest XIX CA, O=TRUST2408, C=DK},CertSerial={1478025777}", "w3Action": "urn:ihe:iti:2007:RegisterDocumentSet-b", "w3MessageID": "urn:uuid:6dae669b-0757-4fe9-ac45-e0f3009c9643", "w3To": "http://localhost:9090/ddsregistry/service" }, "threadId": "default task-7", "time": "2018-09-27T21:35:00.127+02:00", "stats": { "handlerDuration": 4, "bufferAllocated": true, "usedBuffers": 3, "activeBuffersInPool": 3, "idleBuffersInPool": 0 } } } |
Det anbefales at aktuelle konfigurationsfiler til DDS Registry er under versionskontrol og back up.