...

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 gør brug af XdsValidationl, kan man her finde yderligere inspiration for implementering, hvis man som ekstern anvender ønsker at gøre brug af XDS validering. Dette dokument beskriver overordnet tilgængelighed af modulet samt anvendelse.

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 vise 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.

Anvendelse

Bibliteket benyttes ved at instansiere den ønskede validerings factory og efterfølgende kalde validate på den.

Der findes valideringer på følgende kald

• iti-41 - registrering af dokument og metadata  (dokumenter med fast indhold)
• iti-42 - registrering af metadata for dokument(er)
• iti-57 - opdatering af registrerede metadata - herunder deprecate
• iti-61 - registrering af metadata for dokument(er) med dynamisk (On-demand) indhold

Desuden kan et CDA dokuments indhold valideres.

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.

...

Image Added

Men for at lette arbejdet med bibliotekt, findes der en default opsætning per område, som det anbefales at arbejde med (såkaldet 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 består af en ud af 4 typer. Navngivning samt hvilken klasse den extender bestemmer dette)

Validator

En almindelig validering. Den består af en validering, samt mulighed for at angive "under-validatorerer" samt indikation af om disse "under-validateror" skal køres, hvis den egen validering fejler. 

Man kan altså med denne validator gruppere en række valideringer, som man ønskes udført efter hinanden, baseret på validatorens egen udfald.

Et eksempel på sådan en validering er Apd2StartStopTimeValidator. Den tjekker på 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:
Apd2StartStopTimeValidator apd2StartStopTimeValidator = new Apd2StartStopTimeValidator();

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

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

ModelEnricher

valideringen består af udpakning af noget input. Denne "berigelse" sættes på det indkomne objekt (deraf ModelEnricher) og senere validatorer kan så arbejde herpå

AtLeastOneValidator

adskiller sig fra en alminelig validator ved, at den kræver at mindst een af dens under-validatorer vil kendes ved input

Starter

adskiller sig fra en ModelEnricher ved, at den ikke modtager det fælles objekt XDSDocument, men istedet en request type. Dette request pakkes ud i et eller flere XDSDocument objekter, og Starter kører så sine under-validatorer på hver af disse objekter.

Eksempel fra DROS

Følgende kode, består af 3 trin.

...

ProvideAndRegisterDocumentSetStarter subject = Iti41ValidationFactory.createIti41Validator();

ProvideAndRegisterDocumentSet provideAndRegisterDocumentSetInput = provideAndRegisterDocumentSetCreator.createProvideAndRegisterDocumentSetApd();

ValidationResultSet validationOutput = subject.validate(provideAndRegisterDocumentSetInput);

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 valideringsreglser