Tjek relevant overordnede dele er til stede i input (så validatorer ikke behøver blive negative, hvis de ikke er)Indhold:

Indledning

På NSP deles i dag CDA dokumenter 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 typerne:

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

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

XdsValiderings biblioteket er under fortsat udvikling. Se afsnittet "Understøttede valideringsregler" for den nuværende implementering.

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

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.

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

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. 

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-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-validatorerne ved dokumentindholdet/typen, vil AtLeastOneValidatoren melde en fejl retur. Se følgende eksempel:

//validering hvor CdaDocumentTypeValidator forventer at ens af dens under-validatorer vil kendes ved input (dokumentet)

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.

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.

//validering, hvor CdaDocumentApdV2ModelEnricher forventes at pakke input ud og forstå at det er et aftale dokument.

CdaDocumentApdV2ModelEnricher cdaDocumentApdV2ModelEnricher = new CdaDocumentApdV2ModelEnricher();

Apd2StartStopTimeValidator apd2StartStopTimeValidator = new Apd2StartStopTimeValidator();
cdaDocumentApdV2ModelEnricher.appendValidator(apd2StartStopTimeValidator);

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

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

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 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:

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

Hver ITI kald har sin kombination, da ikke alle elementer er til stede, i de forskellige kald. F.eks, er et ITI 41 kald det eneste, som har et faktisk dokument, der kan valideres.

En grafisk præsentation af denne konfiguration af default validering kan ses i Design og arkitektur dokumentet.

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

Et konkret eksempel kan være ændring af en ITI 41 kaldets validering, sådan at startTime for aftaler bliver mere specifik (F.eks at tiden skal være i "fremtiden"). Dette kunne gøres som følger:

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, 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.createIti57Validator();
    }

    public RegisterDocumentSetStarter buildIti61Validator() {
        return Iti61ValidationFactory.createIti61Validator();
    }
}


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 Medcoms standarder og IHE XDS specifikationen.

Disse standarder refereres som følger:

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

