Introduktion

...

Afsnit 4 (Konfiguration) beskriver aktuelle konfigurationsparametre for DDS Registry henholdsvis Repository, samt eksempler på konfigurationsparameter-filer.

Afsnit 5.1, 5.2 og 5 .3 (Overvågning) beskriver hvorledes DDS Registry og Repository komponenterne overvåges.

I afsnit 5.4 6 (Logfiler og fortolkning af disse) er DDS Registry og Repository-relaterede logfiler beskrevet, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning.

...

Komponenter

...

• DDS Registry
  • Type: Webservice
  • Filnavn: ddsregistry.war
  • Servicecheckurl: <serverurl>/ddsregistry/servicecheck
  • Statusurl: <serverurl>/ddsregistry/status
  • Versionurl: <serverurl>/ddsregistry/version
  • Endpoint for RegistryStoredQuery:
    • Url: <serverurl>/ddsregistry
    • DKS-konfiguration DGWS: <serverurl>/ddsregistry/dksconfig
    • DKS-konfiguration IDWS: <serverurl>/ddsregistry/dccconfigidws/dksdksconfig

• DDS Repository

  • Type: Webservice

  • Filnavn: ddsrepository.war

  • Url: <serverurl>/ddsrepository

  • Servicecheckurl: <serverurl>/ddsrepository/servicecheck

  • Statusurl: <serverurl>/ddsrepository/status

  • Versionurl: <serverurl>/ddsrepository/version

  • 
    

  • DKS-konfiguration DGWS: <serverurl>/ddsrepository/dksconfig
  • DKS-konfiguration IDWS: <serverurl>/ddsrepository/dccconfigidws/dksdksconfig

DDS komponenterne anvender desuden ConsentVerification-servicen, MinLog Registration-servicen, Behandlingsrelationsservicen samt STS’en.

...

• Alle linier der starter med # betragtes som en kommentar.
• Blanke linier er tilladte.
• Alle andre linier bliver behandlet.
• Ved fejl skrives en fejlbesked til loggen - den fejlramte linie ignoreres og indlæsningen fortsætterstopper.
• Parserne er case-sensitive.

...

• ROLLETEKST - en kort beskrivelse af den rolle linien omhandler.
• ROLLEID - en unik nøgle der angiver rollen. Nøglen har følgende format fra SOSI id kortet
  • urn:dk:healthcare:national-federation-role:code:<kode>:value:<værdi>
• POSITIVLISTE AF DOKUMENTTYPER - liste af dokumenttyper, som rollen giver adgang til adskilt med komma.
  Anvendes tegnet * istedet for en dokumenttype tillades alle dokumenttyper. Specifikke dokumenttyper og tegnet * må ikke anvendes i kombination.

Eksempel på indhold i fil med Trust roller:

Genindlæsning

Hvis der er ændringer til konfigurationsfilerne for adgang via Trust, så skal WildFly genstartes før ændringerne er aktive. 

Konfiguration

...

nsp-role-mapping.properties

DDS Registry og Repository anvender denne property fil til at mappe hvilken rolle (role), der kommer ned i minlog registreringen.

Property filen vedligeholdes her: https://

...

git.nspop.dk/

...

projects/TOOL/

...

repos/nsp-role-mapping/browse/nsp-role-mapping.properties

Genindlæsning

Hvis der er ændringer til konfigurationsfilerne for adgang via Trust, så skal WildFly genstartes før ændringerne er aktive. 

Konfiguration

Komponenterne afvikles i et docker-compose setup, som ligger under https://svn.nspop.dk/svn/components/dds/trunk/compose.

En række af DDS registry og DDS repositorys properties har samme navne og anvendelse. Derfor beskrives disse sammen nedenfor. Efterfølgende beskrives de properties, som adskiller sig for de 2 komponenter.

DDS Registry og Repository

Servicekonfiguration

Grundlæggende konfiguration foregår ved redigering i filerne

• For DDS registry: DDSRegistry.properties. Filen er placeret i compose/configuration/ddsregistry, og er volume-mappet.
• For DDS repository: DDSRepository.properties.  Filen er placeret i compose/configuration/ddsrepository, og er volume-mappet.

I filerne skal følgende properties være definerede. Bemærk kolonnerne "Reg" og "Rep" der angiver med 'x' om propertien kan anvendes for registry henholdsvis repository properties filen.

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.

Registry og Repository properties

...

En række af DDS registry og DDS repositorys properties har samme navne og anvendelse. Derfor beskrives disse sammen nedenfor. Efterfølgende beskrives de properties, som adskiller sig for de 2 komponenter.

DDS Registry og Repository

Servicekonfiguration

Grundlæggende konfiguration foregår ved redigering i filerne

• For DDS registry: DDSRegistry.properties. Filen er placeret i compose/configuration/ddsregistry, og er volume-mappet.
• For DDS repository: DDSRepository.properties.  Filen er placeret i compose/configuration/ddsrepository, og er volume-mappet.

I filerne skal følgende properties være definerede. Bemærk kolonnerne "Reg" og "Rep" der angiver med 'x' om propertien kan anvendes for registry henholdsvis repository properties filen.

TODO: 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.

Registry og Repository properties

I den/de properties-filer, der udpeges af de forskellige ”client.*.properties” properties skal flg. properties defineres:

...

Property

...

Reg

...

Rep

...

Beskrivelse

...

verification.wsdl.location

...

x

...

x

...

Angiver service endpoint for Samtykkeverifikationsservicen

...

registration.log.organisation_name

...

x

...

x

...

Angiver standard organisationsnavnet, der bliver sendt til MinLog Registreringsservicen.

...

treatment.relation.wsdl.location

...

x

...

x

