A member of the Clinical Programming Team writes about their experience at the CDISC interchange in Brussels held on 11th-12th April 2011.
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 regulatory 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:
- Creating Custom or Non-Standard CDISC SDTM Domains
- Using CDISC SDTM to Improve Cost and Quality in Integrated Summaries