(Anvend "mvn javadoc:javadoc -pl \!validation-cda-dependencies " 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 følgende afsnit.

Klasse
CdaDocumentValidatorFactory
Iti41ValidationFactory
Iti42ValidationFactory
Iti61ValidationFactory
Iti57ValidationFactory

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.

KlasseValideringITI 41ITI 42ITI 61ITI 57Cda dokument







ProvideAndRegisterDocumentSetStarter
  • submissionSet pakkes ud
  • dokumenter pakkes ud
  • der skal som minimum være eet dokument
x



XDSDocumentITI41StructureValidator
  • der findes dokumenter
  • der findes et doucmentEntry
  • der findes et fysisk dokument
  • der findes et submissionSet
x



CdaDocumentApdV2ModelEnricherx


x





















Typevalideringer

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

KlasseValidering

AbstractElementCompare

  • sammenligning af 2 lister (hver med en eller flere objekter)
  • antal af objekter skal være ens
  • de enkelte objekter skal være ens på de samme pladser i listen

CodedModelCompare

  • validering for AbstractElementCompare med typen CodeModel, hvor følgende opfylder "objekterne er ens"
  • value skal være ens
  • codeSystem skal være ens
  • displayName skal være ens

DateTimeCompare

  • validering for AbstractElementCompare med typen DateTime, hvor følgende opfylder "objekter er ens"
  • dateTime skal være ens

StringCompare

  • validering for AbstractElementCompare med typen String, hvor følgende opfylder "objekter er ens"
  • de to strenge skal være ens





CodedValueValidation

  • udfyldt codeSystem (IHE 4.2.3.1.2 Creating Coded Attributes)
  • gyldigt codeSystem (DK_IHE_ClassCode_DE)
  • udfyldt code (IHE 4.2.3.1.2 Creating Coded Attributes)

ClassCodeValidation

  • længden på code må ikke være større end 3 (DK_IHE_ClassCode_DE)
  • displayName skal være udfyldt (IHE 4.2.3.1.2 Creating Coded Attributes)
  • validering for CodedValueValidation. Default gyldigt codeSystem er OID "1.2.208.184.100.9" (DK_IHE_ClassCode_DE)
ConfidentialityCodeValidation
EventCodeValidation
FormatCodeValidation
HealthcareFacilityTypeCodeValidation
LanguageCodeValidation
OrganisationCodeValidation
  • hvis codeSystem er Yder så skal længden på code være 6
  • hvis codeSystem er Yder så skal code være numerisk
  • validering for CodedValueValidation. Default gyldige codeSystemer er "1.2.208.176.1.1" (SOR) og "1.2.208.176.1.4" (YDERNUMMER)
PatientIdCodeValidation


PracticeSettingCodeValidation


StringValidation


TitleValidation


TypeCodeValidation


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, om en given validering er inkluderet i default valideringer, som er konfigureret i XdsValidation biblioteket.

KlasseValideringITI 41ITI 42ITI 61ITI 57Cda dokument

DocumentEntryClassCodeValidator

  • udfyldt classCode (Metadata-v096 2.2.3 classCode)
  • validering for ClassCodeValidation
xxxx
DocumentEntryAuthorInstitutionValidator
  • der skal være mindst een author (Metadata-v096 2.2.1.1 authorInstitution)
  • der skal være en authorInstitution (Metadata-v096 2.2.1.1 authorInstitution)
  • validering for OrganisationCodeValidation
xxxx
DocumentEntrySourcePatientIdValidator
xxxx







CdaHeaderAuthorInstitutionValidator
  • der skal være een author (Metadata-v096 2.2.1.1 authorInstitution)
  • der skal være en authorInstitution (Metadata-v096 2.2.1.1 authorInstitution)
  • validering for OrganisationCodeValidation
x


x
CdaHeaderSourcePatientIdValidator
x


x







SubmissionSetAuthorInstitutionValidator
  • validering for OrganisationCodeValidation
xxxx
SubmissionSetPatientIdValidator


xxxx





















Apd2StartStopTimeValidator
  • ServiceStartTime skal være udfyldt (DK-APD-v2.0: 2.1.10.1 Appointment Date and Time)
x


x


Krydsvalideringer

Her valieres 2 entiteter. F.eks. documentEntry og cdadokument. Hvis mindst en af entiterne kan indholde flere felter af den samme type, sammenlignes antal




CdaCrossDocumentEntryAuthorInstitutionValidator
  • der skal være lige mange authors på CDA header og documentEntry
  • der skal være lige mange AuthorInstitutions på author på CDA header og documentEntry
  • validering for CodedModelCompare af CDA header værdi og documentEntry liste
x



CdaCrossDocumentEntryAuthorPersonValidator
  • der skal være lige mange authors på documentEntry og CDA header
  • validering for StringCompare af CDA header liste og documentEntry liste (listerne består af personens titel og navne)
x



CdaCrossDocumentEntryConfidentialityCodeValidator
  • der skal være lige mange ConfidentialityCodes på CDA header og documentEntry
  • validering for CodedModelCompare af CDA header værdi og documentEntry liste
x



CdaCrossDocumentEntryCreationTimeValidator
  • validering for DateTimeCompare af datoerne
x



CdaCrossDocumentEntryEventCodeValidator
    • validering for CodedModelCompare af CDA header liste og documenEntry liste (listerne består af EventCodes)
x



CdaCrossDocumentEntryLanguageCodeValidator
  • validering for StringCompare af streng og streng (strengene indeholder languageCode)
x



CdaCrossDocumentEntryLegalAuthenticatorValidator
  • validering for StringCompare af CDA header liste og documentEntry liste (listerne består af legalAuthenticators titel og navne)
x



CdaCrossDocumentEntryPatientIdValidator
  • validering for CodedModelCompare af CDA header værdi og documentEntry værdi (værdierne er PatientId'er)
x



CdaCrossDocumentEntryServiceStartTimeValidator
  • validering for DateTimeCompare af datoer
x



CdaCrossDocumentEntryServiceStopTimeValidator
  • validering for DateTimeCompare af datoer
x



CdaCrossDocumentEntrySourcePatientIdValidator
  • validering for CodedModelCompare af CDA header værdi og documentEntry værdi (værdierne er SourcePatientId'er)
x



CdaCrossDocumentEntrySourcePatientInfoValidator
  • validering for StringCompare af CDA header liste og documentEntry liste (listerne består af personens titel og navne)
  • validering for DateTimeCompare af datoer, hvor datoer er fødselsdato
  • validering for StringCompare af streng og streng (strengene indeholder køn)
x



CdaCrossDocumentEntryTitleValidator
  • validering for StringCompare af streng og streng (strengene indeholder titel)
x



CdaCrossDocumentEntryTypeCodeValidator
  • validering for CodedModelCompare af CDA header værdi og documentEntry værdi (værdierne er TypeCodes)
x



SubmissionSetCrossDocumentEntryAuthorInstitutionValidator
  • der valideres kun, hvis submissionSet har authors
  • der skal være lige mange authors på submissionSet og documentEntry
  • der skal være lige mange AuthorInstitutions på author på submissionSet og documentEntry
  • validering for CodedModelCompare af submissionSet liste og documentEntry liste
xxxx
SubmissionSetCrossDocumentEntryAuthorPersonValidator
  • validering for StringCompare af SubmissionSet liste og documentEntry liste (listerne består af en eller flere personers titel og navne)
xxxx
SubmissionSetCrossDocumentEntryPatientIdValidator
  • value og codeSystem skal være ens for submissionSet og documentEntry
xxxx