t travis
on

 

This message posted by Travis on behalf of Kumar Komuralli:

Can someone help me to understand more about the differences between SDTM and SDTM Plus?  Why do some companies use SDMT Plus instead of just SDTM.  Starting jan 1st 2017 as we all know datasets need to be submitted to FDA in SDTM format so what is the plan for those companies who use SDMT plus?  does FDA accespt this?  Please share your thoughts/ knowledge about this.

thansk, Kumar

Forums: SDTM

t travis
on May 14, 2015

Hi Kumar,

 

SDTM + is taking the suppqual variables and “illegally” putting them as additional columns in the base SDTM domain.  Such as putting a new variable called “TRAVIS”  in my AE domain.  Automated programs can split a plus column and push it into SuppQual  domain where it belongs when needed, or vice versa.  Some companies find it easier to work with wide & fat “Plus” data to do their work, instead of tall & skinny Suppqual data.

 At this point FDA does not accept Plus format.

j Jozef
on May 15, 2015

There are very many advantages of using "SDTM+" when doing the mapping from operational data to SDTM data.
Reasons are the one already mentioned before: non-standard variables (NSVs) are kept into the domain / dataset where they really belong and then split off to SUPPxx at the very last moment, as the FDA does not allow yet that the NSVs remain in the real dataset where they belong.
There are however ongoing discussions within the FDA on this, as some/many (?) reviewers do not have the capabilities / tools to bring SUPPxx records for NSVs back to the parent record, which hinders the review process enormously.

There are however many other good reasons for SDTM+: SAS-XPT has the 200 character limitation, meaning that data points with more than 200 characters have to be splitted in "200 character chunks". Only the first one is kept in the original data set, and the other chunks are "banned" to SUPPxx. Most mapping tools do not use SAS-XPT internally but either a propriety format or XML. So these tools ignore the 200 character limitation, and just split off the characters beyond the 200nd at the very last step in the progress, when "downgrading" to SAS-XPT.
A special case is the CO domain ("Comments" domain) where one need to generate additional variables like COVAL1, COVAL2, etc. for the chunks of data after the 200nd character. For most tools, it is much easier to ignore this too (so being "SDTM+") and then do the split in the very last step when generating SAS-XPT.

Whereas the first issue (NSVs - discussed before) could easily be resolved by "flagging" NSVs in the define.xml, the second (200 character limitation) is a severe one which can only be resolved by swiching to the new CDISC Dataset-XML format as the transport format for 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.