Page History
...
- indholdet af et CDA dokument (generelt set, dvs headeren)
- 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
- indholdet af et iti41 kald (provide and register document set / registrer metadata)
- indholdet af et iti42 kald (register document set / registrer metadata)
- indholdet af et iti61 kald (register document set / regisgterr metadata on-demand)
- 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.
Figur: kæde- eller træstruktur
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 er implementeret som en ud af 4 typer. (Navngivning samt hvilken klasse den extender bestemmer illustrerer dette dette)
Validator
En almindelig validering. Den består af en validering, samt mulighed for at angive "under-validatorerer" samt indikation af om disse "under-validaterorvalidatorer" skal køres, hvis den dens 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 eget 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:
...
Det som kendetegner en almindelig validator er extension af klassen AbstractValidatorImpl.
AtLeastOneValidator
Denne validator har lidt 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.
Man kan altså med denne validator sikre
Et eksempel
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
CdaDocumentTypeValidator cdaDocumentTypeValidator = new CdaDocumentTypeValidator();
CdaDocumentApdV2ModelEnricher cdaDocumentApdV2ModelEnricher = new CdaDocumentApdV2ModelEnricher();
cdaDocumentTypeValidator.appendValidator(cdaDocumentApdV2ModelEnricher);
Apd2StartStopTimeValidator apd2StartStopTimeValidator = new Apd2StartStopTimeValidator();
cdaDocumentApdV2ModelEnricher.appendValidator(apd2StartStopTimeValidator);
Apd2AppointmentIdValidator apd2AppointmentIdValidator = new Apd2AppointmentIdValidator();
cdaDocumentApdV2ModelEnricher.appendValidator(apd2AppointmentIdValidator);
Apd2CustodianIdValidator apd2CustodianIdValidator = new Apd2CustodianIdValidator(organisationCodeValidation);
cdaDocumentApdV2ModelEnricher.appendValidator(apd2CustodianIdValidator); |
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.
...