...

Indhold:

Indledning

På NSP deles i dag CDA dokumenter flere forskellige dokument typer vha. en XDS infrastruktur. Et CDA dokument er et struktureret XML dokument, som følger en bestemt standard for kliniske dokumenter. Der findes forskellige typer af CDA dokumenter, hvor der er lavet danske profileringer (Udgivelser), som dækker følgende:

• Appointment Document (APD) til aftaler
• Careplan (CPD)
• Personal Data Card/Stamkort (PDC)
• Personal Health Monitoring Report (PHMR) til hjemmemonitorering
• Questionnaire Form Definition Document (QFDD) og Questionnaire Response Document (QRD) til patientrapporterede oplysninger (PRO)

Fælles for alle dokumenterne er et fælles CDA header format, der indeholder metadata om dokumentet. Denne skal overholde standarden for den danske profilering af metadata (XDS Metadata for Document Sharing. Danish profile).  Ligesom data i headeren skal findes i den fælles liste over tilladet værdisæt (DK-IHE_Metadata-Common_Code_systems-Value_sets). 

Metadata skal overholde standarden for den danske profilering af metadata (XDS Metadata for Document Sharing. Danish profile).  Ligesom data i headeren skal findes i den fælles liste over tilladet værdisæt (DK-IHE_Metadata-Common_Code_systems-Value_sets). 

Dokumenter, som gemmes i XDS infrasktrukturen, registreres under deres metadata - herunder dokumentid, og kan fremsøges ud fra disse igen. Det registerede metadata er underlagt samme standarder, som de indeholdte dokumenter Dokumenter, som gemmes i XDS infrasktrukturen, registreres under deres metadata - herunder dokumentid, og kan fremsøges ud fra disse igen. Det registerede metadata er underlagt samme standarder, som CDA dokumenterne selv er,  dvs. de skal overholde de danske standarder.

For at gemme eller hente et dokument, anvendet et ITI kald. ITI kald er standardiserede SOAP services, der overholder IHE XDS specifikationen. Et ITI kald opererer med begreberne SubmissionSet, DocumentEntry og Association, hvis indhold lægger sig op af dokumentets metadata. Disse skal derfor også overholde standarderne.

Yderligere detaljer og introduktion til dokumentdeling kan læses i Dokumentdeling på NSP. 

For at lette arbejdet med at overholde/validerere for standarderne, findes XdsValidation biblioteket. DROS komponenten kan gøre Flere komponenter, bl.a. DROS, gør brug af denne validering, for at sikre, at der ikke komme ugyldige data ind i XDS infrastrukturen.  Anvendere af DROS kan selv implementere validering vha. af XdsValidation biblioteket, hvis man ønsker at finde fejl, inden det faktiske kald udføres.  Alle, der er koblet på NSP XDS infrastrukturen med enten registry eller repository eller som har sit eget affinitetsdomæne, kan med fordel anvende XdsValiderings biblioteket. Også som supplement til eventuel egen validering.

...

For at anvende XdsValidation biblioteket, skal man gøre brug af tredjepartsproduktet IPF Open eHealth Integration Platform, da interaktionen foregår vha. dette.

Da DROS, som nævnt Yderligere inspiration for implementering af validering kan findes i DROS projektet, da dette projekt allerede gør brug af XdsValidation, kan man her finde yderligere inspiration for implementering der..

Dette dokument beskriver overordnet funktionalitet af biblioteket.

API Beskrivelse og anvendelse

XdsValidation biblioteket kan overordnet validere følgende:

1. indholdet af et CDA dokument (generelt set, dvs headeren)
2. indholdet af et CDA dokument for en specifik type (APD v2, PHMR og QRD). Dette er stadig under udarbejdelse og anvendelsen er pt begrænset
3. indholdet af et iti41 kald (provide and register document set / registrer metadata)
4. indholdet af et iti42 kald (register document set / registrer metadata)
5. indholdet af et iti61 kald (register document set / regisgterr metadata on-demand)
6. indholdet af et iti57 kald (opdater metadata - herunder deprecate status)

Biblioteket består af en række valideringsregler/klasser, som kan sættes sammen efter behov. Det er muligt at sætte en validering sammen, som en lang kæde, eller lave en træstruktur, sådan at visse valideringer, stopper for yderligere validering i specifikt område. Sidstnævnte kan f.eks. være, at hvis et dokument ikke er en kendt CDA type, så behøver man ikke validerere yderligere på dets metadata.

Image Removed

Figur: kæde- eller træstruktur

For at lette arbejdet med bibliotekt, findes der en default opsætning per område, som det anbefales at arbejde med (såkaldt factories). Se figuren "Validator overblik" i design og arkitekturdokumentet, for en overblik over disse. Hvordan disse factories anvendes er beskrevet i næste afsnit.

Hver valideringsregel er implementeret som en ud af fire typer (Navngivning samt hvilken klasse den extender, illustrerer dette dette). Disse er beskrevet i det efterfølgende.

En valideringsregel returnerer enten null (hvis den ikke forstår det input den modtager) eller et object ValidationResultSet. ValidationResultSet kan indholde en række fejl, hvis sådanne er fundet under valideringen.

Validator

En almindelig validering. Den består af en validering, samt mulighed for at angive under-validatorer samt indikation af, om disse under-validatorer skal udføres, hvis validatorens egen validering fejler. 

Man kan altså med denne validator gruppere en række valideringer, som man ønsker udført efter hinanden, baseret på validatorens eget udfald. Den almindelige validator returner så, den fulde mængde af resultater/fejl fundet.

CDA

Et CDA dokument er et struktureret XML dokument, som følger en bestemt standard for kliniske dokumenter. Der findes forskellige typer af CDA dokumenter, hvor der er lavet danske profileringer (Udgivelser), som dækker følgende:

• Appointment Document (APD) til aftaler
• Careplan (CPD)
• Personal Data Card/Stamkort (PDC)
• Personal Health Monitoring Report (PHMR) til hjemmemonitorering
• Questionnaire Form Definition Document (QFDD) og Questionnaire Response Document (QRD) til patientrapporterede oplysninger (PRO)

