SDTM

Description

Technical support questions about SDTM standard and validation rules

January 6, 2016
Hi, Can someone point me to some documentation that explains the xxTPT and xxDTC relationship? I understand the xxTPT/xxTPTNUM/xxTPTREF relationships, but xxTPT and xxDTC is new to me.
Read More
January 5, 2016
I have a record where xxSTRESC = 01 and xxSTRESN = 1. For another record, I have xxSTRESC = 080 and xxSTRESN = 80. I do not believe this is an issue, as I have seen data like this many times before and it’s never been flagged in previous OpenCDISC releases. When selecting the 3.1.3 FDA checks in Community 2.1.0, this is not flagged as an issue. However when I run the validation using PMDA 3.1.3 checks, SD1212 does state that this is an issue where xxSTRESN does not equal xxSTRESC. Is this an issue with the PMDA checks, or was this intentional?
Read More
January 5, 2016
When selecting the PMDA 3.1.3 checks, SD1203 is correctly flagging DADTC dates after RFPENDTC, and also correctly flagging xxDTC dates in a custom findings domain as being after RFPENDTC. However when the FDA 3.1.3 or 3.2 checks are selected, SD1203 is not showing this same issue. Also when I go to the “Rules” tab, SD1203 is not listed out. Has this check been removed from the latest Pinnacle 21 Community 2.1.0 release?
Read More
January 5, 2016

RELREC.USUBJID is an expected variable, however Pinnacle 21 Community 2.1.0 is flagging an error stating that RELREC.USUBJID is

Read More
January 4, 2016

Hi!

I have a case where this check pops up only when generating the cdisc report together with the define.xml. However, when using only the SDTM datasets, this check does not appear. Is anyone able to explain why this is so?

Thanks!

 

Read More
December 9, 2015

Hi,

According to the IG 3.1.3 (section 7.6) or IG 3.2 (section 7.4), Example 2 shows an example of how to implement the null lfavor in TSVALNF when the value in TSVAL is missing. In this case, TSVCDREF should be assigned to "ISO 21090".

In my SDTM.TS dataset, some records are populated as follow : TSVAL and TSVALCD are null, TSVALNF is filled in with null flavor values (ie NA, UNK) and TSVCDREF = ISO 21090 for TSPARMCD = INDIC, PCLAS, REGID, TINDTP, TRT.

Read More
December 8, 2015

Hi,

I just use the latest community 2.1 to validate SDTM datasets (3.1.2). However, I found four wield hits which doesn't seem correct. The report output four label mismatch for AESEV and LBSTNRC, but I double checked and compare with the previous report. I think it might be a false alarm. Please share your thoughts.

AESEV, Severity/Intensity

LBSTNRC, Reference Range for Char Rslt-Std Units

TAETORD, Order of Element within Arm

IETESTCD, Incl/Excl Criterion Short Name

Read More
November 19, 2015

I am validating on SDTM 3.2, where PCSTRESC label is Character Result/Finding in Standard Format, however when i create xpt's the label is truncated to 40 char, So OpenCDISC gives a warning, Is there a solution to this? There are many labels in SDTM IG 3.2 where variable labels are more then 40 Chars. 

Please do let me know your thoughts.

Thank you.

Read More
November 10, 2015

These rules seem to be firing for the trial phase codelist due to letter case mismatches.  The relevant Pinnacle codelist metadata (OID = "CL.C66737.TPHASE" and OID = "CL.C66737.TPHASE.CD") appears to have all of the values upcased, but the CDISC published terminology for codelist C66737 has mostly mixed case values.

Read More
November 9, 2015

Hi

I am using Open CDISC Validator 2.01 with CDISC CT Version: 2015-06-26 and it is giving a Warning when the units  for PCORRESU or PCSTRESU are ng/mL. Not sure the reason for getting this Warning eventhough ng/mL is CDISC submission value for PK Units of Measure. Any clue for this Warning?

Thanks for your help in advance!

Srim

Read More
Subscribe to SDTM

Want a demo?

Let’s Talk.

We're eager to share and ready to listen.

Cookie Policy

Pinnacle 21 uses cookies to make our site easier for you to use. By continuing to use this website, you agree to our use of cookies. For more info visit our Privacy Policy.