Page History
...
En almindelig validering. Den består af en validering, samt mulighed for at angive " under-validatorerer" validatorer samt indikation af, om disse " under-validatorer " skal køresudføres, hvis dens validatorens egen validering fejler.
Man kan altså med denne validator gruppere en række valideringer, som man ønskes ønsker udført efter hinanden, baseret på validatorens eget udfald. Den almindelige validatorer validator returner så, den fulde mængde af resultater/fejl fundet.
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:
...
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 gruppere en række valideringer, og forvente, at mindst een af dem vil kendes ved det input, den får. Den/de " under-validering" validatorer, som kendes ved input, forventes så at udføre relevant validering.
Et eksempel på sådan en validering er CdaDocumentTypeValidator. 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-validatorne" validatorerne ved dokumentindholdet/typen, vil AtLeastOneValidatoren melde en fejl retur. Se følgende eksempel:
...
Dette er ikke en egentlig validator. "Valideringen" består af udpakning af noget input.
Så Man kan se, det er en indirekte validering af, at input forståes 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 så arbejde herpåvidere med dette.
Man kan på denne en ModelEnricher også sættes "sætte under-validatorer " på, ligesom på en almindelig validator.
Et 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.
...
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 derimod 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.
...
Principperne for oprettelse af validerings regler valideringsregler og sammensætning af disse i struktur er, 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 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 . 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 af en af typerne APD, PHMR eller QRD
- Felt specifikke validatorer (Validator) for hver af de 3 dokument typer
- CdaDocumentTypeValidator (AtLeastOneValidator) og CdaDocumentApdV2ModelEnricher, CdaDocumentPhmrModelEnricher samt CdaDocumentQrdModelEnricher, der forventer, at dokumentet er af en af typerne APD, PHMR eller QRD
- XDSDocumentValidator (AtLeastOneValidator) og CdaDocumentHeaderModelEnricher, som forventer at kunne pakke input ud som et CDA dokument ved at finde en CDA header
- 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
- XDSDocumentContentModelEnricher (ModelEnricher), der pakker input ud som UTF8 bytes hvis muligt
Hver ITI kald har sin kombination, da ikke alle elementer er til stede, i de forskellige kald. F.eks, har er et ITI 41 kald det eneste kald, som har et faktisk dokument, der kan valideres.
...