...

Angiver service endpoint for behandlingsrelationsservicen

...

treatment.relation.service.timeout

...

x

...

x

...

Timeout givet i millisekunder anvendt ved kald til behandlingsrelationsservicen 

...

verification.invoker.timeout

...

x

...

x

...

Timeout givet i millisekunder anvendt ved kald til samtykke verifikationsservicen.

...

x

...

x

...

Kafka klient id anvendt til MinLog registrering.

...

x

...

Angiver, om DDS skal minlogge, når der kaldes med SOSI Idkort niveau 3

Skal sættes: true, false

...

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

...

Reg

...

Rep

...

Beskrivelse

...

treatment.relation.serviceprovider.vendor

...

x

...

x

...

Indsættes som ’ServiceProvider/Vendor’ i behandlingsrelationsservicens treatmentRelationRequestBody

...

treatment.relation.serviceprovider.version

...

x

...

x

...

Indsættes som ’ServiceProvider/Version’ i behandlingsrelationsservicens treatmentRelationRequestBody

...

treatment.relation.lookup.timeinterval.start.offset

...

x

...

x

...

Angiver antallet af dage fra DDS-kaldtidspunktet, der skal indsættes som tidsstemplet ’RelationLookupTimeInterval/start’ i behandlingsrelationsservicens treatmentRelationRequestBody.

Negativt fortegn angiver antal dage før DDS-kaldtidspunktet.

...

treatment.relation.lookup.timeinterval.end.offset

...

x

...

x

...

Angiver antallet af dage fra DDS-kaldtidspunktet, der skal indsættes som tidsstemplet ’RelationLookupTimeInterval/end’ i behandlingsrelationsservicens treatmentRelationRequestBody.

Negativt fortegn angiver antal dage før DDS-kaldtidspunktet.

...

treatment.relation.timelimit.offset

...

x

...

x

...

Angiver antallet af dage fra DDS-kaldtidspunktet, der skal indsættes som tidsstemplet ’TimeLimit’ i behandlingsrelationsservicens treatmentRelationRequestBody.

...

treatment.relation.queryable.cvr

...

x

...

x

...

Indsættes som ’QueryableCvr’ i behandlingsrelationsservicens treatmentRelationRequestBody

...

treatment.relation.external.reference.id

...

x

...

x

...

Indsættes som ’ExternalReferenceId’ i behandlingsrelationsservicens treatmentRelationRequestBody

...

treatment.relation.acceptable.relations.hospital

...

x

...

x

...

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

...

x

...

x

...

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

...

x

...

x

...

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

...

x

...

x

...

Kommasepareret liste af kategorier, der indsættes som ’FollowupRelations/Relation’ i behandlingsrelationsservicens treatmentRelationRequestBody, når sundhedspersonens organisation er opført som yder (ved ydernummer).

...

treatment.relation.acceptable.relations.organization

...

x

...

x

...

Kommasepareret liste af kategorier, der indsættes som ’AcceptableRelations/Relation’ i behandlingsrelationsservicens treatmentRelationRequestBody, når sundhedspersonens organisation er opført som SOR (ved SOR-kode).

...

treatment.relation.followup.relations.organization

...

x

...

x

...

Kommasepareret liste af kategorier, der indsættes som ’FollowupRelations/Relation’ i behandlingsrelationsservicens treatmentRelationRequestBody, når sundhedspersonens organisation er opført som SOR (ved SOR-kode).

*1: ved iti-18 kaldes anvendes disse tekster som default. Der kan være mere specifikke tekster der er konfigureret i database tabellerne minlog_text og minlog_usertype_text.

I den/de properties-filer, der udpeges af de forskellige ”client.*.properties” properties skal flg. properties defineres:

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.

Registry properties


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.

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,

Registry properties


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

...

og at klient properties derfor er defineret i samme fil):

Konfiguration af indeks for DDS registry

ReposiDe 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

...

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.

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-18

Eksempel på ”DDSRepository.properties” fil (bemærk at alle ”client.*.properties” udpeger filen selv, og at klient properties derfor er defineret i samme fil):

Konfiguration af indeks for DDS registry

ReposiDe dokumentindeks, hvortil DDSRegistry videresender opslag og registrering af dokumenter, er konfigureret i tabellen documentregistry i databasen documentsources.

Tabel 5 Eksempel på konfiguration af indeks

For at tilføje et indeks til konfigurationen, udføres et SQL-statement i stil med:

log4j konfiguration

Log4j konfiguration findes i (hvis ovenstående format anvendes):

• For DDS registry: compose/configuration/ddsregistry/ddsregistry.log4j.properties filen.
• For DDS repository:  compose/configuration/ddsrepository/ddsrepository.log4j.properties filen

Se yderligere opsætning i installationsvejledningen.

SLA-log konfiguration

SLA-logning på DDS Registry og Repository udføres vha SLALoggingInterceptor. Konfiguration af SLA-log findes i filen:

• For DDS registry: compose/configuration/ddsregistry/nspslalog-ddsregistry.properties.
• For DDS repository: compose/configuration/ddsrepository/nspslalog-ddsrepository.properties.

Whitelist konfiguration

Der foretages whitelisting på to niveauer. Først er der den whitelisting, der skal til for at anvende DDS Registry og Repository. Derudover findes en whitelisting, der afgør, hvorvidt en anvender må kalde DDS med et niveua 3 Idkort. De to whitelisting-mekanismer beskrives i det følgende.

Whitelisting til anvendelse af DDS Registry og Repository

For at tilføje et CVR-nummer til white-list databasen, bruges følgende SQL insert:

For DDS registry:

For DDS repository:

