SDTM

Hi All,

I was a bit confused by this. Since *DY variables can definitely be negative but apparently not zero this would imply that the day before 'Study Day 1' is 'Study day -1' (i.e. study days are rounded away from zero). Is this the case?

Thanks for any help!
Martin.

The SDTM Implementation guide states in section 5.2.1.1., that COVAL can be extended by additional variable like COVAL1, COVAL2, ... COVAL199 etc., when comment text is too long to fit into the 200 characters of COVAL.

But when doing this, OpenCDISC shows a warning as of a violation of rule SD0058. This rule should be modified to allow for such additional COVAL+i variables in CO.

(I'm thinking this is an easy one...)

LB1,LB2,LB3 and LB4 are LB datasets; PE1-PE5 are PE. I get a 'Configuration Unavailable' error when I attempt to validate together.

Can I validate in the same run? If so, how may I do that?

Thanks!

Sean

The rule SD0003, which checks for correct ISO8601 date strings is based on a regular expression, which is incomplete and does not cover all valid ISO8601 strings.

ISO8601 allows for a timezone expression, which indicates the difference between local time an UTC. This is indicated by "+/-hhmm" or "+/-hh:mm". Reference: ISO 8601 2004 standard at paragraph 4.2.5 (page 17-18). An example: "2009-09-23T00:00:00+01:00" .

Are there any example XPT files that have been created for testing the SDTM 3.1.2 or SDTM 3.1.1 versions?

Hi... I'm using v3.1.2. It's very good, but there are a few problems:

I get SD0062 Incompatible data source error when I try to validate SDTM 3.1.1 dataset through the production release of the validator.  The .xpt file is a valid file as I can view it using SAS Viewer.  The error occurs with all the domains.  There is no log message in the trace.log and the error message is rather vague so I am not sure where to look for the source of the problem to try to fix the issue.  Please advise how to overcome this error.

Shouldn't this check take into consideration the LBCAT since there are tests that can span categories and end up having different standard units?

Thanks.

Hello Team,

SD0070 - No exposure record for subject is being output but the records in DM are SCRNFAIL (ARMCD). I think the check should be modified to ignore Screen Failures since they will not have a record in the EX domain.

David

Hello Team,

I did not use a define.xml file when I ran the checks (I don't have one) but I get the following warnings. These domains do not exist in the study I am running against OpenCDISC.