SDTM

Since SAS and Define-XML using differing data type classifications (numeric and charcter for SAS; text, integer, float, date, time, datetime, etc. for Define-XML), how does OpenCDISC work out if the data types match between the data and Define-XML? Does the validator actually look into the data to try to assign the type as it would appear in Define-XML and then match that against what is in the actual Define-XML file contents? Thanks in advance.

SD1023 looks at looks at the text value of VISIT to decide whether a visit is unscheduled or not. There isn’t controlled terminology for unscheduled visit descriptions, nor is there any expectation expressed in the SDTM IG for a value convention. The appropriate way to check whether a visit is unscheduled is to check to see if the VISIT in SV has SVUPDES populated. We use the convention, "UNSCHEDULED - {visit number}", e.g. "UNSCHEDULED - 20.01" for unscheduled VISIT descriptions. We are getting lots of false hits with the OpenCDISC check that must be explained in the SDRG.

Study Day of Visit/Collection/Ex am

There is a space on the label for all --DY variables that aren't pre-specified for a domain (like CMDY if you have CMDTC).

I'm getting this message for essentially anything that could possibly be considered a "custom domain".  I have a PD domain that is for pharmacodynamics and looks like PC.  Every variable is generating this message.   I also have separate a SUPP dataset for each domain that needs it and every single one of those and every single one of their variables is generating this message.  The SUPPs are easiest to check in the define and all of their variables have DataType="text", so I'm not sure what the deal is here. 

I got quite a few such warning messages when I ran the validator all in the urinalysis tests. However, these test results, such as pH or urine Glucose, don't usually associate with a unit. Can we ignore these warnings?

Thanks,

Tribeca

The new validator seems to have a check for the SOC Code (SD2016) being run against the SOC Text variable.

Hi, For the extensible codelists for LBTESTCD and LBTEST, this message is firing as an Error for every term beyond the codelist.  It seems the behavior in 1.3 was much more appropriate for the extensible codelist.  Will it be fixed in the update?

Thank you!

Regards,

Joan

I tried the new validator with 3.1.3 yesterday (thank you for all your effort on getting this done) and found some strange things:

 

I think its meant to look at AESOCCD, but it appears to be looking at AESOC.  Obviously none of the SOC names will match the codes.

In Opencdisc version 1.4, quite a few rules have been added, one of them is SD1082.