Da DDS Registry og Repository sender Id-kortet videre til samtykkeservice, behandlingsrelationsservice og minlog-registrationservice skal whitelisten også opdateres med følgende værdier:

Whitelisting til kald med niveau 3 Idkort

Alle anvendere skal whitelistes som beskrevet ovenfor for at anvende DDS Registry og Repository. Derudover findes en ekstra whitelisting mekanisme, som gør det muligt for visse anvendere at kalde DDS Registry og Repository med et niveau 3 Idkort. Dette kræver en særlig whitelisting og kan sættes op ved at tilføje oplysninger om anvenderen i konfigurationsparameteren 'whitelisted.level3.cvrs'. På trods af navnet kan whitelisting til niveau 3 sættes op på to niveauer: CVR nummer eller et specifikt certifikat.

Værdien er en kommasepereret liste som vist i følgende eksempel:

...

Eksemplet viser de tre formater, der kan anvendes:

• Værdi uden type: I eksempelt ovenfor fortolkes værdien '31908574' som et CVR nummer. Dette sikrer bagudkompatibilietet med tidligere opsætninger
• Værdier med typen CVR: I eksemplet ovenfor fortolkes 'CVR:46837428' som et CVR nummer med værdien 46837428
• Værdier med typen CERT: I eksemplet ovenfor fortolkes 'CERT:CVR:33257872-FID:28250866' som whitelisting af certificatet med Subject Serial Number CVR:33257872-FID:28250866.

I forhold til anvenderne, så tjekkes det, om der er en whitelisting af anvenderens CVR nummer og hvis dette ikke er tilfældet, så tjekkes, om det specifikke certifikat, der anvendes er whitelistet. Alle andre forsøg på adgang med niveau 3 Idkort afvises.

DKS konfiguration

Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS), indlæses fra filen:

• Fra DDS registry: /pack/wildfly8/modules/nsi/ddsregistry/config/main/dksConfiguration.xml
• Fra DDS repository: /pack/wildfly8/modules/nsi/ddsrepository/config/main/dksConfiguration.xml

Filerne skal overholde DKS XML-skemaet og beskriver de webservice-operationer DDS Registry udstiller jf. [DKS-beskrivelse].

Test af DKS

Efter konfiguration og deployering af DDS Registry og Repository servicene, kan DKS-snitfladerne testes med:

Succesfuldt svar giver indholdet svarende til filerne nævnt ovenfor.

Header konfiguration

Det er muligt at konfigurere registry og repository til at lede efter HTTP- og SOAP-headere, og videresende dem til bagvedliggende registries.

Videresendelse styres af databasetabellerne

• For DDS registry:  documentsources.documentregistry_forwarded_header
• For DDS repository: documentsources.documentsource_forwarded_header

Indholdet af tabel documentsources.documentregistry_forwarded_header er som følger:

...

Feltnavn

...

Indhold

...

Indholdet af tabel documentsources.documentsource_forwarded_header er som følger:

...

Feltnavn

...

Indhold

...

DocumentSources konfiguration for DDS repository

For at tilføje et kildesystem til documentsource databasen, bruges følgende 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

• soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:

...

Værdi

...

Benytter HSUID udgående

...

Benytter DGWS udgående

...

1.1

...

+

...

÷

...

1.2

...

+

...

÷

...

1.1_NO_HSUID

...

÷

...

÷

...

1.2_NO_HSUID

...

÷

...

÷

...

1.2_DGWS

...

+

...

+

...

1.2_DGWS_NO_HSUID

...

÷

...

+

...

1.2_DGWS_NO_ADDR

...

+

...

+

...

1.2_MEDCOM_NO_HSUID

...

÷

...

(+)

Kun Medcom-header

Værdien 1.2_DGWS_NO_ADDR benyttes, når WS-Addressing ikke ønskes anvendt.

• timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.

• failurethreshold: Angiver grænseværdi for hvor mange kald mod repositoriet der må fejle før monitoreringssnitfladen melder fejl. Angives som heltal.

Kombinationen oid og unique_id_type skal være unik.

Monitorering af DDSRegistry

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.

Test af versionsnummer

Efter konfiguration og deploy af DDS Registry kan versionsnummeret hentes med følgende kommando:

hvilket giver output i stil med:

I eksemplet kørte servicen på en lokal maskine konfigureret til port 9090.

Specielt vedrørende testConnection på JBoss

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

Konfiguration af databasemonitorering

Databasemonitoreringen laver en simpel query mod databasen. Denne query er justbar og kan ændres i DDSRegistry.properties

Test af monitorering af afhængigheder

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:

Servicen returnerer følgende http koder:

• Der returneres http kode 200 ved normal situation.
• http fejlkode 404 returneres hvis servicen ikke er deployeret
• Hvis en eller flere af afhængighederne mangler eller ved intern fejl i WildFly returneres kode 500. Fejlbeskeden vil kunne ses i ddsregistry-servicecheck.log. Såfremt der ikke er nogen fejlbeskeder i loggen bør property-filen undersøges som det første, da det er herigennem logindstillingerne bestemmes.

Test af monitorering af status

Til Monitorering af forbindelser til BRS, MinLog, SamtykkeVerifikationsservice, PersonInformation, 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:

Servicen returnerer følgende http koder:

• Der returneres http kode 200 ved normal situation.
• http fejlkode 404 returneres hvis servicen ikke er deployeret
• Hvis en eller flere af interne afhængighederne har fejlet nok gange til at nå deres grænseværdi returneres kode 203.
• Hvis en eller flere af ekserne afhængighederne (minlog osv) har fejlet nok gange til at nå deres grænseværdi returneres kode 500. 
• Bemærk at DDSRegistry anvender ”documentregistryfriendlyname” kombineret med ”documentregistryititransaction” (se afsnit 4.1.1.1) til identifikation af de forskellige indekser.

