Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Property

Beskrivelse

dros.url.prefix

URL prefix der indsættes i wsdl'er og bruges af dks-servlet.

dros.app.nameAnvendes af dks-servlet
dros.serviceidentifierAnvendes af dks-servlet. Inkluderes i endpoint og action (serviceIdentifier)

iti41.service.endpoint

Endpoint på ITI41-backend.
iti41.service.security.require.person

Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false)

Default: false

iti41.service.xds.validationlevel

Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier.

iti42.service.endpointEndpoint på ITI42-backend.
iti42.service.security.require.person

Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false)

Default: false

iti42.service.xds.validationlevelAngiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier.

iti57.service.endpoint

Endpoint på ITI57-backend.
iti57.service.security.require.person

Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false)

Default: false

iti57.service.xds.validationlevelAngiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier.
iti61.service.endpointEndpoint på ITI61-backend.
iti61.service.security.require.person

Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false)

Default: false

iti61.service.xds.validationlevelAngiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier.

dros.backend.failure.threshold

Tærskel for, hvor mange gang i træk et kald til en backend må fejle, før denne backend betragtes som 'død' af status-siden.

dros.backend.failure.interval.minutesAngiver antal minutter hvorefter fejlkald 'forældes'. Dermed er det kun fejlkald, der er nyere end dette, der medregnes, når det vurderes om backenden fejler. 
cprexists.validationlevel

Valideringsniveau for CPR validering

Eksempel: WARNING, REJECT, OFF

cprexists.url

URL for CPR exist service

Eksempel: http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-cprexists

cprexists.maxTotalConnections

Konfiguration af client pool til kald af CPRExists service

Default: 200

cprexists.defaultMaxConnectionsPerRoute

Konfiguration af client pool til kald af CPRExists service

Default: 20

handled.type.codes

Angiver en liste af, hvilke type codes DROS håndterer. Er listen tom (property findes, men ingen værdi efter =) accepteres alle type codes.

Eksempel på liste: 39289-4,39290-2,53576-5,52460-3,81215-6

Default: tom liste

 

For alle nedenstående properties, som starter med validation. og slutter på .codes gælder følgende:

Disse properties anvendes til at konfigurerer XDS validerings biblioteket med.

En kode består af 3 elementer: value, system og displayname. Disse adskilles med ¤$. Hver sæt af koder adskilles med #. 

Der er muligt at angive wildcards og det kan man gøre på to niveauer:

  • Indenfor et sæt kan man angive "null" hvis man tillader alle værdier for et specifikt element
    F.eks. fra class codes nedenfor: validation.class.codes=null¤1null$1.2.208.184.100.9¤null#9$null#. Her er der kun krav til "system" værdien.
  • Hvis en kode tillader alle værdier, kan det angives med værdien "*", ved at lade listen være tom  eller ved slet ikke at angive propertien i property filen.
    F.eks. fra format codes nedenfor: validation.format.codes=*. Her kan alle format codes anvendes.
validation.class.codes

Angiv tilladte class koder

Eksempel: null¤1null$1.2.208.184.100.9¤null#9$null#
Alle class koder fra systemet 1.2.208.184.100.9 er tilladste.

validation.confidentiality.codes

Angiv tilladte confidentiality codes. Typisk kun N

Eksempel: N¤2N$2.16.840.1.113883.5.25¤null#25$null#
Classcode N fra systemet 2.16.840.1.113883.5.25 tilladt.

validation.organisation.codes

Angiv tilladte organizations koder. Her angives typisk kun skema.

Eksempel:  null¤1 null$1.2.208.176.1.4¤null#null¤14$null#null$1.2.208.176.1.1¤null#1$null#
Organizationskoder fra system 1.2.208.176.1.4 eller 1.2.208.176.1.1 er tilladte, som er Yder og SOR

validation.patientid.codes

Angiv tilladte patientid. Her angives typisk kun skema.

Eksempel: null¤1null$1.2.208.176.1.2¤null#2$null#
Patientider fra systemet 1.2.208.176.1.2 er tilladte, som er CPR.

validation.format.codes

Angive tilladte format koder

Eksempel: *
Alle format koder er tilladte

validation.healthcarefacilitytype.codes

Angive tilladte healthcarefacilitytype koder

Eksempel: *
Alle healthcarefacilitytype koder er tilladate

validation.practicesetting.codes

Angiv tilladte practicesetting koder

Eksempel: *
Alle practicesetting koder er tilladte

validation.event.codes

Angiv tilladte event koder

Eksempel: null¤1null$1.2.208.176.2.4¤null#4$null#
Alle event koder fra systemet 1.2.208.176.2.4 er tilladte

validation.type.codes

Angiv tilladte type koder

Eksempel: 39289-4¤24$2.16.840.1.113883.6.1¤null#1$null#
Type koden 39289-4 fra systemet 2.16.840.1.113883.6.1 er tilladt.

validation.cda.type.codes

Angiv de type koder, som er af typen CDA.
Dette har betydning for validering af et ITI-41 kald. Hvis et dokuments har en af disse type koder angivet i metadata vil det tilhørenende dokument blive parset som CDA og valideret tilsvarende.

Eksempel: 39289-4¤24$2.16.840.1.113883.6.1¤null#1$null#

log4j konfiguration

Log4j konfiguration findes i samme wildfly modul som servicekonfigurationen

...

Hvis CPR validering kører i WARNING mode, så vil ugyldige (ifølge CPRExits service) CPR numre give anledning til en linje i auditloggen. Logninger af denne type ser således ud:

...