flag non CDISC, non ADaMiG, non ADSL variables

k Karl-Stephan

on February 18, 2019

ADaMiG (v1.0 and 1.1) is strictly in favour of restricting the allowed scenarios for creating new variables. While the various fragments - prefixed radicals (e.g. 'WA' used for references to wash-out) and suffixes *FL, *DT etc - suggest this should probably not even be a warning, it would be great of p21 could identify all variables not in ADSL and not named in one of ADaMiG, OCCDS or TTE.

Forums: Validation Rule Suggestions

s Sergiy

on February 27, 2019

Thank you for this interesting suggestion!

Hi Karl-Stephan,

Thank you for this interesting suggestion!

It could be added it as a new Notice rule like "Custom analysis variable". Some people will appreciate it, other ones will hate it as extra validation issues to explain.

However, I see many implementation challenges. For example, what about standard SDTM variables and custom SDTM variables from SUPP-- datasets? They should not be reported by this new validation rule.

Kind Regards,

Sergiy

j Jozef

on February 28, 2019

Validation Rule Suggestion

I think the implementation challenges for marking NSVs (Non-Standard Variables in the official CDISC language) are minor. This can easily be accomplished by a checkbox in the graphical user interface. When the checkbox is not checked, such tests are not executed. So one could then generate a report for internal usage with checks for NSVs and "custom analysis variables" and another one for submission without these checks performed.

My own SDTM-ETL mapping software has many such options.

Also remark that define.xml 2.1 will have a mechanism for marking NSVs, this although checking whether a variable is an NSV can also be done by a simple RESTful web service query to CDISC's "CDISC Library" system (formerly known as SHARE 2.0 API), Company-internal RESTful web services can also easily be used to implement company-internal validation or quality rules. We have done so for different sponsors.