Fejlbeskeder vil kunne ses i ddsregistry-status.log.

Opsamlingen af kald til en service der fejler nulstilles automatisk efter et antal sekunder. Dette styrres med en properti, servicestatuscheck.unlockdelay.

Nulstilling af opsamling af kald

Opsamlingen af kald der benyttes til monitoring af status kan nustilles. Servicen resetstatuscounters nulstiller alle de opsamlede data omkring fejlkald der har været siden sidste nulstilling.

Der skrives i statusloggen når denne service har været brugt.
Nulstil status

Servicen returnerer følgende http koder:

• Der returneres http kode 200 ved normal situation.

Overvågning

DDS Registry overvåges af en servicespecifik servicechecksnitflade, samt en statussnitflade. Disse to snitfladers url’er kan aflæses i afsnit 2.

Placering af HTML overvågningsside

Under listen af komponenter først i dette dokument, er der henvisninger til overvågningssiderne.

Fortolkning af HTML overvågningsside

Alle overvågningssider returnerer enten status 200 hvis de i øjeblikket kører fint, status 404 hvis servicen ikke er deployeret, 203 mange fejl fra intern dds kald og status 500, hvis der er opstået en fejl, og komponenten derfor ikke virker korrekt.

Overvågningstype

Simpel webside deployeret på serveren. Som udgangspunkt overvåges følgende:

1. Tilstedeværelse og indhold af propertyfil
2. Forbindelse til datasources via JNDI opslag
3. Forbindelse til document registry
4. Konfiguration af trådmanager

Logfiler og fortolkning af disse

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.

...

SLA-logpunkter for indkommende kald til DDS Registry:

• DocumentRegistry_RegistryStoredQuery

SLA-logpunkter for udgående kald fra DDS Registry:

...

Kaldte service

...

LogPoint

...

TargetSOAPOperation

...

Behandlings-relations-service

...

DocumentRegistry_RegistryStoredQuery.TreatmentRelation

...

http://nsi.dk/fmki20110601#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

Tabel 2 Tabellen documentregistry i documentsources-databasen

Tabel 3 Værdier for documentregistrysoapversion, der anfører hvilke headere, der anvendes ved udgående kald fra DDS Registry mod XDS-komponenter.

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:

Tabel 5 Eksempel på konfiguration af indeks

For at tilføje et indeks til konfigurationen, udføres et SQL-statement i stil med:

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

log4j konfiguration

Log4j konfiguration findes i (hvis ovenstående format anvendes):

• For DDS registry: compose/configuration/ddsregistry/ddsregistry.log4j.properties filen.
• For DDS repository:  compose/configuration/ddsrepository/ddsrepository.log4j.properties filen

Se yderligere opsætning i installationsvejledningen.

SLA-log konfiguration

SLA-logning på DDS Registry og Repository udføres vha SLALoggingInterceptor. Konfiguration af SLA-log findes i filen:

• For DDS registry: compose/configuration/ddsregistry/nspslalog-ddsregistry.properties.
• For DDS repository: compose/configuration/ddsrepository/nspslalog-ddsrepository.properties.

Whitelist konfiguration

Der foretages whitelisting på to niveauer. Først er der den whitelisting, der skal til for at anvende DDS Registry og Repository. Derudover findes en whitelisting, der afgør, hvorvidt en anvender må kalde DDS med et niveua 3 Idkort. De to whitelisting-mekanismer beskrives i det følgende.

Whitelisting til anvendelse af DDS Registry og Repository

For at tilføje et CVR-nummer til white-list databasen, bruges følgende SQL insert:

For DDS registry:

For DDS repository:

Da DDS Registry og Repository sender Id-kortet videre til samtykkeservice, behandlingsrelationsservice og minlog-registrationservice skal whitelisten også opdateres med følgende værdier:

Whitelisting til kald med niveau 3 Idkort

Alle anvendere skal whitelistes som beskrevet ovenfor for at anvende DDS Registry og Repository. Derudover findes en ekstra whitelisting mekanisme, som gør det muligt for visse anvendere at kalde DDS Registry og Repository med et niveau 3 Idkort. Dette kræver en særlig whitelisting og kan sættes op ved at tilføje oplysninger om anvenderen i konfigurationsparameteren 'whitelisted.level3.cvrs'. På trods af navnet kan whitelisting til niveau 3 sættes op på to niveauer: CVR nummer eller et specifikt certifikat.

Værdien er en kommasepereret liste som vist i følgende eksempel:

Opsætning af niveau 3 whitelisting

Eksemplet viser de tre formater, der kan anvendes:

• Værdi uden type: I eksempelt ovenfor fortolkes værdien '31908574' som et CVR nummer. Dette sikrer bagudkompatibilietet med tidligere opsætninger
• Værdier med typen CVR: I eksemplet ovenfor fortolkes 'CVR:46837428' som et CVR nummer med værdien 46837428
• Værdier med typen CERT: I eksemplet ovenfor fortolkes 'CERT:CVR:33257872-FID:28250866' som whitelisting af certificatet med Subject Serial Number CVR:33257872-FID:28250866.

I forhold til anvenderne, så tjekkes det, om der er en whitelisting af anvenderens CVR nummer og hvis dette ikke er tilfældet, så tjekkes, om det specifikke certifikat, der anvendes er whitelistet. Alle andre forsøg på adgang med niveau 3 Idkort afvises.

Dokumenttype konfiguration af registry

For at konfigurere hvilke dokumenttyper, der er relevante for et givet registry, skal dette konfigureres manuelt af driften i documenttype_configuration databasen:

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.