Fælles for alle dokumenterne er et fælles CDA header format, der indeholder metadata om dokumentet.

Audio

Et audio dokument er et struktureret XML dokument, som følger HIMSA’s Noah datastandarder. Der findes forskellige typer af audio dokumenter (Udgivelser), hvor følgende dækkes:

• Audiogram Format
  • Audiogram Format 502 
  • Audiogram Format 500
• Admittance Format
  • Admittance Format 501
  • Impedance Format 500
• Hearing Instrument Selection
  • Hearing instrument selection format 500

Hver type og version har et selvstændigt XSD skema, der skal overholdes.

API Beskrivelse og anvendelse

XdsValidation biblioteket kan overordnet validere følgende:

1. indholdet af et CDA dokument (generelt set, dvs headeren)
2. indholdet af et CDA dokument for en specifik type (APD v2, PHMR og QRD). Dette er stadig under udarbejdelse og anvendelsen er pt begrænset
3. indholdet af et Audio dokument for en specifik type (Audiogram, Impedance/Admittance og HearingInstrumentSelection). Dette er stadig under udarbejdelse og anvendelsen er pt begrænset
4. indholdet af et iti41 kald (provide and register document set / registrer metadata)
5. indholdet af et iti42 kald (register document set / registrer metadata)
6. indholdet af et iti61 kald (register document set / regisgterr metadata on-demand)
7. indholdet af et iti57 kald (opdater metadata - herunder deprecate status)

Biblioteket består af en række valideringsregler/klasser, som kan sættes sammen efter behov. Det er muligt at sætte en validering sammen, som en lang kæde, eller lave en træstruktur.

Image Added

Figur: kæde- eller træstruktur

For at lette arbejdet med bibliotekt, findes der en default opsætning per område, som det anbefales at arbejde med (såkaldt factories). Se figuren "Validator overblik" i design og arkitekturdokumentet, for en overblik over disse. Hvordan disse factories anvendes er beskrevet i næste afsnit.

Hver valideringsregel er implementeret som en ud af tre typer (Navngivning samt hvilken klasse den extender, illustrerer dette dette). Disse er beskrevet i det efterfølgende.

En valideringsregel returnerer  et object ValidationResultSet. ValidationResultSet kan indholde en række fejl, hvis sådanne er fundet under valideringen.

Validator

En almindelig validering. Den består af en validering samt kald af dens under validatorer. 

Man kan altså med denne validator gruppere en række valideringer, som man ønsker udført efter hinanden. Den almindelige validator returner så, den fulde mængde af resultater/fejl fundet.

Et eksempel på sådan en validering er Apd2StartStopTimeValidator. Den tjekker om ServiceStartTime på et aftaledokument er Et eksempel på sådan en validering er Apd2StartStopTimeValidator. Den tjekker om ServiceStartTime på et aftaledokument er udfyldt,  Den har ikke nogen under-validatorer i default opsætningen for ITI41 kaldet. Men på sigt kunne disse tilføjes, hvis der opstår behov for specifikke regler omkring StartTime valideringen, når den er udfyldt. Se følgende eksempel:

//nuværende eksempel på almindelig felt validering:
Apd2StartStopTimeValidator apd2StartStopTimeValidator = .add(new Apd2StartStopTimeValidator();)

