Subscribe by Email

Your email:

Posts by category

Follow Us

Quanticate CRO Blog

Current Articles | RSS Feed RSS Feed

CDISC SDTM v3.1.2 Theory and Application

  
  
  

A member of the Clinical Programming Team writes about their experience at the CDISC interchange in Brussels held on 11th-12th April 2011.

cdisc sdtm

I recently attended a 2 day training course on the theory and application of Clinical Data Interchange Standards Consortium (CDISC) Study Data Tabulation Model (SDTM), for v3.1.2 of the implementation guide, at the CDISC interchange in Brussels.  Although I already had good knowledge in SDTM, I was able to obtain a lot of useful information from those at the meeting, particularly for submitting clinical and preclinical data to the Food and Drug Administration (FDA) and general guidance and tips for implementation.  The course covered a number of interesting topics including the history of CDISC and SDTM, FDA reviewer tools, dataset and variable metadata and tips for production of the Case Report Tabulation Data Definition Specification (define.xml), general observation classes, creating custom domains, date/time, duration and relative time variables, and changes from v3.1.1 of the implementation guide including the Findings About domain.

One of the questions that came from a fellow attendee at the start of the course was, "If it is not yet compulsory to submit data in CDISC SDTM format then why should we change our standards to do this?".  The instructor then began to give a good answer to this.  However, after the 2 days it was clear that the question was answered by the content of the course itself and from listening to other people’s experiences.

So what are the advantages of SDTM?  First of all, the main advantage is of course standardization.  Standardization is important not only to make it easier for regulatory bodies to review data across studies, but also to ensure all studies conform to the same high standard.  The CDISC SDTM model is reviewed by many experts across the industry on an ongoing basis to strive towards the best standard and so the model is continuously improving. Standardization between studies within a company will also provide more efficiency for the individual company, in terms of standardized code to produce domains and for reporting and analyses.  This is an area that I am involved in within Quanticate and it can save a lot of time in creation and validation.  Having a standardized structure will also make it easier to check the integrity of the data from a data management perspective.  Standardized checks could be written and performed while a study is still active.

Another advantage of SDTM is in the actual review of the data.  It will be a lot easier for regulatory bodies such as the FDA to review data.  In fact, the FDA have their own reviewer tools that are run to obtain the information they require to review a submission.  This means that it is not necessary to provide subject listings with the submission and the number of queries sent to the submitting company should be significantly reduced.  Similar tools could be used internally by individual companies to help to review safety and efficacy.  For example, tools are available that can create patient profiles, since data is in a standardized structure.  Hence, one could run a simple report to present the data for a subject (e.g. adverse events, concomitant medications or abnormal clinical laboratory results, electrocardiogram [ECG] or vital sign parameters) in such a way that is easy to interpret and could show whether the subject was receiving treatment when a particular adverse event or abnormal laboratory result occurred.

Another question that arose during the course was, "Is it possible to submit data as CDISC SDTM compliant if those data fail a particular requirement?".  The answer to this is that, unless there is a very good reason otherwise, the data should follow the CDISC SDTM recommendations.  However, in certain cases this is not always possible.  For example, suppose adverse event severity is collected on the CRF as a Yes/No variable for severe.  This does not conform to the CDISC controlled terminology for AESEV, which is instead Mild/Moderate/Severe, but suppose it is too late to change the CRF.  This means when running any validation checks (e.g. using the PROC CDISC SAS procedure, open CDISC validator or WebSDM), an error will be obtained.  In this instance it is acceptable to submit these data as long as the reason is detailed within the reviewers’ guide that will be sent along with the submission, it may just mean that a particular report may not be able to run.  So it is possible to submit data that fail specific checks, but this should be a last resort and a valid reason should be given with the submission.

 

Related Blog Posts:

 

cdisc-guide-cta-2

 

 

Comments

Thanks for this excellent report about the SDTM course you attended. The great thing about this training is that we (CDISC) have excellent trainers with a lot of experience, so that participants do not only learn the theory, but also obtain a lot of tips and "do-s" and "don't-s". 
 
Just one remark: there are much better and user-friendlier tools for generating SDTM datasets from operational clinical data than the statistical package you mention.  
 
In my opinion, using a statistical package for generating SDTM datasets is an expensive overkill. 
 
Posted @ Friday, June 10, 2011 9:35 AM by Jozef
Dear Jozef, 
 
Thank you for your comment, it certainly was a good course and I learnt a lot of valuable information. 
 
Regarding the statistical package for generating SDTM datasets, we currently use SAS. The reason for this is that, being a global CRO, we offer statistics as well as data management and programming, and so SAS is currently our primary package. This is not simply about the cost of the software, it is also about utilising people’s skills in using the software. Of course, we are always open to new and cheaper ways of doing things.
Posted @ Wednesday, June 22, 2011 8:55 AM by Programming Consultancy Team
Thanks a lot for sharing such a piece of valuable information. 
 
 
 
Is there any guide which descibes the case of values for a variable under SDTM?
Posted @ Friday, July 22, 2011 3:34 AM by M K Sinha
Yes, there are guides available. The Study Data Tabulation Model Version 1.2 gives information on the actual model and the Study Data Tabulation Model Implementation Guide Version 3.1.2 is a guide for the organization, structure, format of and describes the content of each published standard domain. 
 
 
 
These guides are available to download from the CDISC website: http://www.cdisc.org/sdtm
Posted @ Friday, July 22, 2011 4:39 AM by Programming Team
Hi, 
 
 
 
Can you please let me know which section of SDTMIG refers to the CASE of values for a vraible? 
 
 
 
Thanks
Posted @ Friday, July 22, 2011 4:59 AM by M K Sinha
Section 4.1.2.4 of the implementation guide (Version 3.1.2) contains the case use of text in submitted data. I think this may be the section you are looking for. 
 
 
 
 
 
 
 
“It is recommended that text data be submitted in upper case text. Exceptions may include long text data (such as comment text); values of --TEST in Findings datasets (which may be more readable in title case if used as labels in transposed views); and certain controlled terminology (see Section 4.1.3.2) that are already in mixed case. The Sponsor‘s define.xml may indicate as a general note or assumption whether case sensitivity applies to text data for any or all variables in the dataset.” 
 
 
 
Posted @ Friday, July 22, 2011 5:12 AM by Programming Team
Please check the latest DTM terminology for representation case of values for a variable under SDTM.
Posted @ Wednesday, February 29, 2012 10:19 PM by Latha
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics