SUPP-- file: SD1022 - "Invalid value for QNAM variable"

Pinnacle 21 Product Suggestions Validation Rule Suggestions
1

Hi!

I think that the SEND IG text is not clear enough and may be confusing.

SEND IG section 4.1.2 (p. 22):

"Values of --TESTCD and QNAM values must be limited to 8 characters, and cannot start with a number, nor can they contain characters other than letters, numbers, or underscores. This is to avoid possible incompatibility with SAS v5 Transport files. This limitation will be in effect until the use of other formats (such as XML) becomes acceptable to regulatory authorities. QNAM serves the same purpose as --TESTCD within supplemental qualifier datasets, and so values of QNAM are subject to the same restrictions as values of --TESTCD. "

SEND IG uses the SDTM IG as a start point or template. The text you refer to is similar to SDTM IG, but slightly modified. Unfortunately they missed one important paragraph.

SDTM IG section 4.1.5.3.2 (p. 51)

“In cases where the standard domain variable name is already 8 characters in length, sponsors should replace the last character with a digit when creating values for QNAM. As an example, for Other Action Taken in Adverse Events (AEACNOTH), values for QNAM for the SUPPAE records would have the values AEACNOT1, AEACNOT2, and so on.”

Thank you,

Sergiy

2

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).

Quote from the SENDIGv3.pdf specs:

“The first 200 characters of text should be stored in the standard domain variable, and each additional 200 characters
of text should be stored as a record in the SUPP-- dataset (see Section 8). In this dataset, the value for QNAM
should contain a sequential variable name, which is formed by appending a one-digit integer, beginning with 1, to
the original standard domain variable name. When splitting a text string into several records, the text should be split
between words to improve readability. As an example, if the original result or finding as collected was 500 characters in length, the sponsor would put the first 200 characters of text in the standard domain variable and dataset (TFORRES in TF), the next 200 characters of text as a first supplemental record in the SUPPTF dataset, and the final 100 characters of text as a second record in the SUPPTF dataset (see example below). Variable QNAM would have the values TFORRES1 and TFORRES2 for these two records in SUPPTF, respectively, for this one particular text string.”

In this situation, the warning message is perfectly legit, because the lenght of the content from the QNAM variable (meaning “TFSPCCND1”, “TFSPCCND**2”, etc) is longer than 8 characters.

So, this is not actually an OpenCDISC Validator issue, but more likely a “flaw” of the SENDIGv3 specs?

In practice, we know that we’ll get SUPP-- entries more likely for --ORRES or for user-defined variables (whose length we can control), but the above scenario might also happend (QNAM for a variable that has already 8 chars in length like TFSTRESC, TFSPCCND, etc) - and what to do then to keep the QNAM’s content to maximum 8 chars in lenth?

Thanks!