CDISC models used to standardize data collection, data tabulation, and creation of analysis datasets are implemented with purpose in mind. This section guides the selection of standards to used based on:
- Tobacco product study use cases covered in this guide.
- The purpose of a standard model in relation to these use cases.
The table below relates use cases to models implemented in the TIG.
CDASH:
Throughout this document, a deliberate decision was made to use a variety of synonyms for various terms in order to reflect the fact that sponsors also use a variety of terms.
- Paper CRFs vs. electronic CRFs: The term CRF used throughout this document refers to both paper and electronic formats, unless otherwise specified.
- Fields vs. variables: Data collection fields refers to terms that are commonly on the CRF. Data collection variables refers to what is in a clinical database.
- Study treatment: The phrase study treatment has been used instead of investigational/medicinal product, study drug, test article, vaccine, study product, medical device, and so on, in order to include all types of study designs and products.
- Mechanisms for data collection: Different data-collection mechanisms can be used to control how data are collected (e.g., tick boxes, checkboxes, radio buttons, drop-down lists). For the purposes of this document, these terms are used interchangeably.
Subjects are... Note that generally the term "trial" is equivalent to "study" in the nonclinical context. In addition, "subjects" are equivalent to "animals."
Values in this column should be used with values in TIG Core to determine when a field should be present on a CRF.
How collection, tabulation, and analysis standards are related.
SDTM
Observations about study subjects are normally collected for all subjects in a series of domains. A domain is defined as a collection of logically related observations with a common topic. The logic of the relationship may pertain to the scientific subject matter of the data or to its role in the trial. Each domain is represented by a single dataset.
Each domain dataset is distinguished by a unique, 2-character code that should be used consistently throughout the submission. This code, which is stored in the SDTM variable named DOMAIN, is used in 4 ways: as the dataset name, as the value of the DOMAIN variable in that dataset, as a prefix for most variable names in that dataset, and as a value in the RDOMAIN variable in relationship tables (see Section 8, Representing Relationships and Data).
All models implemented as part of this guide collect and represent data by common topics with:
- CDASH and SDTM grouping logically related data points in domains; and
- ADaM dataset design customizable to support analysis requirements.
SEND
Aside from a limited number of special-purpose domains, all subject-level SDTM datasets are based on 1 of the 3 general observation classes. When faced with a set of data that were collected and that "go together" in some sense, the first step is to identify SDTM observations within the data and the general observation class of each observation. Once these observations are identified at a high level, 2 other tasks remain:
- Determining whether the relationships between these observations need to be represented using GRPID within a dataset, as described in Section 8.1, (SENDIG v3.1.1) Relating Groups of Records Within a Domain Using the --GRPID Variable, or using RELREC between datasets, as described in Section 8.3, (SENDIG v3.1.1) Supplemental Qualifiers - SUPP-- Datasets
- Placing all the data items in 1 of the identified general observation class records, or in a SUPP-- dataset, as described in Section 8.5, (SENDIG v3.1.1) Relating Findings To Multiple Subjects - Subject Pooling
In practice, considering the representation of relationships and placing individual data items may lead to reconsidering the identification of observations, so the whole process may require several iterations.
ADD MORE TEXT HERE
Overview
Content Tools