Validation Rule Suggestions

Hi all,

Do we need a rule for limitating the number of decimals used to represent the --STRESN variable for domains that contain measurements - e.g. OM or BW?

I feel that the following rule should be disabled for PM (Palpable Masses):

SD0026: "Missing value for --ORRESU, when --ORRES is provided".

PMORRES can be populated while PMORRESU remains empty - see example from SENDIGv3.pdf - page 118.

I haven't found any validation rule for the relation between SE and EX records.

I feel that there is a one-to-many relation between SE and EX (1 SE to many EX). Shouldn't this be illustrated by a consistency rule (like SD0070 is)?

Some rule suggestions in relation to:

- "SD0023" - "Missing value for --STAT, when --REASND is provided";

- SD0036 - "Missing value for --STRESC, when --ORRES is provided";

- SD0047 - "Missing value for --ORRES, when --STAT or --DRVFL is not populated";

- SD0048 - "Value for --ORRES is populated, when --STAT is 'NOT DONE'";

Please comment if the suggestions are not valid for some reason:

1. When --STAT="NOT DONE", --STRESC should also be empty (like --ORRES).

I don't think that checks related to lengths of variables should be included.  FDA is pushing for reducing the length of each variable in a submission to the minumum length needed to accomodate the longest value.  Therefore, for example, if the longest value of ARMCD in a submission is 4, the length should not be forced to 20.

The rule CT1023 - "Value for --SEV not found in (SEV) CT codelist" is enabled into config-send-3.0.xml  for most of the domains, including CL (for CLSEV).

However, into the SENDIGv3.pdf standard the CLSEV variable is not controlled by any Terminology (SENDIGv3.pdf - page 70). Other --SEV variables (MASEV, MISEV) variables are controlled by the CL.C90000.SEV Terminology list.

Should rule CT1023 be disabled for CL, to reflect the SENDIGv3.pdf standard?

I notice that SD1029 is a new rule in the recent version of OpenCDISC and is marked as an error. Can you provide where this requirement came from. I understand that it is good practice not to use extended ascii characters but in order to convince our CROs of this it would help to be able to refer to a regulatory requirement.

.... SD1029 Non-ASCII or non-printable characters Character variable value must not include non-ASCII or non-printable characters (outside of 32-127 ASCII code range)

Hello all,

I was wondering how "special chars" (e.g. ISO-8859-1 or UTF-8) like öäüéàè are represented in .xpt files (which support just ASCII from what I know) and if there are any validation rules that check the .xpt's content to be plain ASCII.

Thanks!

Hello all,

I'm getting the following Warning for the SUPPTF.xpt QNAM variable, when the TFSPCCND text is longer than 200 chars and it gets split in 200 chars pieces into the SUPPTF.xpt file:

SD1022 - "Invalid value for QNAM variable" - The value of Qualifier Variable Name (QNAM) should be limited to 8 characters, cannot start with a number, and cannot contain characters other than letters in upper case, numbers, or underscores.

Note: QNAM in my case contains the "TFSPCCND1", "TFSPCCND2" values (9 chars length).