Discussing with our P21 define team, please see the follow-up to each question below:
This connects to the Documentation column on the Standards for Study table. This column is currently something we do not support and will not auto-populate. If this column is needed to explain why a certain Standard version was used, this can be explained in the Reviewers Guide.
We will review the logic to determine if a future improvement is required.
we will review the logic to determine if a future improvement is required.
Our team confirmed this is an issue and we have documented it to be resolved in a future release of Community.
We believe this may be resolved in a fix anticipated to come in an upcoming Community release.
Context should always be “Submission” as the defines generated are under the assumption that the “Define-XML document is intended to be used for a regulatory submission.”
As one of the developers of the Define-XML standards (versions 1.0, 2.0 and 2.1), such postings make me pretty sad …
Personal opinion: If software claims to generate compliant define.xml files, it should:
not be based on “naming conventions” for OIDs (Object Identifiers): the user should be able to use whatever they want (e.g. UUIDs)
allow to add comments (references to def:CommentDef) everywhere this is allowed, without exception
not change or “adapt” any information like adding underscores or so
not remove any information provided by the user like for the “arm:AnalysisDatasets” element, or refuse to allow to provide it. Every element of the Define-XML standard should be fully supported.
support all elements and attributes (like “Purpose”) for all versions of all CDISC submission standards
also support generation of metadata for tabular datasets that are not based on submission standards (“generic” use of define.xml)
not make any assuptions regarding what the user wants to accomplish, like that the define.xml is in the context of a regulatory submission. The users should be able to decide these things themselves.
There are very good software packages on the market that are fully define.xml compliant, e.g. that use graphical user interfaces for adding all the necessary and allowed information (i.e. not based on Excel “specifications”) in a very user-friendly way, help the user making decisions through “wizards”, have pre-defined templates for the most common submission standards and versions (but with the possibility to change everything, including OIDs), have build-in validation against XML-schema and other rules, generate the HTML view of the define.xml “on the fly”, and much much more.
These software packages are not always free of charge, but have none of the limitations mentioned in Sherry’s posting, and have excellent customer support.
Thank you for pushing v2.1 functionality also into Community version.
I had tried as suggested in your presentation to take CDISC’s sample define.xml in the v2.1 release package and to create the P21 spec off it to see an example what needs to be filled in.
Out of curiousity, I’ve loaded the P21 spec back into P21 to generated the define.xml again to see if it matches with CDISC’s release but there are some differences:
For the AdaM define.xml, in the MetaDataVersion, although multiple def:Standard were available, but the def:CommentOID=“COM.STDCT.01” is not included (although def:CommentDef is present).
In the arm:ResultDisplay/Name attribute, it adds in underscores. E.g.,
The def:PDFPageRef/Title attribute seems to be completely dropped off (but it is actually one of the features in v2.1), therefore it used the def:title element instead to populated. E.g.