Feature konfiguration af registry

For at konfigurere hvilke feature, der er relevante for et givet registry, skal dette konfigureres manuelt af driften i feature_configuration databasen:

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.

Pt er ovenstående 3 features mulige. De anvendes, når der laves en ITI-18 søgning (Registry Stored Query). Hvis det indkomne request ikke matcher opsætningen for et givet registry, søges der ikke ned i dette registry. Dvs. at har et registry ingen opsætning af query types, bliver det aldrig kaldt.

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.

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:

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.

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");

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

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.

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.

Hvis der ikke kan findes en opsætning i databasen for en given typecode, classcode og formatcode kombination, skrives en warning til applikationsloggen, så man har mulighed for at holde øje med anvendte, men ikke konfigurerede kombinationer.

Ved hentning af dokumenter (iti-43) anvendes altid værdierne fra property filen.

Hvis den fremfundne minlog tekst overstiger den maksimale længde, som minlog kan modtage (pt 75 karakterer), afkortes teksten og en fejl skriver i applikationsloggen. For lange tekster fejlmeldes også i forbindelse med servicens status endpoint. Her vil det fremgå, hvis mindst en minlog tekst er for lang (kan være en kombinationer af tekst og den tilføjede brugertype tekst). Alle ugyldige tekster kan efter kald til status endpoint findes som fejl i applikationsloggen.

DKS konfiguration

Test af DKS

Efter konfiguration og deployering af DDS Registry og Repository servicene, kan DKS-snitfladerne testes med:

Succesfuldt svar giver indholdet svarende til filerne nævnt ovenfor.

Header konfiguration

Det er muligt at konfigurere registry og repository til at lede efter HTTP- og SOAP-headere, og videresende dem til bagvedliggende registries.

Videresendelse styres af databasetabellerne

• For DDS registry:  documentsources.documentregistry_forwarded_header
• For DDS repository: documentsources.documentsource_forwarded_header

Indholdet af tabel documentsources.documentregistry_forwarded_header er som følger:

Indholdet af tabel documentsources.documentsource_forwarded_header er som følger:

DocumentSources konfiguration for DDS repository

For at tilføje et kildesystem til documentsource databasen, bruges følgende 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

• soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:

Værdien 1.2_DGWS_NO_ADDR benyttes, når WS-Addressing ikke ønskes anvendt.

• timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.

• failurethreshold: Angiver grænseværdi for hvor mange kald mod repositoriet der må fejle før monitoreringssnitfladen melder fejl. Angives som heltal.

Kombinationen oid og unique_id_type skal være unik.

Monitorering

Det er muligt at konfigurere grænser for tilladte fejl i et givet tidsrum for de alarm og status check, der findes i DDS'en health endpoints. Se afsnittet "Overvågning" nedenfor.

Overvågning

DDS registry og repository har følgende endpoints til overvågning:

• curl localhost:9090/ddsregistry/status

• curl localhost:9090/ddsregistry/alarm

• curl localhost:9091/ddsrepository/status

• curl localhost:9091/ddsrepository/alarm

Generelt omkring status endpointet:

• Returnerer status HTTP 200, hvis DDS'en kan modtage forespørgsler, og 500 hvis den ikke er i stand til det.
• Returnerer tekst i json format
• Eksempel på status check er adgang til database og gyldig certifkat for kald til backends
• Eksempel på relevant driftinformation information, der returneres er f.eks. servicens version og tidspunkt for certifikat udløb

Status omkring alarm endpoint:

• Returnerer HTTP 500, hvis der er aktive alarmer og ellers HTTP 200.
• Returnerer tekst i text/plan format. 
• Der returneres kun tekst, hvis der en alarm. Hver alarm skrives på sin egen linie.
• En klassisk alarm holder øje med kald til ekstern service i et givet tidsrum og melder fejl, hvis antal fejl bliver for højt.

Eksempel på status tekst, når alt er godt.

200 ok

{ "Servicens certifikat udløber den 2025-11-28T10:30:24":"OK", "Database DocumentSourcesDataSource":"OK", "Database AuthDataSource":"OK", "Version":"2.7.4" }

Eksempel på alarm tekst, når der har været for mange kald til person information uden svar:

500 Internal Server Error

Person Information servicen har fejlet flere gange end tilladt i en given periode.

HealthIndictors

I den følgende tabel gives et overblik over de forskellige status og alarm check. Efterfølgende er enkelte af de forskellige check uddybet for relevant.

En Healthindicator kan være enten status- eller alarmindicator. Eller både og.  Hvis tabellens celler er tomme for status eller alarm, betyder dette at den ikke er implementeret for den pågældende healthindicator.

Forklaring til tabellen:

• HealthIndicator: navn på healthIndicator. Dette er også navnet på klassen i sourcekoden
• Udførsel: det tjek der udføres ved health checket
• Status 200: Den tekst status og/eller alarm returnerer ved kald når tjekket går godt
• Status 500: Den tekst status og/eller alarm returnerer ved kald når tjekket fejler
• Konfiguration (property) er den opsætning, der kan påvirke healthindicatoren. Typisk properties (default værdi står efter ":") og i enkelte tilfælde database opsætning.

DatasourceHealthIndicator - konfiguration af databasemonitorering

Databasemonitorerings healthindicatorerne laver en simpel query mod databasen. Denne query er justerbar og kan ændres i servicenes property filer.

DDSRegistry.properties:

documentsourcesds.statement=SELECT * FROM documentsources.documentregistry LIMIT 1;
authds.statement=SELECT * FROM stamdata.autreg LIMIT 1;
whitelist.statement=SELECT 1 FROM dual;

DDSRepository.properties:

