SDTM

Hello team,

I think I got a false positive based on an incorrect version of the 3.1.1 Config file. The SU domain config file shows that VISITNUM has the Label "Visit Name" but it should really be "Visit Number". 

Also in the config file VISIT has the Label "Visit Number" but it really should be "Visit Name"

See below

I'm getting this error because I have records in DM with ARMCD != SCRNFAIL/NOTASSGN and also not in TA.

However the SDTM implementation guide seems to suggest this is permissable in trials with multiple branch points, e.g. see Example 7 p63 / section 7.2.4.2 on p238.

Should this be a WARNING instead?

Cheers

Martin.

Hello Team,

I got this error message:

EG        TYPE, VARIABLE    Char, EGLOINC    SD0055    SDTM/dataset variable type mismatch

However, when I look in the eg.xpt file at the metadata EGLOINC is character.

EGLOINC    Char    10    10    $10.    .    LOINC Code

David

Running the latest validator program I got this error message for the EG domain using SDTM V 3.1.2

"Value for EGSTRESC not found in EGSTRESC controlled terminology codelist"

The records that were highlighted were the direct copy of measurements from EGORRES to EGSTRESC. This may be a false positive result.

I noted in the SDTMIG that generally the assumption is that any value in --ORRES should be derived or copied into --STRESC. So flagging numeric values for the ECG intervals of 62 msec seems to be a false positive.

Can someone clarify this?

Thanks!

Hello,

We are submitting data to the FDA and it appears that the rule CT0037 looks for the SOC to be in ALL UPPERCASE format. However, the FDA has asked us to provide the MedDRA coding in the standard MedDRA sentence case format.

The FDA advice letter said " The spelling and capitalization of MedDRA terms must match the way the terms are presented in the MedDRA dictionary. For example, do not provide MedDRA terms in all upper case letters"

Is there are way to modify Rule CT0037 to recognize this updated format request? 

Thanks -- Dave Borbas

We work with vendors to generate the SDTM datasets we need. First we work on the specifications. Has anyone had experience with converting file specs from Excel into SAS and then checking the results with Open CDISC? This seems like it should be possible without incredible efforts.

Thanks!

I'm pretty confused about this. I'm using NOTASSGN as the arm code for subjects who enter run-in but are not randomized, as described in impl guide 3.1.2. However I've also put records in EX for these subjects because they are receiving study treatment during run-in (placebo in this case, but I know of other trials which have active non-randomized run-in periods).

I'm guessing this means I can't use NOTASSGN and have to invent a new arm code for these people, but it just seems wrong! Anybody know more about the background to this rule?

Thanks,

Martin

I have a sponsor-defined findings domain XX.

When I validate the dataset xx.xpt I get a warning that rule SD0057 is violated: variable XXDTC is missing. It is "expected".
I do indeed not have this variable in my dataset.

My question:
- I have not been able to find in the standards document nor in the IGs that --DTC is expected in the case of a sponsor-defined domain. Can you point me to the paragraph where this is stated?
Or has it simply be assumed that it is so as it always is expected in the standard findings domains?

Many thanks in advance,

Are the OpenCDISC.org, SDTM 3.1.1 and 3.12 rules based on the latest WebSDm release 3.0? 

1. Curious to know why this rule is specified in RULES link in home page and not in the latest download Config folder.

2. Are the SDTM 3.1.1 and 3.12 rules based on the latest WebSDm release 3.0?