SDTM

For some AE variables which are defined using Codelist (NY) the validator comes up with the WARNING SD1055:

The length of AE flags variables (AESER, AESCAN, AESCONG, AESDISAB, AESDTH, AEHOSP, AESLIFE, AESOD, AESMIE, AECONTRT) is expected to be 1.

The values for this codelist are "N", "Y", "NA" and "U".

When using the expeceted length of 1 I cannot use the NA.

Even if NA is not allowed for these variables, using length 1 in these variables there will be inconsistencies with other NY-variables in the database. :(

I need to create a custom doamin like (XB) for intervention and for that in CRF I have some values like commments(It's not free flowcomment) so is there any chance I can create custom variable if not how to represent them?

How to populate a country variable in DM doamin if it's not captured in CRF? please suggest

Hi OpenCDISC Team,

The error check SD1029 was added in the recently released v1.3 of the OpenCDISC Validator.

The rules define it as:

 

 

SDTM 3.1.2 Amendment 1 variables are still being flagged as invalid, as per rule SD0058. What could the problem be?

Dear OpenCDISC users,

The OpenCDISC team receive many questions through Contact Form. Unfortunately about 20% users misspelled their email address. Sometimes we can figure out the correct one ;), but in most cases it’s impossible to answer your question because that issue. Now I use the forum to handle one of such cases.

Original question:

"1. In the open cdisc report detail sheet, is the "record" is the actual record number in dataset?

In the v1.3 configuration file, rule SD1048 ("Total Daily Dose (--DOSTOT) must not be populated, when there is no data in Dose (--DOSE) and Dose Description (--DOSTXT)") isn't supported by the SDTM IG rules and is opposite to the intent of --DOSTOT. --DOSTOT is to be used when individual --DOSE is NOT collected. Likewise, --DOSTOT (and --DOSE) are mutually exclusive with --DOSTXT; they shouldn't be populated concurrently.

So SD1048 needs to be removed.

Randall Austin

Hi, I've come across many submission packages, and it is quite interesting to see the many variations for domain names (not abbreviations or custom domains). I provided some examples across the board for this, just to exemplify how many variations exist. Based on CDISC input, the SDTMIG should be utilized and, at some point in the future, a correlating CodeList will exist for standard domains. Out of curiosity, why does OpenCDISC utilize the mentioned domain name over the SDTMIG? SDTM Terminology 2011-07-22 CT Code C61536 IE = Inclusion/Exclusion SDTMIG 3.1.2

Hi,

FDA CDER and CDISC have released new documents for data submission last week (Dec. 2011), and CDER recommends implementation of CDISC's "Amendment 1 to the SDTM v1.2 and the SDTM Implementation Guide V3.1.2." Refer to FDA document at

Hello,

It seems that SDTM variables should not attach any sponsor defined formats. I have one senario:

1. Define format $SEXC as M--Male, F--Female;

2. Attach $SEXC to DM.sex varable;

3. Send the DM (in XPT) to the OpenCDISC SDTM Validator.

How will the OpenCDISC SDTM Validator respond to sex ? Any errors or warnings (by which Rule ID) ?

Similar issues to ADaM dataset.

Thanks,

Cheng