b Bedeoan
on

 

Hi all,

The OpenCDISC tool provides validation rules with category = "Terminology" and content of the following form: "Value for $SENDCol not found in ($Codelist) CT codelist" (CT0004 -> CT1046).

Apparently the rules apply to all CT codelists, both extensible and not extensible.

And I'm not 100% sure that these rules should apply to extensible codelists - where the user is allowed to add new entries (that are not found into the standard CT codelist).

So in my opinion:

- CT1023 "Value for MISEV not found in (SEV) CT codelist" - OK since SEV CT is not extensible.

- CT1020 "Value for MASPEC not found in (SPEC) CT codelist" - not OK since SPEC CT is extensible and the user-defined entry was added to define.xml.

Is it possible that am I missing something?

Here are some related topics:

http://www.opencdisc.org/forum/codelist-extensible-vs-non-extensible
http://www.opencdisc.org/forum/extensible-not-extensible-codelists-non-standard-values


Forums: Validation Rule Suggestions

s Sergiy
on February 25, 2013

Hi!

Checks around non-extensible codelists are Errors. Checks for extensible codelist are Warnings.

We are thinking about changes Warning into Information. Nevertheless such checks are definitely needed for review purposes to ensure that all new terms are valid values.

Regards, 

Sergiy

b Bedeoan
on February 26, 2013

Hi Sergyi,

I was not aware of the fact that the tool is using Error for non extensible and Warning for extensible codelists. In the example I gave before I had warnings both for SPEC (extensible) and SEV (not extensible). So probably the @Type attribute for CT1023 (for SEV) should be changed from Warning to Error.

Otherwise you are definitvely right; it makes sense to have all new terms from extensible CodeLists reported somehow to the user. Errors for non-extensible Codelists and Information for extensible Codelists is a solution I would like to see. Maybe the messages between Error and Information could be differentiated a little bit?

Thank you for the reply.

Best regards,

Amelia

b Bedeoan
on February 26, 2013

One additional question:

Shouldn't the tool implement some validation rules for the new terms added to extensible Codelists? According to SEND standard, the new terms should be in upper-case (except for the units of measure and the --TEST variables which are to be presented in title case).

s Sergiy
on February 26, 2013

Amelia, 

I forgot to mention, that actual validation process for CDISC Terminology is slightly more complicated.

Now in a case of extensible CT codelist, original CTxxxx checks will be replaced by the SD0037 check for all variables with custom user's codeliststs provided in your study define.xml file.

Therefore validation results for codelists will be different when you use define.xml and when you do not.

An enhancement plan is to generate Informational summary for non-CDISC terms provided in define.xml. 

Regards, 

Sergiy

s Sergiy
on February 26, 2013

Thanks!

It's good idea. Just keep inmind, that there are some other CDISC CT codelists with mixed case.

Regards, 

Sergiy

b Bedeoan
on February 27, 2013

And I assume you can't disable SD0037 just for some variables?

E.g. the rule SD0037 is active for ma.xpt => it is triggered for MASEV user-defined values. But since SEV CT is not extensible, the warning should not be trigerred for MASEV's content.

However I should not disable SD0037for ma.xpt because there are other variables like MASPEC, MALAT etc that belong to extensible CT lists and for which this validation should still be performed...

Or can one update the SD0037 rule in config.xml to exclude some variables (e.g. MISEV, MASEV) from the validation?

<val:Match ID="SD0037" Variable="%Variables[!EGSTRESC, MASEV, MISEV].Define.WithCodeList%"

(I'm not familiar with the API...)

 

s Sergiy
on February 27, 2013

Hi Amelia, 

More accurate description of current validation logic for CT:

SD0037 check validates variable's custom codelist provided in define.xml vs. actual data.

CTxxxx checks ensure that specified variables use CDISC Control Terminology. However when custom codelists are present in define.xml, then some checks (with extensible CT) will not be executed. The check control element for this is an ActiveUnless attribute.

In your example for MASEV and MISEV variables, both SD0037 and CT1023 checks will be run independently.

CT1023 will complained about any values outside of CDISC CT.

SD0037 will report any values not specified in define.xml.

Regards, 

Sergiy

 

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.