Potential Define 2.1 Validation bugs with rules DD0004, DD0007, DD0011, and DD0124

a Adam

on March 7, 2023

Hi all,

Our team recently started evaluating our Define v2.1 files for SEND 3.1 datasets and after reviewing the Pinnacle 21 validation reports, I identified a few potential checks that may be incorrect:

DD0004 - "Attribute 'def:HasNoData' is not allowed to appear in element 'ItemRef'": This is being triggered when def:HasNoData is applied at the value level for blank results, which is acceptable per Define XML 2.1 spec. Adding comments to the value level ItemDef did not resolve the validation issue.
DD0007 - "Invalid content was found starting with element 'Alias'.": This is being triggered for ItemDef value level entries where Alias is used if the SASFieldName attribute was shortened to 8 characters because the Name attribute was longer than 8 characters. Alias, with context "SAS", was used to present the SAS Name without any character limits (see screenshot). This seems like it should be acceptable per Define 2.1 Spec.
DD0011 - "ODM element 'Alias' should not be included in Define.xml": see issue above
DD0124 - "Expected Codelist is missing": This issue is being triggered for blank expected SEND variables that should have a codelist defined if populated (e.g., LBUSCHFL). These variables are included in the dataset because they are expected, but there is no way to populate a codelist because there are blank.

Please let me know if I am misinterpreting any of these checks or the information in the Define Specifications. Otherwise, I do believe these checks may be bugged for these scenarios.

Thanks,

Adam

Attached Files

alias-example.png

Forums: Define.xml

j Jozef

on March 8, 2023

Potential Define 2.1 Validation bugs

In my personal opinion, the DD0004 message you obtain is a false positive: there is indeed no (at least CDISC) rule that says that def:HasNoData is not allowed on ValueList-ItemRef|s. I consider this as an over-interpretation of the define.xml 2.1 specification. Also, there is no such rule in the CDISC "Define-XML 2.1 validation rules".
IMO, adding it also to ValueList-Items is extremely useful as it allows to say to the reviewer, that, after transposal, the thus generated column will be empty.
But maybe this rule has been "invented" by FDA/P21 "on top" of the define.xml 2.1 rules.

There is no relation at all between "Alias" and "SASFieldName". The latter is only useful for when using SAS as an indication what the generated field name is. When e.g. using R, SASFieldName has no meaning. "Alias" is however completely independent of anything else.
One is completely free to choose the value for "Context" in "Alias". Doing so for Context="SAS" is indicating: In the context of using SAS, a synonym for the variable is XXX where XXX is the value of the "Name" attribute. There is no rule in Define-xml 2.1 whatsoever values for "Context" are allowed.
Also here, maybe this rule has been "invented" by FDA/P21 "on top" of the define.xml 2.1 rules. It surely is not a CDISC rule.

Regarding DD0124 - "Expected Codelist is missing", this cannot be a Define-XML rule. The Define-XML specification does not say at all for which variables a codelist is expected, as the Define-XML specification does not know anything about the semantics/meaning of variables and their names. This could be an SENDIG-rule, but then it should not appear in the rules regarding Define-XML. We usually name this a kind of rule "cross-standard-validation rule" as as well the define.xml as the SDTMIG/SENDIG is involved.
So, although it cannot be a Define-XML rule, it still may not be a false positive (but with the incorrect code) in the sense of SENDIG. Reason is that the associated codelist is always about the "possible values than can be expected". For example, if you never have a value for an Albumin measurement (in LB), but it was planned to do Albumin measurements, you still will need to have "ALB" in your CodeList associated to LBTESTCD. Similar, in your case, LBUSCHFL, even when there never is a value, there could have been a case where there is a value, and thus the codelist (with the only value being "Y" I presume) should be provided.
Please check the SENDIG rules for finding out what the exact rules concerning the use of codelists are.

Lex

on March 8, 2023

Potential Define 2.1 Validation bugs

It is not clear from the post whether VLM was used to define a non-standard or supplemental qualifier variable. The specification does not describe using def:HasNoData as an ItemRef attribute in other cases.
From the Define-XML specification (5.3.9.2 ItemRef Element): def:HasNoData:

Required in the context of a regulatory submission when the dataset variable defined in the associated ItemDef has no data values (ODM@def:Context="Submission")
Used to indicate that an ItemRef that represent a dataset's variable has no data. Note that variables refer to both standard and non-standard/ supplemental qualifiers variables (/ODM/Study/MetaDataVersion/ItemGroupDef/ItemRef or /ODM/Study/MetaDataVersion/def:ValueListDef/ItemRef).
Business Rule: A comment must be included to explain why no data is present for dataset's variables that were planned for use in the study.

Alias can be used to define longer SAS names, but then it should be a valid SAS name. NON-NEOPLASTIC is not a valid SAS variable name, since it contains a dash.

Aliases not described by the Define-XML 2.1 specification should be considered an extension in the context of submission.