Could open cdisc respect DEFINE.XML when deciding on dataset type?

Hi Rob,  What are Type values

Hi Rob, 

What are Type values in your define.xml?

Thanks, 

Sergiy

Types

We have as types ADSL, OCCDS, BDS and OTHER. 

Thanks

Rob

Hi Rob,  Please note, that

Hi Rob, 

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

• "SUBJECT LEVEL ANALYSIS DATASET"
• "BASIC DATA STRUCTURE"
• "ADAM OTHER"

No, we do not use dataset

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.

• ADSL - based on dataset name.
• BDS - based on presence of PARAMCD, PARAM, AVAL, AVALC, ADT, ASTDT or ASTDTM variables
• TTE - BDS plus presence of CNSR variable

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. 

ADAE variation dataset is considered a BDS

Hi Sergiy,

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. 

Thanks,
Rob

ADT, ASTDT or ASTDTM

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.

Regards,
Lex Jansen

More thoughts about define driving the validator

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. 

Regards,
Rob

Hi Rob,  Unfortunately as of

Hi Rob, 

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.

Kind Regards,

Sergiy