documentsourcesds.statement=SELECT * FROM documentsources. documentsource LIMIT 1;
authds.statement=SELECT * FROM stamdata.autreg LIMIT 1;
whitelist.statement=SELECT 1 FROM dual;

HealthIndicatorer, der overvåger fejlkald over tid

En række af healthindacatoerne har mulighed for konfiguration af tolerance og duration:

*.error.tolerance=0

*.errorcount.duration=PT10M

Tolerance angiver, hvad grænsen for fejl er. Overstiger antal fejl det angivne, kommer der en alarm ved kald af alarm endpointet.

Duration angiver, hvor lang en periode, der skal kigges i efter antallet af fejl.

Specielt for BackendRegistryHealthIndicator og BackendRepositoryHealthIndicator er, at tolerance findes i databasetabellerne documentregistry henholdsvis documentsource.

Logfiler og fortolkning af disse

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.

DDS Registry:

DDS Repository:

SLA log

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 og Repository logges alle kald til DDSRegistryWS henholdsvis DDSRepositoryWS, 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:

• DocumentRegistry_RegistryStoredQuery

SLA-logpunkter for udgående kald fra DDS Registry:

For SLA-logning af udgående kald til XDS Registry:

• logges i feltet GenericCallParms desuden det konfigurerede navn for XDS Registry under parameternavnet registryFriendlyName.
• logges fejlet kald, på trods af succesfuldt kald, når en eller flere af følgende XDS-fejl/advarsler er indlejret i XDS-fejlstrukturen i svaret:
  • XDSMissingHomeCommunityId
  • XDSRegistryBusy
  • XDSRegistryError, medmindre der er tale om advarsel om tilbageholdte oplysninger grundet samtykker
  • XDSRegistryOutOfResources
  • XDSUnavailableCommunity
  • XDSUnknownCommunity

SLA-logpunkter for indkommende kald til DDS Repository:

• DocumentRepository_RetrieveDocumentSet

SLA-logpunkter for udgående kald fra DDS Repository:

For SLA-logning af udgående kald til XDS Repository:

• logges i feltet GenericCallParms desuden det kaldte XDS Repository’s repositoryUniqueId under parameternavnet repositoryUniqueId.

• logges fejlet kald, på trods af succesfuldt kald, når en eller flere af følgende XDS-fejl/advarsler er indlejret i XDS-fejlstrukturen i svaret:

  • XDSMissingHomeCommunityId

  • XDSRepositoryBusy

  • XDSRepositoryError, medmindre der er tale om advarsel om tilbageholdte oplysninger grundet samtykker

  • XDSRepositoryOutOfResources

  • XDSUnavailableCommunity

  • XDSUnknownCommunity

  • XDSUnknownRepositoryId

Audit log

Auditlogning foretages med det officielle NSP Audit Log modul.

De forskellige ITI-håndtag logges på følgende måde.

DDS Registry

