f Frank
on

 

I'm using version 2.1.2 to validate define v2 xml (SDTM 3.2, CT 2015-12-18)

The config XML for 3.2 has numerous references to CodeListOID="CL.C66742.NY”  They look like:

         <CodeList OID="CL.C66742.NY" Name="No Yes Response" DataType="text"

                   nciodm:CodeListExtensible="No">

            <EnumeratedItem CodedValue="N">

               <Alias Name="C49487" Context="nci:ExtCodeID"/>

            </EnumeratedItem>

            <EnumeratedItem CodedValue="NA">

               <Alias Name="C48660" Context="nci:ExtCodeID"/>

            </EnumeratedItem>

            <EnumeratedItem CodedValue="U">

               <Alias Name="C17998" Context="nci:ExtCodeID"/>

            </EnumeratedItem>

            <EnumeratedItem CodedValue="Y">

               <Alias Name="C49488" Context="nci:ExtCodeID"/>

            </EnumeratedItem>

            <Alias Name="C66742" Context="nci:ExtCodeID"/>

         </CodeList>

 

The following comes from the XML that I created:

<CodeList OID="CL.NY" Name="No Yes Response" DataType="text">

          <EnumeratedItem CodedValue="N">

                    <Alias Name="C49487" Context="nci:ExtCodeID"/>

          </EnumeratedItem>

          <EnumeratedItem CodedValue="Y">

                    <Alias Name="C49488" Context="nci:ExtCodeID"/>

          </EnumeratedItem>

<Alias Name="C66742" Context="nci:ExtCodeID"/>

</CodeList>

 

So the codelist alias matches and the term (for "N") matches, yet in the validation there’s a warning flagging N (DD0024 – Invalid term in codelist “No Yes Response”)

And the warning only occurs once, even though there are >1 references to OID CL.NY

Why [a] is there a warning and [b] why am I getting the warning only once, instead of the expected (5) times?  I'm stumped

Forums: Define.xml

g Gerard
on September 1, 2016

Hey Frank,

[a] -  Can you check what variables you have referencing your CL.NY codelist in your define.xml and verify that the same variable in the 3.2 config is not referencing a subset version of the NY codelist such as the No Yes Response (Yes only) codelist? This would be marked as CL.C66742.Y in the config. Variables such as AE.AEPRESP reference this codelist. There is a little niggle with DD0024 where it will report using the metadata from your codelist rather than reporting using the metadata from the controlled terminology, such as the name used for the codelist. So instead of saying Invalid term in codelist “No Yes Response (Yes only)” it will say the message you received. That is the most likely issue.

[b] - It only reports the message once because it is a problem with the CodeList (1 CodeList) rather than the Variables (5 variables) referencing it. The idea is it doesn't matter how many times the codelist is referenced, it only needs to get validated once.

 

Hopefully this clears things up for you and let me know if you have any more questions!

 

Best Regards,

Gerard

 

P.S. We are going to fix DD0024 so that it uses the metadata from the controlled terminology in a future release so that this rule is more helpful.

f Frank
on February 16, 2017

This problem cropped up again: running Comm. Ver. 2.0.0, SDTM 3.1.3 (FDA)  Var AESER references CL.C66742.NY, and in the terminology file (2016-12-16) CL.C66742.NY (just ...NY, not a subset) shows values N Y U NA.  The values in our codelist referenced by AESER are N and Y (no leading or trailing blanks). We use the NY list a handful of times, all for variables that used only the value Y. The error occurred when we added variable AESER, which had dataset values of N and Y (so it looks like the addition of N to the list raised the error).

s Sergiy
on February 17, 2017

Hi Frank, 

Is this issue present in v2.2.0?

Thank you,

Sergiy 

f Frank
on February 17, 2017

Yes, 2.2.0

s Sergiy
on February 17, 2017

Hi Frank, 

I cannot reproduce it. 

Most likely, you have this DD0024 message due to assignment of NY Codelist (which include term 'N') to  *FL or --PRESP variables. Please ensure that this is not your case.

