SDTM

Hello Everyone,

I am here with question regarding one of the warning I received in OpenCDISC report as mentioned below:

We are using OpenDISC Validator 1.3  I have copied the licensed MedDRA Ascii files into their separate sub-folders (14.0, 14.1, 15.0 and 15.1) as instructed in your documentation “Configuring OpenCDISC Validator for MedDRA”.   I get the following error:

We recently ran across an issue where a date was incorrectly generated like this: 2012-10-10T12:-- (Note the trailing dashes) It was caught on manual review, but I am surprised that check SD0003 did not fire, as this is not a valid ISO date.

The Description has the following text in parenthese:

(outside of 32-127 ASCII code range)

I think there is a typo

I think the correct value for second number should be 126

Sorry if this is posted somewhere already or covered in documentation ... perhaps I missed it.  Does the SDTM validator re-attach the SUPPxx data sets to the parent domains, thereby checking the content of SUPPxx as opposed to jsut the structure of SUPPxx?

Hi all,

I thought that there was an error check for the uniqueness of TEST/TESTCD. (They had to match 1-1)

We had a study with the following error, and we I cannot figure out why we didn't get an error with OpenCDISC Validator.

I understand in they example below that UNIT1/UNIT2 don't belong as part of the TESTCD.

However, I don't understand why we didn't get this an error in the OpenCDISC Validator Report.

Hi Team,

We recently discovered this issue on OpenCDISCv1.3:

Our study has 4 split QS domains (e.g. QSAA, QSBB, QSCC and QSDD). Out of these four split domains, QSCC had no observations. All four domains were included in the OpenCDISC Validator run and the tool only reviewed domains QSAA and QSBB. It did not process QSCC and QSDD. We understand that QSCC was not processed as it was an empty domain, however we didn't realize that the tool would overlook/exclude the next valid QSxx domain.The tool reviewed QSAA, QSBB and QSDD after QSCC was removed from the "review list".

 

For continuations, the split between COVAL and COVAL1 text will sometimes trip a warning if the continuation text block begins with a space. Should the first part of the rule that

"Character values should not have leading space ' ' characters or '.' as an entire value

be suspended / not applied for continuation fields, where absense of space would be run-together text?

Please consider and advise. 

No issue