ITI-18 søgninger logger patient-id, bruger-id, på-vegne-af-id samt hsuid-header 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":"2025-09-10T12:08:32.78Z",
   "category":"dk.sds.nsp.audit.log",
   "audit":{
      "timestamp":"2025-09-10T14:08:32.686+02:00",
      "components":[
         {
            "component":"DDS",
            "contexts":[
               {
                  "context":"documentRegistryAdhocQuery",
                  "information":[
                     {
                        "key":"patient-cpr",
                        "type":"SPI",
                        "value":"0207761919"
                     },
                     {
                        "key":"bruger-cpr",
                        "type":"SPI",
                        "value":"0611809735"
                     },
                     {
                        "key":"queryTypecode",
                        "type":"NPI",
                        "value":"('39289-4^^2.16.840.1.113883.6.1')"
                     },
                     {
                        "key":"queryFormatcode",
                        "type":"NPI",
                        "value":"EMPTY"
                     },
                     {
                        "key":"queryEventCode",
                        "type":"NPI",
                        "value":"EMPTY"
                     },
                     {
                        "key":"queryStartTimeFrom",
                        "type":"NPI",
                        "value":"EMPTY"
                     },
                     {
                        "key":"queryStartTimeTo",
                        "type":"NPI",
                        "value":"EMPTY"
                     },
                     {
                        "key":"queryStopTimeFrom",
                        "type":"NPI",
                        "value":"EMPTY"
                     },
                     {
                        "key":"queryStopTimeTo",
                        "type":"NPI",
                        "value":"EMPTY"
                     },
                     {
                        "key":"queryAvailabilityStatus",
                        "type":"NPI",
                        "value":"('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')"
                     },
                     {
                        "key":"queryDocumententryType",
                        "type":"NPI",
                        "value":"('ondemand'), ('stable')"
                     },
                     {
                        "key":"queryReferenceIdList",
                        "type":"NPI",
                        "value":"EMPTY"
                     },
                     {
                        "key":"document_entry.0.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.0.documentid",
                        "type":"NPI",
                        "value":"0207761919.678401000016005.10001"
                     },
                     {
                        "key":"document_entry.0.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.1.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.1.documentid",
                        "type":"NPI",
                        "value":"5619531150207761919.6052203964123326052.1537974544003"
                     },
                     {
                        "key":"document_entry.1.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.2.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.2.documentid",
                        "type":"NPI",
                        "value":"5619531150207761919.7052203964123326052.1537974544003"
                     },
                     {
                        "key":"document_entry.2.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.3.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.3.documentid",
                        "type":"NPI",
                        "value":"0207761919.6052203964123326052.1537974544003"
                     },
                     {
                        "key":"document_entry.3.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.4.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.4.documentid",
                        "type":"NPI",
                        "value":"0207761919.7052203964123326052.1537974544003"
                     },
                     {
                        "key":"document_entry.4.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.5.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.5.documentid",
                        "type":"NPI",
                        "value":"0207761919.7152203964123326052.1537974544013"
                     },
                     {
                        "key":"document_entry.5.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.6.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.6.documentid",
                        "type":"NPI",
                        "value":"0207761919.7152203964123326052.1537974544113"
                     },
                     {
                        "key":"document_entry.6.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.7.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.7.documentid",
                        "type":"NPI",
                        "value":"0207761919.7152203964123326052.1537974544123"
                     },
                     {
                        "key":"document_entry.7.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.8.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.8.documentid",
                        "type":"NPI",
                        "value":"0207761919.7152203964123326052.1537974544213"
                     },
                     {
                        "key":"document_entry.8.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.9.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.9.documentid",
                        "type":"NPI",
                        "value":"0207761919.7152203964123326052.1537974544223"
                     },
                     {
                        "key":"document_entry.9.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"document_entry.10.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.10.documentid",
                        "type":"NPI",
                        "value":"5619531150207761919.6052203964123326052.1537974544003"
                     },
                     {
                        "key":"document_entry.10.typecode",
                        "type":"NPI",
                        "value":"39289-4"
                     },
                     {
                        "key":"hsuid-header",
                        "type":"SPI",
                        "value":{
                           "assertion":{
                              "issuer":"Aftale",
                              "attributeStatement":{
                                 "attribute":[
                                    {
                                       "attributeValue":"0207761919",
                                       "name":"NSI_CITIZEN_CIVIL_REGISTRATION_NUMBER",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"nsi:HealthcareProfessional",
                                       "name":"NSI_USERTYPE",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"0611809735",
                                       "name":"NSI_ACTING_USER_CIVIL_REGISTRATION_NUMBER",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"33257872",
                                       "name":"NSI_ORG_USING_ID",
                                       "nameFormat":"NSI_SORCODE"
                                    },
                                    {
                                       "attributeValue":"system owner",
                                       "name":"NSI_SYSTEM_OWNER_NAME",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"test aftaler",
                                       "name":"NSI_SYSTEM_NAME",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"1.0",
                                       "name":"NSI_SYSTEM_VERSION",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"MyOrganisation",
                                       "name":"NSI_ORG_RESPONSIBLE_NAME",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"false",
                                       "name":"NSI_CONSENT_OVERRIDE",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"0611809735",
                                       "name":"NSI_RESPONSIBLE_USER_CIVIL_REGISTRATION_NUMBER",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"6QF17",
                                       "name":"NSI_RESPONSIBLE_USER_AUTHORIZATION_CODE",
                                       "nameFormat":null
                                    }
                                 ],
                                 "id":"HSUIDdata"
                              },
                              "issueInstant":1757506112543,
                              "version":2,
                              "id":"HSUID"
                           }
                        }
                     }
                  ]
               }
            ]
         },
         {
            "component":"MinLog2",
            "contexts":[
               {
                  "context":"addRegistrations",
                  "information":[
                     {
                        "key":"added",
                        "type":"SPI",
                        "values":[
                           "0207761919"
                        ]
                     },
                     {
                        "key":"failed",
                        "type":"SPI",
                        "values":[
                           
                        ]
                     }
                  ]
               }
            ]
         }
      ]
   },
   "access":{
      "code":200,
      "duration":80,
      "httpHeaders":{
         "Content-Type":"text/xml;charset=UTF-8",
         "SOAPAction":"urn:ihe:iti:2007:RegistryStoredQuery"
      },
      "httpHost":"localhost",
      "idCardAttributes":{
         "medcom:CareProviderID":"33257872",
         "medcom:CareProviderName":"Sundhedsdatastyrelsen",
         "medcom:ITSystemName":"Service Consumer Test",
         "medcom:UserAuthorizationCode":"6QF17",
         "medcom:UserRole":"7170",
         "sosi:AuthenticationLevel":"4",
         "sosi:IDCardID":"VhwRkWa9ZDJ2atk5igEBsA==",
         "sosi:IDCardType":"user",
         "sosi:IDCardVersion":"1.0.1"
      },
      "method":"POST",
      "path":"/ddsregistry",
      "query":"",
      "port":9090,
      "protocol":"http",
      "reqSize":9424,
      "resSize":57274,
      "soapHeaders":{
         "FlowID":"e4d2aa20-fcaf-44f5-be93-7e29d7acd3d7",
         "Issuer":"TEST1-NSP-STS",
         "MessageID":"AAABmTOHDKgwkxxDbSVdo1NPU0k=",
         "NameID":"urn:uuid:46559bb9-d720-48b7-b9bd-c280915768d0"
      },
      "threadId":"default task-113",
      "time":"2025-09-10T14:08:32.686+02:00",
      "stats":{
         "handlerDuration":10,
         "RequestContentDuration":0,
         "ResponseContentDuration":0,
         "SecurityProtocolRequestDuration":6,
         "SecurityProtocolResponseDuration":1,
         "bufferAllocated":false,
         "usedBuffers":2,
         "activeBuffersInPool":2,
         "idleBuffersInPool":28
      },
      "reqUUID":"1c00db04-3a73-4434-8e0e-9c26eb66930e"
   }
}

DDS Repository

De forskellige ITI-43 operationer logger patient-id, bruger-id, på-vegne-af-id samt hsuid-header og for hvert dokument i returneret svar (der kan være frafiltreret dokument(er) pga. samtykker, der kan være forespurgt dokumenter, der ikke er tilgængelige): requestens uniqueId, repositoryUniqueId, homeCommunityId.

Se eksempel nedenfor:

