Define.xml generated for SEND with Validator 1.5

b Bedeoan

on April 14, 2014

Hi all,

I'm generating a define.xml with Validator 1.5 based on an XPT dataset, and I have a few questions:

1. In a previous topic it was said that Validator 1.5 will also support DefineXML2.0; I don't see this feature enabled in the UI. Will it be available in a future release?

2. Some attributes are generated with empty content: ODM FileOID, Study OID, StudyName, StudyDescription, ProtocolName. MetaDataVersion OID, MetaDataVersion Name, MetaDataVersion Description.

The intention is to have the user later fill in manually the content for these tags?

At least some of them (FileOID, StudyName) could be populated with the STUDYID variable's content.

And MetaDataVersion OID shouldnt be "CDISC SEND 3.0"?

3. In the ItemDef definition, Origin, Comment and Length have empty values and I assume these should be filled in manually by the user?

I would suggest to fill in the Origin and Length with default values because:

3.1 The Origin of variables is in 90% the same, no matter what is the study's specific - e.g. STUDYID, USUBJID, DOMAIN, --SEQ, or --TESTCD will always be "OTHER", STRESN, STRESU, DY will always be "DERIVED", etc - see SENDIgv3.pdf - page 19.

3.2 the Length of variables is in 90% the same: the big majority of variables will have Length="200", --TESTCD will have Length="8", --TEST will have Length="40", etc - see SENDIgv3.pdf - page 36.

If the Validator populates with default values, the user will have to change manually only where he considers it to be necessary, not for all variables of an export, and this would reduce a lot the work of the user.

What do you think, guys?

4. The usage for the "Code Lists:" feature is not very clear to the end-user, in my opinion...

Best regards,

Amelia

Forums: Define.xml

j Jozef

on July 27, 2014

Define.xml generated for SEND with Validator 1.5

It is my opinion that it is in general a pretty bad idea to use OpenCDISC to generate define.xml files from XPT files.
You can only use it when:
a) you do not have any other option at all
b) AND you realize that what is produced is only a "very first guess", which you will need to edit and adapt manually (good luck with that!)

The "generator" only reads the headers of the XML files, so cannot know about "Study ID". It even does not seem to look into the lengths of the variables.
How can it know what the "Origin" is? That is not in the XPT either. If the generator uses predefined values as you suggest, people will complain that the generator does not work correct, as they simply expect too much from the software - some might even want to sue OpenCDISC!

So, consider the generator as a "last resort" tool and be aware of the limitations.

Essentially, you should have a process in place that keeps a define.xml in sync with your mappings between your operational data and your SDTM/SEND data. There are several such tools on the market, for example the SDTM-ETL software from my company. It supports all newer versions of SDTM and SEND and both define.xml 1.0 and 2.0.

s Sergiy

on July 29, 2014