It's a safe bet that most people's first introduction to CDISC is through the SDTM. This is a content standard that ensures clinical data is submitted in a consistent manner, helping reduce review time and facilitating cross study analysis. Another content standard, ADaM, aims to perform a similar function for analysis datasets. Likewise SEND defines standardized domains for non-clinical data.
Adoption of these standards is driven by regulators such as FDA and PMDA, who mandate that data must be submitted in these formats.
This post gives a very brief overview of each model, how they fit in with the wider clinical trial process, and how you can get maximum benefit from them.
The bad old days
Prior to the year 2000, clinical trial submissions were like the wild west. Anything went. There was no standardized way to provide any particular type of data, so each organization could submit the same information in completely different ways. Worse than that, individual organizations could submit the same information in different ways for different studies. The format of the submitted data was not controlled. This led to huge inefficiencies for both sponsors and regulators.
Sponsors often ended up with different ways of presenting data for each study, which had to be hand coded each time. This led to inconsistencies, and inconsistencies led to errors. Coding of analysis datasets was a huge effort as the source data was not in a consistent format. Similarly coding of TLFs was hindered by the analysis data not having a standard format across studies. Any sort of cross-study analysis could be hugely difficult as data was collected and tabulated in different ways.
Regulators had similar issues. Every study was unique, so the reviewer had to understand how the data was presented for each study.
Sorting this problem was one of CDISC's core missions. The result is three standardized content models: SDTM, ADaM and SEND.
SDTM - Standardizing clinical datasets
CDISC's Study Data Tabulation Model (SDTM) is often thought of as the core of what CDISC is. It defines standardized domains for submitting clinical data, which means that regulators have a consistent way of viewing data and analysis datasets have a common data format to work from. People don't need to learn for each study how a particular sort of data is represented. This is key for regulators to be able to efficiently process submissions.
SDTM consists of two standards. The core SDTM model defines different classes of domains (Events, Interventions, Findings), each of which has a number of possible variables. The SDTM Implementation Guide defines a set of standard domains based on the core model, such as AE (Adverse Events) and VS (Vital Signs). Where submission data relates to domains in the Implementation Guide it must be submitted using these standard domains. Where there isn't a relevant domain in the Implementation Guide, a custom domain is created based on the domain classes defined in the core SDTM model.
Sometimes people think that SDTM makes things harder as they need to learn how it works and ensure that data is transformed into it. I look at it another way. Using SDTM brings the following advantages:
- Data is more consistent between studies, so less per-study work and less chance of errors
- Consistency makes cross-study and cross-organization pooling and analysis easier
- No need to learn organization-specific dataset formats
- There is a worldwide community to help with any questions, rather than relying on a small number of internal colleagues
- Reviewers can understand your submission quicker, leading to fewer questions and faster approval
One way to simplify the generation of SDTM datasets is to use CDASH when designing your CRFs, as described in my earlier blog, Using ODM and CDASH for CRF design. This ensures that your source data is collected in a manner that is as simple as possible to map to SDTM.
SEND - Standardizing non-clinical datasets
Non-clinical data has exactly the same issues as clinical data with regard to standardization, but the actual domains and variables required to represent the data are different. CDISC's Standard for Exchange of Nonclinical Data (SEND) Implementation Guide is analogous to the SDTM Implementation Guide, defining the standard domains and variables that should be used when submitting non-clinical data. It is based on the core SDTM model, allowing submission of standardized domains that are not described in the Implementation Guide.
ADaM - Standardizing analysis datasets
CDISC's Analysis Data Model (ADaM) is a bit different than SDTM and SEND. It still has a core model and an implementation guide, but the model is not as proscriptive. Additional variables can be added within certain constraints defined by the model. This gives it the flexibility to be used for any type of analysis while providing a level of standardization that allows it to be easily understood by reviewers.
Analysis Results Metadata for tables, listings and figures
CDISC have also standardized the description of Analysis Results Metadata (ARM) for describing tables, listings and figures. This references the data in standardized ADaM datasets, making simple to re-use your analysis results metadata across different studies.
Working with SDTM, ADaM, SEND and ARM
It's true that there's a learning curve with these standards, but you can reduce the level of expertise required by making use of tools that understand CDISC and do the heavy lifting for you. The first step is to use a CDISC-aware metadata repository. With built in knowledge of the standards, this can help you define all your CDISC metadata right at the start of your study, and also re-use your metadata from study to study in order to greatly reduce study build time. You can even go a step further by defining CDISC-compliant organizational standards to increase data quality and simplify regulatory compliance. You can:
- Define all your data up front
- Ensure consistency across studies
- Standardize mappings between different parts of the clinical lifecycle
- Drive study designs from standards
- Perform compliance checks to ensure adherence to standards
Defining your SDTM and SEND datasets early on in your study process enables you to map your source data to your intended submission datasets before actually collecting any data. This can help flag up problems with the CRF design, which can be corrected before actually rolling out the study.
Check compliance to SDTM, SEND and ADaM
There are a lot of rules in the CDISC content standards, so it's important to check that you're using them properly. If you're using a CDISC-aware tool to define your datasets, it will be able to guide you towards compliance and report on any issues.
Using these standards is no longer a choice; FDA, PMDA and other regulators insist on it. This post should leave you understanding the benefits they provide, and that they should be embraced early on in the study process to get maximum benefit.
Download our example compliance reports.
Other posts in this series:
- An Introduction to CDISC standards
- Using ODM and CDASH for CRF design
- Using Define-XML for dataset design
- Using SDTM, ADaM and SEND for regulatory submissions [this]
- Using NCI Controlled Terminology for standardizing data