{
   "time":"2025-09-10T12:08:33.026Z",
   "category":"dk.sds.nsp.audit.log",
   "audit":{
      "timestamp":"2025-09-10T14:08:32.94+02:00",
      "components":[
         {
            "component":"DDS",
            "contexts":[
               {
                  "context":"documentRepositoryRetrieveDocumentSet",
                  "information":[
                     {
                        "key":"patient-cpr",
                        "type":"SPI",
                        "value":"0207761919"
                     },
                     {
                        "key":"bruger-cpr",
                        "type":"SPI",
                        "value":"0611809735"
                     },
                     {
                        "key":"document_entry.0.homecommunityid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.0.repositoryid",
                        "type":"NPI",
                        "value":"1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key":"document_entry.0.documentid",
                        "type":"NPI",
                        "value":"5619531150207761919.6052203964123326052.1537974544003"
                     },
                     {
                        "key":"hsuid-header",
                        "type":"SPI",
                        "value":{
                           "assertion":{
                              "issuer":"Aftale",
                              "attributeStatement":{
                                 "attribute":[
                                    {
                                       "attributeValue":"0207761919",
                                       "name":"NSI_CITIZEN_CIVIL_REGISTRATION_NUMBER",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"nsi:HealthcareProfessional",
                                       "name":"NSI_USERTYPE",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"0611809735",
                                       "name":"NSI_ACTING_USER_CIVIL_REGISTRATION_NUMBER",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"33257872",
                                       "name":"NSI_ORG_USING_ID",
                                       "nameFormat":"NSI_SORCODE"
                                    },
                                    {
                                       "attributeValue":"system owner",
                                       "name":"NSI_SYSTEM_OWNER_NAME",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"test aftaler",
                                       "name":"NSI_SYSTEM_NAME",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"1.0",
                                       "name":"NSI_SYSTEM_VERSION",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"MyOrganisation",
                                       "name":"NSI_ORG_RESPONSIBLE_NAME",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"false",
                                       "name":"NSI_CONSENT_OVERRIDE",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"0611809735",
                                       "name":"NSI_RESPONSIBLE_USER_CIVIL_REGISTRATION_NUMBER",
                                       "nameFormat":null
                                    },
                                    {
                                       "attributeValue":"6QF17",
                                       "name":"NSI_RESPONSIBLE_USER_AUTHORIZATION_CODE",
                                       "nameFormat":null
                                    }
                                 ],
                                 "id":"HSUIDdata"
                              },
                              "issueInstant":1757506112831,
                              "version":2,
                              "id":"HSUID"
                           }
                        }
                     }
                  ]
               }
            ]
         },
         {
            "component":"MinLog2",
            "contexts":[
               {
                  "context":"addRegistrations",
                  "information":[
                     {
                        "key":"added",
                        "type":"SPI",
                        "values":[
                           "0207761919"
                        ]
                     },
                     {
                        "key":"failed",
                        "type":"SPI",
                        "values":[
                           
                        ]
                     }
                  ]
               }
            ]
         }
      ]
   },
   "access":{
      "code":200,
      "duration":73,
      "httpHeaders":{
         "Content-Type":"text/xml;charset=UTF-8",
         "SOAPAction":"urn:ihe:iti:2007:RetrieveDocumentSet"
      },
      "httpHost":"localhost",
      "idCardAttributes":{
         "medcom:CareProviderID":"33257872",
         "medcom:CareProviderName":"Sundhedsdatastyrelsen",
         "medcom:ITSystemName":"Service Consumer Test",
         "medcom:UserAuthorizationCode":"6QF17",
         "medcom:UserRole":"7170",
         "sosi:AuthenticationLevel":"4",
         "sosi:IDCardID":"YRKgDAkQUL4n2svL+G9JWA==",
         "sosi:IDCardType":"user",
         "sosi:IDCardVersion":"1.0.1"
      },
      "method":"POST",
      "path":"/ddsrepository",
      "query":"",
      "port":9091,
      "protocol":"http",
      "reqSize":8747,
      "resSize":12670,
      "soapHeaders":{
         "FlowID":"e7be2b98-212b-44a3-a2cd-8c9fc91cd103",
         "Issuer":"TEST1-NSP-STS",
         "MessageID":"AAABmTOHDamrJmpBR/TEJlNPU0k=",
         "NameID":"urn:uuid:46559bb9-d720-48b7-b9bd-c280915768d0"
      },
      "threadId":"default task-65",
      "time":"2025-09-10T14:08:32.94+02:00",
      "stats":{
         "handlerDuration":10,
         "RequestContentDuration":0,
         "ResponseContentDuration":0,
         "SecurityProtocolRequestDuration":7,
         "SecurityProtocolResponseDuration":1,
         "bufferAllocated":false,
         "usedBuffers":2,
         "activeBuffersInPool":2,
         "idleBuffersInPool":18
      },
      "reqUUID":"41dd9a97-0998-4cdb-91b7-e08be4a1d5bf"
   }
}

Standard fejlsøgning

• Ved problemer med indlæsning af servicens konfigurationsfiler (DDSRegistry.properties og DDSRepository.properties

For SLA-logning af udgående kald til XDS Registry:

• logges i feltet GenericCallParms desuden det konfigurerede navn for XDS Registry under parameternavnet registryFriendlyName.
• logges fejlet kald, på trods af succesfuldt kald, når en eller flere af følgende XDS-fejl/advarsler er indlejret i XDS-fejlstrukturen i svaret:
  • XDSMissingHomeCommunityId
  • XDSRegistryBusy
  • XDSRegistryError, medmindre der er tale om advarsel om tilbageholdte oplysninger grundet samtykker
  • XDSRegistryOutOfResources
  • XDSUnavailableCommunity
  • XDSUnknownCommunity

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: