We have some datasets that or not a true BDS structure, still borrowed some BDS elements. Open CDISC validates them as being BDS, however in the DEFINE.XML they have been flagged as OTHER. My question is if OPEN CDISC validator could use the type defined in the define.xml when it is available instead of trying to determine the structure based on the available variables?
We have as types ADSL, OCCDS, BDS and OTHER.
Please note, that define.xml standard has a Control Terminology for "Def:Class" attribute. See v2.0 specs on page 70. You need to follow the standard. E.g.,
No, we do not use dataset Class metadata from define.xml file. Dataset Class or "Prototype" in OpenCDISC terms is defined based on actual structure of datasets.
If analysis datasets do not fit in any category above, they are not validated.
Similar approach is used in SDTM/SEND validation
Standard domains are identified by their names.
Custom domains are assigned to one of three General Class domain groups based on presence --TEST, --TERM or --TRT variable.
Thanks for pointing out that we need to spell out the class.
The issue I am facing is that we have a dataset that is very much like an AE dataset which because the name of the xpt file is not ADAE and it has the variable ASTDT in it, is recognized as a BDS, which results in producint the error that all the BDS variables are missing. To get this data properly trough the validator we probably have to append the data to the ADAE dataset and identify this data through a categorizing variable instead of putting it in a separate dataset.
I think the problem here is really that the ADT, ASTDT or ASTDTM variables are used to characterize BDS. When a Define-XML file is not available to give the metadata for dataset classification, it is a good idea to use variables to classify. However, only variables should be used that truly identify the class or dataset.
It is really problematic when a validator is driving analysis modeling, instead of the analysis need or clearly stated rules.
I have been thinking a bit more about this. For one of the analysis we combine data from AE with CE. If I would call this dataset ADAE I will get errors as the rules for ADAE say that the data has to originate from SDTM.AE. If I use a different name than ADAE I will get errors as open cdisc validator determines that the dataset is a BDS. Also if I would create multiple ADAE datasets for mutliple purposes the validator will not correctly validate these as ADAE data structure. I agree with Lex and therefore I would like to ask to consider driving the validator by the define.xml if that is available for the next version of the program. The define.xml really should be available and be used when checking the ADaM datasets.
Unfortunately as of today study metadata has most compliance problems. Therefore we cannot 100% rely on define.xml file.
For example, original configuration of MedDRA validation was driven by define.xml file. In user interface you could chose a MedDRA version, however if define.xml file was submitted then a MedDRA version provided in define.xml overwrote a version entered manually. Such approach resulted in a lot of confusion mostly due to invalid representation of MedDRA version in study metadata. Now the only option is to specify MedDRA version in GUI. A define.xml is ignored. Such approach works much better today.
In the future when the industry compliance with define.XML standard will be good enough, we will re-introduce more features based on provided study metadata. Meanwhile functionality of OpenCDISC Community is defined by practical usage and needs of majority users.
If you need customization consider Enterprise edition or contact Pinnacle 21 for commercial support.
* Required Field
Hi Rob, What are Type values
What are Type values in your define.xml?