//fremtidigt eksempel med yderligere validering:
Apd2StartStopTimeValidator apd2StartStopTimeValidator = .add(branch(new Apd2StartStopTimeValidator(false));
Apd2StartStopTimeSpecifikValueValidator  apd2StartStopTimeSpecifikValueValidator = new     .add(new Apd2StartStopTimeSpecifikValueValidator());
apd2StartStopTimeValidator.appendValidator(apd2StartStopTimeSpecifikValueValidator);

Det som kendetegner en almindelig validator er extension af klassen AbstractValidatorImpl.

AtLeastOneValidator

Denne validator har mere logik end en almindelig validator: Den kræver, at mindst een af dens under-validatorer vil kendes ved det input, den får, for at AtLeastOneValidatoren selv validerer noget ok. 

ModelEnricher

Dette er ikke en egentlig validator. "Valideringen" består af udpakning af input.

Man kan se, det er en indirekte validering af, at input forstås og forbedring/berigelse af det data, der arbejdes på. Denne berigelse sættes på det indkomne objekt (deraf ModelEnricher) og senere validatorer, kan arbejde videre med dette.

Man kan på en ModelEnricher også sætte under-validatorer på, ligesom på en almindelig validatorMan kan altså med denne validator gruppere en række valideringer, og forvente, at mindst een af dem vil kendes ved det input, den får. Den/de under-validatorer, som kendes ved input, forventes så at udføre relevant validering.

Et eksempel på sådan en validering ModelEnricher er CdaDocumentTypeValidatorCdaDocumentApdV2ModelEnricher. Den er default konfigureret med en række under-validatorer, der hver især kan håndtere en dokument type. Aktiveres CdaDocumentTypeValidator på et dokument, vil den under-validator, der kendes ved dokumenttypen, sørge for at validere specifikke regler for denne type. Kendes ingen af under-validatorerne ved dokumentindholdet/typen, vil AtLeastOneValidatoren melde en fejl retur. Se følgende eksempel:på CdaDocumentHeaderModelEnricher og modtager et CDA dokument, som den forsøger at pakke ud til et aftaledokument. Herefter kalder den sine under validatorer.

//validering, hvor CdaDocumentTypeValidatorCdaDocumentApdV2ModelEnricher forventerforventes at pakke ensinput ud afog densforstå under-validatorerat vildet kendeser vedet input (dokumentet)aftale dokument.


CdaDocumentTypeValidator cdaDocumentTypeValidator = new CdaDocumentTypeValidator();

CdaDocumentApdV2ModelEnricher cdaDocumentApdV2ModelEnricher = new CdaDocumentApdV2ModelEnricher();
cdaDocumentTypeValidator.appendValidator(cdaDocumentApdV2ModelEnricher);  		

CdaDocumentPhmrModelEnricher cdaDocumentPhmrModelEnricher = new CdaDocumentPhmrModelEnricher();
cdaDocumentTypeValidator.appendValidator(cdaDocumentPhmrModelEnricher);

CdaDocumentQrdModelEnricher cdaDocumentQrdModelEnricher = new CdaDocumentQrdModelEnricher();
cdaDocumentTypeValidator.appendValidator(cdaDocumentQrdModelEnricher);

Det som kendetegner en AtLeastOne validator er extension af klassen AbstractAtLeastOneValidatorImpl.

ModelEnricher

Dette er ikke en egentlig validator. "Valideringen" består af udpakning af input.

Man kan se, det er en indirekte validering af, at input forstås og forbedring/berigelse af det data, der arbejdes på. Denne berigelse sættes på det indkomne objekt (deraf ModelEnricher) og senere validatorer, kan arbejde videre med dette.

Man kan på en ModelEnricher også sætte under-validatorer på, ligesom på en almindelig validator.

 .add(branch(new CdaDocumentHeaderModelEnricher(xdsConfiguration.getCdaTypeCodes()))
         ...
        .comment("APD")
        .add(branch(new CdaDocumentApdV2ModelEnricher())
                .add(new Apd2StartStopTimeValidator())
                .add(new Apd2AppointmentIdValidator())
                .add(new Apd2CustodianIdValidator(codeValidators.getOrganisationCodeValidation()))
        )
        ...
 )

Det som kendetegner en ModelEnricher er extension af klassen AbstractModelEnricherImpl.

Starter

Denne minder om en ModelEnricher, men adskiller sig ved, at den ikke modtager det fælles objekt XDSDocument, som de andre validatorer arbejder med. Den modtager en request type, som pakkes ud i et eller flere XDSDocument objekter, og Starter kører så sine under-validatorer på hver af disse objekter.

Alle valideringer starter derfor med en Starter validering, og al anden validering bygges herpå. Se eksempelvis ProvideAndRegisterDocumentSetStarter for et fuldt eksempelEt eksempel på sådan en ModelEnricher er CdaDocumentApdV2ModelEnricher. Den er default konfigureret på CdaDocumentTypeValidator (se ovenfor for en AtLeastOneValidator) og modtager et CDA dokument, som den forsøger at pakke ud til et aftaledokument. Lykkedes dette, kalder den sine under-validatorer som validerer aftale specikke regler.

//validering, hvor CdaDocumentApdV2ModelEnricherdet forventeshele atinitiers pakkemed inputen udStarter ogvalidering forståtil atet detiti er et aftale dokument.41 kald

CdaDocumentApdV2ModelEnricherValidatorBuilder<ProvideAndRegisterDocumentSetStarter> cdaDocumentApdV2ModelEnricherbuilder = new CdaDocumentApdV2ModelEnricher();

Apd2StartStopTimeValidator apd2StartStopTimeValidator = ValidatorBuilder<>(new Apd2StartStopTimeValidatorProvideAndRegisterDocumentSetStarter();
cdaDocumentApdV2ModelEnricher.appendValidator(apd2StartStopTimeValidator);

Apd2AppointmentIdValidator apd2AppointmentIdValidator = new Apd2AppointmentIdValidator();
cdaDocumentApdV2ModelEnricher.appendValidator(apd2AppointmentIdValidator);

Apd2CustodianIdValidator apd2CustodianIdValidator = new Apd2CustodianIdValidator(organisationCodeValidation);
cdaDocumentApdV2ModelEnricher.appendValidator(apd2CustodianIdValidator);)

Det som kendetegner en ModelEnricher Starter er extension af klassen AbstractModelEnricherImplAbstractStarterImpl.

Starter

Denne minder om en ModelEnricher, men adskiller sig ved, at den ikke modtager det fælles objekt XDSDocument, som de andre validatorer arbejder med. Den modtager en request type, som pakkes ud i et eller flere XDSDocument objekter, og Starter kører så sine under-validatorer på hver af disse objekter.

Alle valideringer starter derfor med en Starter validering, og al anden validering bygges herpå. Se eksempelvis ProvideAndRegisterDocumentSetStarter for et fuldt eksempel.

//validering, hvor det hele initiers med en Starter validering til et iti 41 kald

ProvideAndRegisterDocumentSetStarter provideAndRegisterDocumentSetStarter = new ProvideAndRegisterDocumentSetStarter(); 

Det som kendetegner en Starter er extension af klassen AbstractStarterImpl.

Den gode kombination

Principperne for oprettelse af valideringsregler og sammensætning af disse i struktur, kan skitseres ved:

• Start med en Starter, som forstår input
• Berig input efterhånden som behovet opstår
• Valider kun data, som er relevant. Dvs. anvend træstrukturer
• Tjek relevante overordnede dele er til stede i input (sådan at øvrige senere validatorer kan tillade sig at ignorere dette)
• Er input "uforståligt" så returner ingen ting
• Er input "forståligt" men forkert så returner fejl

Alle ITI kalds default valideringer, som er konfigureret i XdsValidation biblioteket, er sat op efter følgende struktur:

Den gode kombination

Principperne for oprettelse af valideringsregler og sammensætning af disse i struktur, kan skitseres ved:

• Start med en Starter, som forstår input
• Berig input efterhånden som behovet opstår
• Tjek relevante overordnede dele er til stede i input
• Er input "uforståligt" så returner en tom fejlliste
• Er input "forståligt" men forkert så returner fejl

Alle ITI kalds default valideringer, som er konfigureret i XdsValidation biblioteket, er sat op efter følgende struktur:

• Den tilhørende starter vælges (Starter)
• En struktur validator tilknyttes (Validator), som sikrer at et kald indeholder de komponenter, det skal (eksempel for ITI 41 documententry, assocation og selve dokumentet)
• Alle andre relevante validatorer tilføjes. For ITI 41 drejer det sig om følgende træstruktur:
  • XDSDocumentContentModelEnricher (ModelEnricher), der pakker input ud som UTF8 bytes hvis muligt
    • CdaDocumentHeaderModelEnricher, som forsøger at pakke input ud som et CDA dokument ved at finde en CDA header
      • CdaDocumentApdV2ModelEnricher, CdaDocumentPhmrModelEnricher samt CdaDocumentQrdModelEnricher, der forsøger at parse dokumentet som en af typerne APD, PHMR eller QRD
        • Felt specifikke validatorer (Validator) for hver af de 3 dokument typer
    • AudioDocumentModelEnricher, som tjekker på om dokument er validt ift. skema
      • AudioDocumentModelValidator, som tjekker at indhold af dokument er validt.
  • Felt specifikke validatorer (Validator) for documentEntry
  • Felt specifikke validatorer (Validator) for
• Den tilhørende starter vælges (Starter)
• En struktur validator tilknyttes (Validator), som sikrer at et kald indeholder de komponenter, det skal (eksempel for ITI 41 documententry, assocation og selve dokumentet)
• Alle andre relevante validatorer tilføjes. For ITI 41 drejer det sig om følgende træstruktur:
  • XDSDocumentContentModelEnricher (ModelEnricher), der pakker input ud som UTF8 bytes hvis muligt
    • XDSDocumentValidator (AtLeastOneValidator) og CdaDocumentHeaderModelEnricher, som forventer at kunne pakke input ud som et CDA dokument ved at finde en CDA header
      • CdaDocumentTypeValidator (AtLeastOneValidator) og CdaDocumentApdV2ModelEnricher, CdaDocumentPhmrModelEnricher samt CdaDocumentQrdModelEnricher, der forventer, at dokumentet er en af typerne APD, PHMR eller QRD
        • Felt specifikke validatorer (Validator) for hver af de 3 dokument typer
  • Felt specifikke validatorer (Validator) for documentEntry
  • Felt specifikke validatorer (Validator) for SubmissionSet
  • Sammenlignings validatorer per felt (Validator), der sikrer DocumentEntry og SubmissionSet indeholder samme værdier
  • Sammenlignings validatorer per felt (Validator), der sikrer DocumentEntry og dokumentets CDA header indeholder samme værdier

...

En grafisk præsentation af denne konfiguration af default validering kan ses i Design og arkitektur dokumentet. Og den tilhørende java kode findes i klassen Iti41ValidationFactory.

Der er lavet en hjælpe "abstraktion" i source koden, til at lave validerings strukturen, så man kan opbygge den vha. en builder pattern. Se factory metoderne for sådan anvendelse.

Hvordan ændrer man default valideringen

Hvis man ønsker, at ændre i den måde, default valideringen er sat op i XdsValidation biblioteket, enten ved at fjerne valideringsregler eller udvide med sine egne, kan det gøres ved at kopiere den default validering, man ønsker ændret og lave sine justeringer (fjerne eller tilføje regler). Alternativt, hvis man ønsker at lave "strengere" regler på udvalgte områder, kan man udføre default valideringen, og så yderligere have en validering, som alene består af egne valideringsregler (med relevante Starter og ModelEnricher).

...

• Udvikling af egen udvidede validering  i klassen Apd2StartStopTimeSpecifikValueValidator (en almindelig validator vil her være passende som som skabelon)
• Lave en kopi af klassen Iti41ValidationFactory som Iti41ValidationFactoryExtended
• Tilføj egen validering (se eksemplet ovenfor i afsnit 2.1 for "fremtidigt eksempel med yderligere validering"
• Der, hvor man normalt ville bruge Iti41ValidationFactory.createIti41Validator anvender man istedet Iti41ValidationFactoryExtended.createIti41Validator.

Eksempel fra DROS

For at gøre brug af xdsValidation skal følgende dependencies tilføjes til maven pom fil:

<dependency>
	<groupId>dk.nsp</groupId>
	<artifactId>validation-xds</artifactId>
</dependency> 

Hvis man ikke allerede anvender IPF Open eHealth Integration Platform skal følgende dependency tilføjes

<dependency>
	<groupId>org.openehealth.ipf.commons</groupId>
	<artifactId>ipf-commons-ihe-xds</artifactId>
	<version>${openehealth.version}</version>
 </dependency> 
<!-- openehealth.version bør være samme version som XDSValidation anvender -->

Følgende kode er taget fra DROS's validerings logik for ITI 41 kald.

Har man brug for at kunne lave sin egen enricher, og tilhørende opbevaring til en validator senere i flowet kan man gøre følgende

• Opret en klasse, som beskriver det objekt man gerne vil have enricheren til at enriche til
• Opret en enricher i stil med f.eks. CdaDocumentPhmrModelEnricher
  • Dens enrich metode skal modtage XDSDocument som input
  • Den skal oprette et beriget objekt (punkt 1) og  tilføje det til XDSDocument som en "enrichment".
    
    
• Lav de yderligere relevante validatorer, som validererer dette ny enriched object

• Kombiner ekisterende  og nye enrichere og validatorer i en ValidationFactory som beskrevet i afsnittet tidligere.

  Code Block
  language java title Eksempel på anvendelse af eget format
  public static final EnrichmentKey<MyTestDocument> ENRICHMENT_MY_TEST_DOCUMENT = EnrichmentKey.create(MyTestDocument.class); public class MyTestDocument { private String somefield1; private String somefield2; } public class MyTestDocumentModelEnricher extends AbstractModelEnricherImpl<XDSDocument> implements Validator<XDSDocument> { @Override protected ValidationResultSet enrich(XDSDocument input) { ValidationResultSet validationResultSet = new ValidationResultSet(); MyTestDocument myTestClass = new MyTestDocument(); // lav logik som tager relevant indhold fra XDSDocument og pakker det om til MyTestDocument // opstår der fejl kan de returneres i validationResultSet xdsDocument.setEnrichment(ENRICHMENT_MY_TEST_DOCUMENT, myTestClass); return validationResultSet; } } public class MyTestDocumentSomeField1Validator extends AbstractValidatorImpl<XDSDocument> { @Override protected ValidationResultSet validateInternal(XDSDocument input) { ValidationResultSet validationResultSet = new ValidationResultSet();         if (input == null || input.getEnrichment(ENRICHMENT_MY_TEST_DOCUMENT) == null) { return validationResultSet; } // lav logik til validering af input.getEnrichment(ENRICHMENT_MY_TEST_DOCUMENT).getSomeField1(); // hvis fejl returneres de i validationResultSet; return validationResultSet; } }

Eksempel fra DROS

For at gøre brug af xdsValidation skal følgende dependencies tilføjes til maven pom fil:

<dependency>
	<groupId>dk.nsp</groupId>
	<artifactId>validation-xds</artifactId>
</dependency> 

Hvis man ikke allerede anvender IPF Open eHealth Integration Platform skal følgende dependency tilføjes

<dependency>
	<groupId>org.openehealth.ipf.commons</groupId>
	<artifactId>ipf-commons-ihe-xds</artifactId>
	<version>${openehealth.version}</version>
 </dependency> 
<!-- openehealth.version bør være samme version som XDSValidation anvender -->

Følgende kode er taget fra DROS's validerings logik for ITI 41 kald.

// Fra klassen Iti41ValidationImpl metode validateAndTransform
List<ErrorInfo> xdsValidationErrors = getXdsValidationErrors(provideAndRegisterDocumentSet, xdsValidatorFactory.buildIti41Validator(), xdsValidationLevel);

// Fra klassen RegistryItiValidationImpl
protected List<ErrorInfo> getXdsValidationErrors(ProvideAndRegisterDocumentSet request, List<ProvideAndRegisterDocumentSetStarter> starterList, XdsValidationLevel xdsValidationLevel) {
     List<ErrorInfo> errors = new ArrayList<>();
     for (ProvideAndRegisterDocumentSetStarter starter : starterList) {
         List<ErrorInfo> validationErrors = getXdsValidationErrors(request, starter, xdsValidationLevel);
         errors.addAll(validationErrors);
         if (errors.size() > 0) {
             return errors;
         }
     }
     return errors;
}

private List<ErrorInfo> getXdsValidationErrors(ProvideAndRegisterDocumentSet request, ProvideAndRegisterDocumentSetStarter starter, XdsValidationLevel xdsValidationLevel) {
    return getXdsValidationErrors(() -> starter.validate(request), xdsValidationLevel);
}

private List<ErrorInfo> getXdsValidationErrors(Supplier<ValidationResultSet> validator, XdsValidationLevel xdsValidationLevel) {
    if(xdsValidationLevel == XdsValidationLevel.OFF

// Fra klassen Iti41ValidationImpl metode validateAndTransform
List<ErrorInfo> xdsValidationErrors = getXdsValidationErrors(provideAndRegisterDocumentSet, xdsValidatorFactory.buildIti41Validator(), xdsValidationLevel);

// Fra klassen RegistryItiValidationImpl
protected List<ErrorInfo> getXdsValidationErrors(ProvideAndRegisterDocumentSet request, ProvideAndRegisterDocumentSetStarter starter, XdsValidationLevel xdsValidationLevel) {
    return getXdsValidationErrors(() -> starter.validate(request), xdsValidationLevel);
}

private List<ErrorInfo> getXdsValidationErrors(Supplier<ValidationResultSet> validator, XdsValidationLevel xdsValidationLevel) {
     if(xdsValidationLevel == XdsValidationLevel.OFF) {
          return new ArrayList<>();
     }
     List<ErrorInfo> errors = new ArrayList<>();
     // Perform the validation
     ValidationResultSet resultSet = validator.get();
     // Construct the result
     if(resultSet.hasErrors()) {
          // Based on the validation level, either return a warning or an error.
          Severity severity = getSeverity(xdsValidationLevel);
          for(ValidationError ve : resultSet.getErrors()) {
               ErrorInfo errorInfo = new ErrorInfo(ErrorCode.REGISTRY_METADATA_ERROR, ve.getErrorMessage(), severity, "", "");
               errors.add(errorInfo);
          }
     }
     return errors;
}

//Klassen XdsValidatorFactory
public class XdsValidatorFactory {
    public ProvideAndRegisterDocumentSetStarter buildIti41Validator() {
        return Iti41ValidationFactory.createIti41Validator();
    }

    public RegisterDocumentSetStarter buildIti42Validator() {
        return Iti42ValidationFactory.createIti42Validator();
    }

    public RegisterDocumentSetStarter buildIti57Validator() {
        return Iti57ValidationFactory.createIti57Validatornew ArrayList<>();
    }

    List<ErrorInfo> errors public= RegisterDocumentSetStarternew buildIti61ValidatorArrayList<>();
 {
   // Based on the validation level, either return Iti61ValidationFactory.createIti61Validator(); a warning or an error.
    }
}

Dvs ønsker man benytte default valideringen for ITI 41 kaldet gøres det ved at:

1. Oprette en instans af ProvideAndRegisterDocumentSetStarter (linie 2)
2. Kalde metoden validate på denne med ITI 41 requested (ProvideAndRegisterDocumentSet) (linie 6)
3. Retur får man en liste over de fejl XdsValidation fandt (linie 15)

På samme måde kan man få valideret de øvrige kald, ved at vælge den rette Starter og sende requsted ind til den.

// Fra klassen Iti42ValidationImpl metode validateAndTransform
List<ErrorInfo> xdsValidationErrors = getXdsValidationErrors(registerDocumentSet, xdsValidatorFactory.buildIti42Validator(), xdsValidationLevel);

// Fra klassen RegistryItiValidationImpl

protected List<ErrorInfo> getXdsValidationErrors(RegisterDocumentSet request, RegisterDocumentSetStarter starter, XdsValidationLevel xdsValidationLevel) {
    return getXdsValidationErrors(() -> starter.validate(request), xdsValidationLevel); //for getXdsValidationErrors se ovenfor
}

// Fra klassen Iti57ValidationImpl metode validateAndTransform
List<ErrorInfo> xdsValidationErrors = getXdsValidationErrors(registerDocumentSet, xdsValidatorFactory.buildIti61Validator(), xdsValidationLevel);  

// Fra klassen RegistryItiValidationImpl
protected List<ErrorInfo> getXdsValidationErrors(RegisterDocumentSet request, RegisterDocumentSetStarter starter, XdsValidationLevel xdsValidationLevel) {
    return getXdsValidationErrors(() -> starter.validate(request), xdsValidationLevel); //for getXdsValidationErrors se ovenfor
}

// Fra klassen Iti41ValidationImpl metode validateAndTransform
List<ErrorInfo> xdsValidationErrors = getXdsValidationErrors(registerDocumentSet, xdsValidatorFactory.buildIti57Validator(), xdsValidationLevel);

// Fra klassen RegistryItiValidationImpl
protected List<ErrorInfo> getXdsValidationErrors(RegisterDocumentSet request, RegisterDocumentSetStarter starter, XdsValidationLevel xdsValidationLevel) {
    return getXdsValidationErrors(() -> starter.validate(request), xdsValidationLevel); //for getXdsValidationErrors se ovenfor
}  

Se iøvrigt praktisk anvendelse i bibliotekets egne unit test. F.eks. CdaHeaderValidatorTest der viser CDA dokument validering og  ProvideAndRegisterDocumentSetValidatorTest, der viser en række kald for iti-41.

Understøttede valideringsregler

De implementerede valideringsregler er lavet med udgangspunkt i de danske standarder og IHE XDS specifikationen.

Disse regler/standarder refereres på følgende måde::

• IHE Vol3 4.2.3.1.2 Creating Coded Attributes: Henviser til IHE XDS specifikationen volume 3, afsnit 4.2.3.1.2
• DK_IHE_ClassCode_DE: Henviser til til Medcoms fælles liste over tilladet værdisæt faneblad ClassCode_DE
• Metadata-v096 2.2.3 classCode: Henviser til den danske CDA profil afsnit 2.2.3
• DK-APD-v2.0.1: 2.1.10.1 Appointment Date and Time: Henviser til Appointment Document (APD) til aftaler afsnit 2.1.10.1
• DK-QRD-v1.3: 2.2.5 Custodian: Henviser til Questionnaire Response Document (QRD)  afsnit 2.2.5
• PHMR-DK-v1.3 2.13.3 Custodian: Henviser til Personal Healthcare Monitoring Report (PHMR) afsnit 2.13.3

Begreber (entiteter/atributer mm) anvendt i valideringen stammer fra IHE frameworket (documentEntry og SubmissionSet) samt Medcoms Cda builder/parser (anvendes til at parse CDA header og de konkrete danske profileringer).

For nu er følgende valideringer implementeret. Beskrivelserne i tabelkolonnerne "Validering" stammer fra XdsValidationprojektets javadoc og skal vedligeholdes der.

Bemærk det er muligt sortere og filtrere i tabellerne med confluence indbyggede tabelhåndtering. 

(Anvend "mvn javadoc:javadoc" for at generere i target/site folderne for mvn modulerne validation-xds og validation-codes)

Default validering konfiguration

Man kan med fordel tage udgangspunkt i disse konfigurerede valideringer, ligesom DROS gør i ovenstående eksempler. Hvad de hver især dækker fremgår af de følgende afsnit.

...

 Validering af struktur

Dette er validering, som har med struktur at gøre. F.eks. udpakning af information og forventninger til del-elementer.

Afkrydningen i tabellens 5 sidste søjler indikerer, om en given validering er inkluderet i default valideringer, som er konfigureret i XdsValidation biblioteket.

...

• submissionSet pakkes ud
• dokumenter pakkes ud
• der er som minimum et dokument

...

• submissionSet pakkes ud
• dokumentEntries pakkes ud

...

• der findes et documentEntry
• der findes et fysisk dokument
• der findes et submissionSet

...

• der findes et documentEntry
• der findes et submissionSet

...

• der findes et documentEntry
• der findes et submissionSet

...

• der findes et submissionSet

...

• under-validatorne tjekker for dokument type. Default vil det være:
  • CdaDocumentHeaderModelEnricher

...

• under-validatorne tjekker for dokument type. Default vil det være:
  • CdaDocumentHeaderModelEnricher

...

• under-validatorne tjekker for dokument type/ indholdsprofil. Default vil det være:
  • CdaDocumentApdV2ModelEnricher
  • CdaDocumentPhmrModelEnricher
  • CdaDocumentQrdModelEnricher

...

• indhold kan læses som bytes (UTF8)

...

• bytes kan parses som en CDA header

...

• det er et aftale dokument: CodeCodedValue har Codesystem "2.16.840.1.113883.6.1" og code "39289-4"
• det er Cda Header Version 2: FormatCode har Codesystem "1.2.208.184.100.10" og code "urn:ad:dk:medcom:apd-v2.0.1:full"
• CDA dokumentet kan parses som et APD dokument

...

• det er et PHMR dokument: CodeCodedValue har Codesystem "2.16.840.1.113883.6.1" og code "53576-5"
• det er Cda Header Version 1: FormatCode er null (anvendt parser finder ikke formatCode for v1)
• CDA dokumentet kan parses som et PHMR dokument

...

• det er et QRD dokument: CodeCodedValue har Codesystem "2.16.840.1.113883.6.1" og code "74465-6"
• det er Cda Header Version 1: FormatCode er null (anvendt parser finder ikke formatCode for v1)
• CDA dokumentet kan parses som et QRD dokument

...

Typevalideringer

Dette er hjælpevalideringer, som feltvalideringer gør brug af.

...

AbstractElementCompare

...

• sammenligning af 2 lister (hver med nul, en eller flere objekter)
• antal af objekter i listen er ens
• de enkelte objekter er ens på de samme pladser i listen

...

CodedModelCompare

...

• overholder validering i AbstractElementCompare hvor følgende opfylder "objekter er ens"
  • value er ens
  • codeSystem er ens
  • displayName er ens

...

DateTimeCompare

...

• overholder validering i AbstractElementCompare hvor følgende opfylder "objekter er ens"
  
  • dateTime er ens

...

StringCompare

...

• overholder validering i AbstractElementCompare hvor følgende opfylder "objekter er ens"
  • de to strenge er ens

...

CodedValueValidation

...

• regel: IHE Vol3 4.2.3.1.2 Creating Coded Attributes
• codeSystem er udfyldt
• codeSystem er gyldigt
• code er udfyldt

...

StringValidation

...

• overholder regler specificeret af anvender:
  • er udfyldt hvis påkrævet sat
  • længden på værdien er ikke  større end maksimum længde angivet
  • værdien er en af de tilladte værdier angivet

...

ClassCodeValidation

...

• regel: IHE Vol3 4.2.3.1.2 Creating Coded Attributes
• længden på code er ikke  større end 3 (DK_IHE_ClassCode_DE)
• overholder validering i CodedValueValidation. Default gyldigt codeSystem er OID "1.2.208.184.100.9" (DK_IHE_ClassCode_DE). Code, CodeSystem og DisplayName er udfyldt.

...

• regel: IHE Vol3 4.2.3.1.2 Creating Coded Attributes
• code indholder "N" (DK_IHE_ConfidentialityCode_DE)
• overholder validering i CodedValueValidation. Default gyldigt codeSystem er OID "2.16.840.1.113883.5.25" (DK_IHE_ConfidentialityCode_DE). Code og CodeSystem er udfyldt.

...

• regel IHE 4.2.3.1.2 Creating Coded Attributes
• overholder validering i CodedValueValidation. Ingen default gyldig codeSystem.  Code, CodeSystem og DisplayName er udfyldt.

...

• regel: IHE 4.2.3.1.2 Creating Coded Attributes
• overholder validering i CodedValueValidation. Ingen default gyldig codeSystem. Code, CodeSystem og DisplayName er udfyldt.

...

• regel: IHE 4.2.3.1.2 Creating Coded Attributes
• hvis udfyldt er værdien numerisk (DK_HealthcareFacilityType_DE)
• overholder validering i CodedValueValidation. Ingen default gyldig codeSystem. Code, CodeSystem og DisplayName er udfyldt.

...

• overholder validering i StringValidation. Påkrævet og default tilladt værdi er "da-DK" (DK_IHE_LanguageCode_DE)

...

• hvis codeSystem er Yder så er længden på code 6
• hvis codeSystem er Yder er code numerisk
• overholder validering i CodedValueValidation. Default gyldige codeSystemer er "1.2.208.176.1.1" (SOR) og "1.2.208.176.1.4" (YDERNUMMER)

...

• overholder validering i CodedValueValidation. Default gyldigt codeSystem er "1.2.208.176.1.2" (CPR)

...

• regel: IHE 4.2.3.1.2 Creating Coded Attributes
• displayName er udfyldt
• overholder validering i CodedValueValidation. Ingen default gyldig codeSystem.

...

• validering for StringValidation. Påkrævet og default maksimum længde er 128 (Metadata-v096 2.2.31 title)

...

• regel: IHE 4.2.3.1.2 Creating Coded Attributes
• displayName er udfyldt
• validering i CodedValueValidation. Ingen default gyldig codeSystem.

Severity severity = getSeverity(xdsValidationLevel);

    try {
        // Perform the validation
        ValidationResultSet resultSet = validator.get();
        // Construct the result
        if(resultSet.getValidationResults().size() > 0) {
            // Based on the validation level, either return a warning or an error.
            for(ValidationResult vr : resultSet.getValidationResults()) {
                ErrorInfo errorInfo = new ErrorInfo(ErrorCode.REGISTRY_METADATA_ERROR, vr.getValidationError().getErrorMessage(), severity, "", "");
                errors.add(errorInfo);
            }
        }
    } catch (Exception e) {
        // Because validation depends on validation library and builder parsers handling of exceptions we need to make sure any unstable exception handling there will not get to the caller.
        String errorMessage = "Unhandled exception in validation library or its sub dependencies.";
        LOGGER.error(errorMessage, e);
        ErrorInfo errorInfo = new ErrorInfo(ErrorCode.REGISTRY_METADATA_ERROR, errorMessage, getSeverity(xdsValidationLevel), "", "");
        errors.add(errorInfo);
    }
    return errors;
}

//Klassen XdsValidatorFactory
public class XdsValidatorFactory {
 ...
    public List<ProvideAndRegisterDocumentSetStarter> buildIti41Validator() {
        return Arrays.asList(
                Iti41ValidationFactory.createIti41Validator(xdsConfigurationFactory.buildXDSConfiguration()),
                createItiProvideAndRegisterDocumentSetStarterDrosValidator());
    }
  ... 
}

Dvs ønsker man benytte default valideringen for ITI 41 kaldet gøres det ved at:

1. Oprette en instans af ProvideAndRegisterDocumentSetStarter (linie 2)
2. Kalde metoden validate på denne med ITI 41 requested (ProvideAndRegisterDocumentSet) (linie 18)
3. Retur får man en liste over de fejl XdsValidation fandt (linie 31)

På samme måde kan man få valideret de øvrige kald, ved at vælge den rette Starter og sende requsted ind til den.

Se iøvrigt praktisk anvendelse i bibliotekets egne unit test. F.eks. CdaHeaderValidatorTest der viser CDA dokument validering og  ProvideAndRegisterDocumentSetValidatorTest, der viser en række kald for iti-41.

Understøttede valideringsregler

De implementerede valideringsregler er lavet med udgangspunkt i de danske standarder og IHE XDS specifikationen.

Disse regler/standarder refereres på følgende måde::

• IHE Vol3 4.2.3.1.2 Creating Coded Attributes: Henviser til IHE XDS specifikationen volume 3, afsnit 4.2.3.1.2
• DK_IHE_ClassCode_DE: Henviser til til Medcoms fælles liste over tilladet værdisæt faneblad ClassCode_DE
• Metadata-v096 2.2.3 classCode: Henviser til den danske CDA profil afsnit 2.2.3
• DK-APD-v2.0.1: 2.1.10.1 Appointment Date and Time: Henviser til Appointment Document (APD) til aftaler afsnit 2.1.10.1
• DK-QRD-v1.3: 2.2.5 Custodian: Henviser til Questionnaire Response Document (QRD)  afsnit 2.2.5
• PHMR-DK-v1.3 2.13.3 Custodian: Henviser til Personal Healthcare Monitoring Report (PHMR) afsnit 2.13.3

Begreber (entiteter/atributer mm) anvendt i valideringen stammer fra IHE frameworket (documentEntry og SubmissionSet) samt Medcoms Cda builder/parser (anvendes til at parse CDA header og de konkrete danske profileringer).

For nu er følgende valideringer implementeret. Beskrivelserne i tabelkolonnerne "Validering" stammer fra XdsValidationprojektets javadoc og skal vedligeholdes der.

Bemærk det er muligt sortere og filtrere i tabellerne med confluence indbyggede tabelhåndtering. 

(Anvend "mvn javadoc:javadoc" for at generere i target/site folderne for mvn modulerne validation-xds og validation-codes)

Default validering konfiguration

Man kan med fordel tage udgangspunkt i disse konfigurerede valideringer, ligesom DROS gør i ovenstående eksempler. Hvad de hver især dækker fremgår af de følgende afsnit.

De forskellige factories anvender en XDSConfiguration. I XDSConfiguration findes en række kode lister, som anvendes af typevalideringerne (se afsnit nedenfor) til at validere gyldige koder med. Som minimum kan man sætte følgende opsætning ved anvendelse af validerings biblioteket:

• ClassCode: Default gyldigt codeSystem er OID "1.2.208.184.100.9" (DK_IHE_ClassCode_DE).
• ConfidentialityCode: Default gyldigt codeSystem er OID "2.16.840.1.113883.5.25". Gyldig kode er "N". (DK_IHE_ConfidentialityCode_DE)
• OrganisationCode: Default gyldige codeSystemer er "1.2.208.176.1.1" (SOR) og "1.2.208.176.1.4" (YDERNUMMER).
• PatientIdCode: Default gyldigt codeSystem er "1.2.208.176.1.2" (CPR).

Derudover kan man udvide med yderligere værdier for ovenstående og værdier for de andre kodesæt.

Man skal være særlig opmærksom på konfiguration omkring CdaTypeCodes. Denne afgør om et givet dokument skal parses som et CDA dokument. Validerer man dokumenter, der er af CDA typen skal man huske at sætte listen med, hvilke TypeCodes, der faktisk er CDA dokumenter.

Der findes en række metoder på XDSConfiguration objektet til at sætte de forskellige konfigurationer.

Validering af struktur

Dette er validering, som har med struktur at gøre. F.eks. udpakning af information og forventninger til del-elementer.

Afkrydningen i tabellens 5 sidste søjler indikerer, om en given validering er inkluderet i default valideringer, som er konfigureret i XdsValidation biblioteket.

Typevalideringer

Dette er hjælpevalideringer, som feltvalideringer gør brug af.

Krydsvalideringer

Her sammenlignes to entiteter. Disse valideringer sikrer, at de samme felter i forskellige entiteter (documentEntry, submissionSet og Cda dokument) er ens. Hvis mindst en af entiterne kan indholde flere felter af den samme type, sammenlignes antallet af disse også.

Afkrydningen i tabellens 5 sidste søjler indikerer, hvilke default valideringer, den enkelte validator er inkludret i.

Feltvalideringer

Hver validering beskæftiger sig med et specifikt felt i enten ITI kald og/eller CDA dokumentet

Krydsvalideringer

Her sammenlignes to entiteter. Disse valideringer sikrer, at de samme felter i forskellige entiteter (documentEntry, submissionSet og Cda dokument) er ens. Hvis mindst en af entiterne kan indholde flere felter af den samme type, sammenlignes antallet af disse også.

Afkrydningen i tabellens 5 sidste søjler indikerer, hvilke default valideringer, den enkelte validator er inkludret i.

...

• der er lige mange authors (dvs en)
• der er lige mange AuthorInstitutions på den enkelte author
• overholder validering i CodedModelCompare

...

• der er lige mange authors (dvs en)
• overholder validering i StringCompare indholdende personens titel og navne

...

• der er lige mange ConfidentialityCodes (dvs en)
• overholder validering i CodedModelCompare

...

• overholder validering i DateTimeCompare

...

• overholder validering i CodedModelCompare

...

• overholder validering i StringCompare indeholdende languageCode værdierne

...

• overholder validering i StringCompare indeholdende legalAuthenticators titel og navne

...

• overholder validering i CodedModelCompare

...

• overholder validering i DateTimeCompare

...

• overholder validering i DateTimeCompare

...

• overholder validering i CodedModelCompare

...

• overholder validering i StringCompare indeholdende personens titel og navne
• overholder validering i DateTimeCompare med datoer, hvor datoer er fødselsdato
• overholder validering i StringCompare med køn værdierne

...

.

Søjlen "felt" kan anvendes til sortering, hvis man ønsker at se valideringen for et specifik felt på tværs af entitet.

...

• overholder validering i StringCompare indeholdende titel værdierne

...

• overholder validering i CodedModelCompare

...

• ! forudsætning for validering: submissionSet har authors
• der er lige mange authors
• der er lige mange AuthorInstitutions på den enkelte author
• overholder validering i CodedModelCompare

...

• ! forudsætning for validering: submissionSet har authors
• overholder validering i StringCompare indholdende personernes titel og navne
• (indirekte test af at der er lige mange authors qua listen af titel og navne)

...

• value og codeSystem er ens

...

Feltvalideringer

Hver validering beskæftiger sig med et specifikt felt i enten ITI kald og/eller CDA dokumentet.

Afkrydningen i tabellens 5 sidste søjler indikerer, hvilke default valideringer, den enkelte validator er inkludret i.

Søjlen "felt" kan anvendes til sortering, hvis man ønsker at se valideringen for et specifik felt på tværs af entitet.

.