DD0022 warning on OpenCDISC Community 2.0.2

Hi Jenny,Can you download

Hi Jenny,

Can you download Pinnacle 21 (formerly OpenCDISC) Community v2.1 and validate your define.xml again? If the issue persists then I will be happy to help you but unfortunately we do not support old versions of the application.

Regards,

Gerard

Hi, we have the same issue

Hi,

we have the same issue now. and we downloaded the community 2.1 version. it seems the only define 2.0 was validated in the new version. we want to validate define1.0 with a SDTM version 3.2. How can we implement this? please advise.

Regards,

Jing

Hi, we have the same issue

Hi,

we have the same issue now. and we downloaded the community 2.1 version. it seems the only define 2.0 was validated in the new version. we want to validate define1.0 with a SDTM version 3.2. How can we implement this? please advise.

Regards,

Jing

We've experienced the same

We've experienced the same behavior:

Using version 1.5, SDTM version 3.2 creates a warning (other than that, validation was clean)

Using Community version 2.1.1 with config file define.xml, 3.2 is not flagged, but there are many errors about missing method reference, def:Origin missing, etc.  Ours is a version 1 define.xml, but it almost looks like the define.xml is being processed as a version 2 file.

Was there some way to avoid this (special defxml v1 config file, or some other option), or is this a bug?

I guess it depends on the

I guess it depends on the reason for validating Define.xml. If you are only interested in structural conformance, then just use XML schema validation. However, if are validating for FDA or PMDA submission, then you must ensure the content of Define.xml is useful for reviewers. Origins and Methods are especially important for reviewers in helping them understand how your data was collected and prepared, which is why both agencies now recommend the use of Define.xml 2.0. 

New FDA Technical Conformance Guide recommends the usage of version 2.0 as “preferred version”. Recently FDA announced that the support for version 1.0 will end for studies that starts 12 months after March 15, 2017.

Pinnacle 21 validation rules are oriented for regulatory submission, which is why they contain many additional regulatory business rules that are not defined by CDISC standards.

Kind Regards, 

Sergiy

CRT-DDS 1.0 vs Define-XML v2 validation

Agreed that Origins and Methods are especially important for reviewers!
This is why they were both already part of CRT-DDS 1.0, although in a different place in the define.xml file.

When validating a CRT-DDS 1.0 file, a validator should not look for a def:MethodDef element, but a def:ComputationMethod element. A def:MethodDef element would be invalid in a CRT-DDS 1.0 define.xml file.

The def:Origin element in Define-XML v2 allows much more structure than the CRT-DDS 1.0 @Origin attribute, but CRT-DDS 1.0 does have origin metadata.

Believe me, I'm a BIG advocate for Define-XML v2, but when validating a CRT-DDS 1.0 define.xml file, we can not apply rules that are specific for Define-XML v2.

Separate config files?

Having written several papers on define.xml, I understand the need for validation of both structure and content. What I don't understand is the apparent use of a single, Version 2-centric, set of validation rules. I as.sumed that the validator would examine the define version and apply rules accordingly. From what I'm inferring from the earlier posts, this doesn't seem to be the case. So wouldn't separate config files for the different versions be the only alternative? Yes, version 2 is preferred and yes, it's going to be required in a year, but meanwhile there are probably hundreds of studies that are using version 1.  We could validate using define 2 rules, then add content in the Reviewers Guide explaining why the def:Origin errors are false positives, etc. etc.  Seems like a change upstream in the process would be easier for the user base - i.e., a config file for each define-xml version.