a Adam
on

 

In Pinnacle 21 Community v4.1.0, we've been validating SEND 3.1 Define 2.0 files with engine FDA (2304.3) and have been receiving the "Invalid dataset label value" (DD0136) for a few domains like LB and PC.  In the Define-XML Conformance rules (from CDISC and posted on the Pinnacle 21 website), this rule should only be applied to Define XML 2.1, but it is being triggered on our Define XML 2.0 files.  Is this a mistake in the system?  Also, what is the best source for where the Dataset Labels are defined for each domain (to reference when we eventually move over to Define XML 2.1)?

Forums: Define.xml

j Jozef
on August 28, 2024

It looks as there is a discrepancy between what is published by P21 about for which versions of Define-XML rule DD0136 is applicable, and what is implemented in the software.
And no, these by P21 published conformance rules for Define-XML are NOT from CDISC. They are P21s own interpretation of the standard.

The best source for finding the labels for any SDTM or SEND domain is the "CDISC Library Browser" which you can find at https://library.cdisc.org/browser/#/.
If you don't have an account, get one (it's free).
Then select the appropriate Implementation guide under "Data Tabulation" (in your case "SENDIG v3.1", then the class (e.g. "Findings") and then the domain (e.g. "LB").
You then see the label for that domain for that version of the Implementation Guide under "Name" - screenshot attached.
The "CDISC Library" is the "CDISC truth". There is also an excellent API (for use with RESTful Web Services) described at: https://api.developer.library.cdisc.org/api-details. Use it for automation!!!

CDISC Library - the "CDISC truth"

Jozef Aerts
CDISC Define-XML Development Team and Define-XML Instructor.

Matt
on August 29, 2024

Hi Adam,

 

What is the label DD0136 expecting in your case, and what do you have?

 

 

Kind regards,

Matt

a Adam
on September 11, 2024

Hi Matt,

The warning doesn't elaborate on what labels the DD0136 message is expecting, but it is occurring for the LB, PC, and PP domains.  Our labels are populated as "Laboratory Test Results", "Pharmacokinetics Concentrations", and "Pharmacokinetics Parameters".  Based on Jozef's comment, the CDISC Library lists the labels as "Laboratory", "Pharmacokinetic Concentrations", and "Pharmacokinetics Parameters" (the labels for LB and PC are different, but the label for PP is the same, so still not sure what values the labels are being compared against).  I hope this helps.

Thanks,

Adam

Matt
on September 12, 2024

Hi Adam,

 

We are aware of this for PP. Thank you for confirming your differences in labeling for LB and PC vs the CDISC Library. We are looking into correcting the labeling issue for PP. Furthermore, labeling should also clear itself up once CDISC publishes a codelist for domain labels and corrects inconsistencies across the CDISC Library and the IGs.

 

Kind regards,

Matt

s Siru
on February 20, 2025

I also encountered the same issue and DD0136 was been fired. Actually I am going to submit NMPA, and all the dataset labels and variable labels were translated to Chinese. When created define.xml, I specied language "cn" in the define spec. Why this rule was triggered?

File Upload

Sergiy
on February 20, 2025

Hi Siru, 

This is a bug. DD0136 rule should not be applicable for NMPA validation due to missing CDISC Chinese translation for SEND standard. 

P21 will add support for Chinese dataset and variable labels in SDTM and ADaM in the next (25xx.0) engine later this year.

Thanks for reporting this issue.

Kind Regards,
Sergiy 

 

n Nick
on February 28, 2025

So, I am running into same issue where DD0136 is being fired on Define 2.0 SDTM dataset labels. It is too late to go back and change the label itself so can I just annotate in the reviewer's guide that this is a false positive? Or what would be a good annotation?

j Jozef
on March 1, 2025

"It is too late to go back and change the label itself"

In general, NEVER, NEVER, NEVER change something in your submission because of a false positive error/warning message in a validation report from any vendor or organization.
You should NEVER change such things only for satisfying the validation software. You should think for yourself.

Validation software should be such that users can:
a) decide themselves which rules are tested on (and document that)
b) exclude rules from the validation that are known to generate false positives
Validation software vendors and organizations should take care that:
a) errors in their software causing false positives are repaired within days or weeks, rather than months
b) allow users to choose which version they use (no automatic updates)
c) users can always revert to an earlier version when they find out that the new version does not meet their expectations

All my personal opinion of course!

 

Want a demo?

Let’s Talk.

We're eager to share and ready to listen.

Cookie Policy

Pinnacle 21 uses cookies to make our site easier for you to use. By continuing to use this website, you agree to our use of cookies. For more info visit our Privacy Policy.