4 Radnor Corporate Center
Suite 350
Radnor, PA 19087
+1 (888) 507-2270
DD0148 - Invalid Syntax for Predecessor
Forums: Define.xml
LexDescription when the Orgin="Predecessor"
The Description in case of Origin="Predecessor" is meant to identify data set and variable. The Define-XML v2.1 specification gives a bit more detail in section 4.3.3.4.(in an example):
- The ItemDef element includes a def:Origin child element with the Type attribute value set to Predecessor. The Description child element of the def:Origin element has a TranslatedText child element with the value ADSL.TRT01P, indicating that the predecessor variable for the TRTP variable in the ADQSADAS dataset is the TRT01P variable in the ADSL dataset. Notice that the Source attribute of the def:Orgin element is not used in this case.
- When the date for an ADaM variable is taken from an SDTM supplemental qualifier dataset, the following notation should be used in the TranslatedText child element: <dataset name>.QVAL where QNAM="<QNAM value>". In general, a where condition should be specified when the values for the ADaM variable are taken from a subset of the referenced source dataset only.
Notice the use of "should", instead of "must". There is no formal business rule to validate the contents of the Origin/Description. Section 4.3.2 gives some considerations.
Lex Jansen
DD0148 - Invalid Syntax for Predecessor
There's no formal business rule, yet P21 seems to be validating the contents of the Origin/Description through the application of rule DD0148?
Resolved(ish)
We've managed to resolve the issue for predecessors from SUPP-- by using this format <dataset name>.QVAL where QNAM="<QNAM value>".
It would be nice if this was mentioned in the rule information for DD0148. It would also be nice if variables with sources other than SUPP-- could use Origin/Description with this format. When we try to use this format in any other context, the warning remains.
Thanks for your help,
David
Multiple source dataset caused DD0148
For ADaM datasets, we have two source data. And for studyid, we are Predeceased from two SDTM datasets. Would you help to give some advice to solve this problem?
how to display when the processor with the conditional?
Starting in Enterprise 5.3, there is the new validation checks. "Define-XML defines Predecessor as a value that is copied from a variable in another dataset. The Description child element identifies the dataset and variable that is copied. To enable other validation rules, the structure of this column needs to be in the form of DATASET.VARIABLE."
I would like to know is any rule if we have some Predecessor conditional not only the easy logic for XX.XXSTRESN? for the condition like: XX.XXSTRESN@XXTESTCD="XXX" or <dataset name>.QVAL where QNAM="<QNAM value>", that as normal condition selected from SDTM for the AVAL based the PARAMCD (for my understanding it should be Predecessor), but now will jump the issue when using Enterprise Version: 5.4.1.
Thank you!
"The Description child…
"The Description child element identifies the dataset and variable that is copied. To enable other validation rules, the structure of this column needs to be in the form of DATASET.VARIABLE.".
I can only laugh (or should I cry?) when I read such a sentence. Reason: define.xml does not have any "columns", and the Description child element surely not.
The people who wrote this rule should first learn XML.
Secondly, (as Lex already suggested), the mentioned requirement is surely not one of the Define-XML standard itself.
In my opinion, it even violates the standard. Companies should not "change" the standard on their own.
Hi All,
We're in the process of validating a data package (incl. define.xml) and the warning DD0148 is being triggered. Interestingly, I couldn't find any additional information about this rule in the set of validation rules (Define-XML Validation Rules | Pinnacle 21) but that's not my main concern.
The description of the rule in P21 Enterprise is as follows:
"..The Description child element identifies the dataset and variable that is copied. To enable other validation rules, the structure of this column needs to be in the form of DATASET.VARIABLE."
For a core SDTM variable, such as LB.LBSTRESC, I think this guidance is unambiguous. However, it's less clear how to refer to variables from a supplemental dataset because of the vertical structure. A few options:
1) Rather than DATASET.VARIABLE (in the context of SDTM datasets) the rule should be interpreted as DOMAIN.VARIABLE. Example: QNAM = TESTID would be referred to as LB.TESTID. If that's the case, the wording of the rule should be generalised to "DOMAIN" rather than "DATASET" when the source variable comes from SDTM.
2) Use the DATASET.VARIABLE format, but add a comment? So something like SUPPLB.QNAM and then a comment like WHERE QNAM = TESTID. This seems clumsy, and I hope it isn't the preferred solution :P
3) If the rule really does mean DATASET rather than DOMAIN, and the distinction between core/supplemental is important, then maybe P21 could accept a three-level reference. Something like SUPPLB.QNAM.TESTID as the predecessor variable. This is the way key variables in SUPP-- are referred to in the SDTM IG.
Thanks for your help,
David Oakley