Regards, 

Sergiy

s Snehal
on September 27, 2017

We are also experiencing the same problem. I checked the variables associated with this codelist and they are not the same mentioned in above (--FL/--PRESP). Please see the screenshot below for more details about the warning messages. Kindly advice.

screenshot

 

s Sergiy
on September 28, 2017

Hi Snehal, 

As you can see from discussion above, it's not enough to have an example of Codelits terms for diagnostics. We also need to check assignments of Codelists to particular variables to ensure a correct use.

Kind Regards, 

Sergiy 

o Olga
on December 1, 2017

Hi,


Per SDTM IG 3.2, in my current study, the following variables are set to (NY)  No Yes Response codelist in define v2.0 : AESER , EXFAST, MLOCCUR, AECONTRT, IESTRESC, LBFAST -- all those contain both, "N" and "Y" values. Also, per SDTM IG 3.2, baseline flags set to (NY)  No Yes Response, such as LBBLFL, EGBLFL, VSBLFL, QSBLFL -- those contain only "Y" or null values.
PMDA rule DD0024 throws the following error: DD0024: Invalid Term in codelist 'No Yes Response (Yes only)' for variable 'EGBLFL' -- one example -- because codelist for (NY)  No Yes Response in define.xml contains both, "N" and "Y" (pulled from AESER, EXFAST, MLOCCUR, etc.).
Is it a known issue in DD0024 rule? How do we explain this in SDRG?
Also, in SDTM Terminology, up to the latest 2017-09-29 version, there is no such CT as No Yes Response (Yes only). There is CT for No Yes Response (C66742) but no No Yes Response (Yes only) -- where is it coming from?


Thank you for your help in advance.

j Jozef
on December 2, 2017

Hi OlgaF,

This is a omission in the CDISC Controlled Terminology that makes me so sad and angry over and over again.
The CDISC-CT team still (repeatedly) refuses to publish a "YesOnly" codelist for use in the cases that you mention (like baseline flags). Instead, they point to the SDTM-IG (not machine-readable) where it is stated that one should use the "NY" codelist, but that only "Y" is allowed.
How can a machine know that???
The best workaround (I cannot name it otherwise) is to make a subset of the "NY" codelist, only containing "Y", and give the codelist as well as the single entry the same NCI codes as in the original "NY" codelist.

Jozef

o Olga
on December 4, 2017

Thank you, Jozef, for your explanation. It's very helpful.

s Sergiy
on December 4, 2017

Hi Olga,

You have an incorrect Codelist assigned to Flag variables. This is a technical error in your define.xml file which must be fixed.

DD0024 validation message may be quite confusing. Your example is the most common and notorious case.

Codelists describe a data collection process for data elements which were populated by pre-specified list of terms.

Flag variables like DTHFL, --BLFL, or --PRESP may be populated with only a single term ’Y’. Therefore, a Codelist for these variables cannot include any additional terms like ‘N’ or ‘U’.

You should have two or more separate Codelists based on CDISC CT (NY). One Codelist with a single term ‘Y’ is assigned to Flag variables. Other Codelist based on CDISC CT (NY) assigned to other variables or Value Level items.

Please remember that CDISC CT is a source of standard terms, while define.xml file is a description of study data collection / derivation process.

Kind Regards, 

Sergiy

j Jozef
on December 6, 2017

DD0024 is essentially not a Define-XML validation test, it is an SDTM validation test.
Reason is that the sponsor's define.xml is the "Sponsor's truth", it is what YOU, as a sponsor want to provide as metadata information to the reviewer. So if you, as a sponsor feel that "Y" and "N" can both occur as a baseline flag value, than assigning the NY codelist to --BLFL is 100% correct.
However, also assigning "N" as a possible value for a baseline flag variable is a violation against the SDTM standard, and not against the Define-XML standard.
Remark that you can also depict the playing schedule of the next soccer world championship in a define.xml, as the standard is meant for ANY tabular data, not only for SDTM, SEND or ADaM.

Jozef Aerts
CDISC Define-XML team

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.