Clinical Data Acquisition Standards Harmonization (CDASH) User Guide

Transcription

1 Clinical Data Acquisition Standards Harmonization (CDASH) Prepared by: CDISC CDASH Project Team CDASH_UG April 2010

2 CDASH V1.0 Table of Contents Section Page 1.0 Introduction Purpose Organization of this Document Explanation of Table Headers Information for End Users CRF Designers (or Developers) Database Builders or Administrators SDTM Programmers General Information Review the CDISC Standards Documents Conformance Rules for CDASH Tier Conformance Terms Used in this Document Variables and How to Use Them CDASH Core Designations Using Fields That Do Exist in CDASH Creating Fields That Do Not Exist in CDASH Mapping from CDASH to SDTM Datasets Mapping collected dates and times to SDTM RELREC-Creating Relationships between Collected Case Report Form Data General Recommendations on Screen Failures Order of Fields in Each Domain Normalized vs. De-normalized Data Structures LB Domain VS Domain QS Domain Form Level CRF Instructions General Design Considerations for Completion Instructions General Content Considerations for Completion Instructions CDASH ODM Introduction Description Use of OIDs in CDASH file CDASH_UG-1.0 ii 19 April 2010

3 CDASH V1.0 Table of Contents Section Page 3.0 Domain Implementation Reference Common Identifier Variables Adverse Events (AE) CDASH to SDTM Mapping AE Implementation Examples AE Completion Instructions Adverse Events (AE) ODM CRF Examples AE Comments (CO) CDASH to SDTM Mapping CO Implementation Examples CO Form Level Completion Instructions CO ODM CRF Examples CO Concomitant Medication (CM) ATC Classifications CDASH to SDTM Mapping CM Implementation Examples CM Form Level Completion Instructions CM ODM CRF Examples CM Paper CRF Example CM EDC CRF Example CM Demographics (DM) CDASH to SDTM Mapping DM Implementation Examples DM Form Level Completion Instructions DM ODM CRF Examples DM Disposition (DS) CDASH to SDTM Mapping DS Implementation Examples DS Form Level Completion Instructions DS ODM CRF Examples DS Drug Accountability (DA) CDASH to SDTM Mapping DA Implementation Examples DA Form Level Completion Instructions DA CDASH_UG-1.0 iii 19 April 2010

4 CDASH V1.0 Section Table of Contents Page ODM CRF Examples DA ECG (ECG) ECG Test Results (EG) CDASH to SDTM Mapping EG Implementation Examples EG Form Level Completion Instructions EG ODM CRF Examples EG Exposure (EX) CDASH to SDTM Mapping EX Implementation Examples EX Form Level Completion Instructions EX ODM CRF Examples EX Inclusion and Exclusion Criteria (IE) CDASH to SDTM Mapping IE Implementation Examples IE Form Level Completion Instructions IE ODM CRF Examples IE Lab Test Results (LB) CDASH to SDTM Mapping LB Implementation Examples Form Level Completion Instructions LB ODM CRF Examples LB Medical History (MH) CDASH to SDTM Mapping MH Implementation Examples MH Form Level Completion Instructions MH ODM CRF Examples MH Physical Exam (PE) CDASH to SDTM Mapping PE Implementation Examples PE Form Level Completion Instructions PE ODM CRF Examples PE Protocol Deviations (DV) CDASH to SDTM Mapping DV CDASH_UG-1.0 iv 19 April 2010

5 CDASH V1.0 Section Table of Contents Page Implementation Examples DV Form Level Completion Instructions DV ODM CRF Examples DV Subject Characteristics (SC) (Findings) CDASH to SDTM Mapping SC Implementation Examples SC Form Level Completion Instructions SC ODM CRF Examples SC Substance Use (SU) CDASH to SDTM Mapping SU Implementation Examples SU Form Level Completion Instructions SU ODM CRF Examples SU Vital Signs (VS) CDASH to SDTM Mapping VS Implementation Examples VS Form Level Completion Instructions VS ODM CRF Examples VS Fields Considered Not Necessary to Collect on CRFs Common Identifier and Timing Variables Adverse Events Concomitant Medications Demography Disposition Drug Accountability ECG Test Results, Scenario ECG Test Results, Scenario ECG Test Results, Scenario Exposure Inclusion/Exclusion Laboratory Test Results, Scenario Laboratory Test Results, Scenario Laboratory Test Results, Scenario Medical History CDASH_UG-1.0 v 19 April 2010

6 CDASH V1.0 Table of Contents Section Page Protocol Deviations Substance Use Appendices Appendix A: Information for End Users Appendix B: Variable Naming Implementation Examples Appendix C: CDASH Authors Appendix D: Acknowledgements Representation and Warranties, Limitations of Liability, and Disclaimers CDISC Patent Disclaimers Representations and Warranties No Other Warranties/Disclaimers Limitation of Liability Revision History CDASH_UG-1.0 vi 19 April 2010

7 CDASH V BIntroduction 1.1 6BPurpose This user guide is an aid to implementers of the Clinical Data Interchange Standards Consortium (CDISC) Clinical Data Acquisition Standards Harmonization (CDASH) standard version 1.1. The aim of the CDASH Standard Version 1.1 is to describe CDISC-recommended basic standards for the collection of clinical trial data. This CDASH is intended to be used together with the CDASH Standard that is available at and describes how to implement CDASH for the creation of standardized Case Report Forms (CRF) used to collect data in clinical trials. CDISC recommends that CDASH Standard Version 1.1 be read prior to this user guide (CDASH UG). This user guide was developed to facilitate those functions involved in the planning, collection, management, and analysis of clinical trials and clinical data, including: Clinical Investigators Medical Monitors Clinical Research Associates (Monitors) Clinical Research Study Coordinators Clinical Data Managers Clinical Data and Statistical Programmers Biostatisticians Drug Safety CRF designers Other functions tasked with the responsibility to collect, clean, and ensure the integrity of clinical trial data As described in CDASH Standard Version 1.1, Sponsors need to determine what additional data fields need to be added to address study-specific requirements based on regulatory and applicable business practices. Until therapeutic area (TA) specific data fields have been standardized, sponsors need to add these fields to the CDASH recommendations to fulfill their protocol-specific requirements. The CDASH standards are part of the CDISC Technical Road Map that is designed to realize the vision of a set of harmonized standards that meet the CDISC Mission and Strategy. The set of standards has been, and will continue to be, developed to support the streamlining of processes within medical research from the production of clinical research protocols through to reporting and/or regulatory submission, warehouse population and/or archive, and post-marketing studies/safety surveillance BOrganization of this Document This document has been organized into the following sections: CDASH_STD April 2010

8 CDASH V1.0 Section 1: Introduction Provides an overall introduction to the purpose and goals of the CDASH UG project as well as describes the organization of CDASH UG version 1.0. Section 2: General Information Provides information on conformance rules for CDASH implementations, the order of variables in domain tables, terms used in this document, as well as sections on CDASH Core Designations, Normalized vs. De-normalized Data Structures, recommendations on screen failures, mapping from CDASH to the SDTM, and a section on CDASH-ODM. Section 3: Domain Implementation References Provides specific implementation on cross mapping between CDASH data collection fields and SDTM variables, CRF form level instructions, and CRF paper and EDC examples for the following domains: -Common identifying and timing variables - Inclusion and Exclusion Criteria (IE) - Adverse Events (AE) - Laboratory Test Results (LB) - Comments (CO) - Medical History (MH) - Prior and Concomitant Medications (CM) - Physical Examination (PE) - Demographics (DM) - Protocol Deviations (DV) - Disposition (DS) - Subject Characteristics (SC) - Drug Accountability (DA) - Substance Use (SU) - ECG Test Results (EG) - Vital Signs (VS) - Exposure (EX) This section also includes tables that contain Variables/Fields Considered Not Necessary on to Collect on CRFs. These tables describe data collection fields that were reviewed by the team during the initial development of the CDASH standard and designated as not necessary to collect on the majority of case report forms. Section 4: Appendices Includes a list of team members, acknowledgments, and supplemental information relevant to use of CDISC standards BExplanation of Table Headers Question Text Descriptive for the collection field; this text may be included in the CRF completion guidelines to provide additional information about the field or it may be included with the prompt on the CRF to provide further instructions to the site. Prompt The concise label, or shortened version of the Question Text, that displays for the collection field on the CRF. CDASH Core The CDASH category for the collection field, including: o HR Highly recommended; the field should be included on the CRF. o R Recommended/Conditional; the field should be collected on the CRF if certain conditions are met. o O Optional; the field may be included on the CRF if it is needed to satisfy study requirements or for the sponsor s operational database. o NA Not applicable in CDASH; not collected on a CRF. SDTM Variable Name The 8 character or less SDTM data element that is part of and describes an observation in the domain. CDASH_STD April 2010

9 CDASH V1.0 SDTM Variable Label The 40 character or less descriptive label for the SDTM variable. SDTM Core The SDTM category for the domain variable, including: Req Variables that are required in the SDTM dataset and cannot have a null value. Exp Variables that are necessary and expected in the domain but which may have a null value. Perm Variables that may optionally be collected or derived, as appropriate, in the domain; permissible variables may have a null value. NS If the variable is not submitted in SDTM or there is no corresponding SDTMIG variable, the NS notation will appear in lieu of the SDTM Variable and Core Designation. In some cases there will still be mapping information for SDTM for these CDASH fields. Implementation Notes Supplemental information about the CDASH field as it relates to the SDTM domain, e.g., implementation guidelines, SDTM mapping instructions, usage examples, etc BInformation for End Users This user guide has been developed to serve 3 distinct user groups in the execution of a clinical trial as it relates to the collection and the compilation of the study data. In the appendices, the organization of the user guide is shown with each section relating to its target audience and then also by listing the different target audiences followed by the sections of the user guide that will be most beneficial to that group. Certainly, some of the sections, such as the conformance rules, pertain to all 3 user groups. The 3 user groups targeted by this guide are: CRF Designers Database Builders or Administrators SDTM Programmers See Appendix A for hyperlinks to the relevant sections for each End User BCRF Designers (or Developers) CRF Designers are those charged with using the CDASH data collection fields as building blocks in order to design a case report form that meets the objectives of the protocol and that facilitates proper and correct data entry. They also would be the group most likely to write CRF completion instructions and to utilize the section of the user guide that provides the detail for each of the covered domains BDatabase Builders or Administrators Database Builders (Administrators) are those that will build the study s underlying database, either in a dedicated CDMS or in an EDC environment. They would ensure that the CRF is in tune with the CDASH core designations and that any variable that is Highly Recommended is included on the CRF. They would also be charged with the creation of variables that do not currently exist in CDASH but are needed to address the objectives of the protocol. CDASH_STD April 2010

10 CDASH V BSDTM Programmers SDTM Programmers would utilize those sections of the user guide that (perhaps along with database builders) address CRF and database structure and would have the most understanding of the implications of what it means to collect data in a de-normalized or normalized orientation. In addition, SDTM programmers would be the group most concerned with the mapping of CDASH variables to SDTM compliant datasets. CDASH_STD April 2010

11 CDASH V BGeneral Information BReview the CDISC Standards Documents Review the CDASH Standard as well as this user guide before attempting to use any of the individual domain models for data collection. For information on preparing collected data for submissions, refer to the Study Data Tabulation Model Implementation Guide (SDTMIG), and the Case Report Tabulation Data Definition Specification (define.xml), available on the CDISC website, for information about an xml representation of the Define Data Definition document BConformance Rules for CDASH B2-Tier Conformance Conformance to the CDASH standard is described in this document at two levels. Tier 1 conformance describes the minimum implementation that is required for an individual CRF to be considered conformant to the CDASH standard. Tier 2 conformance is focused on the operational implementation of CDASH standards as described in this document. Conformance assumes that the implementer may use a subset of the defined domains as appropriate for the study. So, for example, if an individual study does not include the collection of Inclusion/Exclusion exceptions because none were allowed, that CRF does not have to be created for the study. Implementers should bear in mind that all decisions about protocol, CRF and submission data should be in line with the expectations of the Review Division that will be receiving the submission. Conformance also assumes that a sponsor s implementation of CDASH is done in a way that makes sense for the study being conducted, and data collection fields from one domain may be mixed with fields from another domain. So, for example, if it makes sense to ask a disposition question such as was the subject randomized? on the dosing CRF, or if an informed consent date is recorded on the Demographics form, these will not violate the Conformance rules. Tier 1 Conformance is evaluated at the individual CRF level and means that: All Highly Recommended and applicable Recommended/Conditional are present in the CRF. All code lists displayed in the CRF use or map to current published CDISC Controlled Terminology. Subsets of Controlled Terminology may be used. The implementation follows the Best Practice recommendations in Section 3.4 of CDASH v1.1. CDASH Question Text or Prompt is used. In cases where a CRF must be translated for language or cultural reasons, the implementer should ensure the translation is semantically consistent with the CDASH Question Text. Tier 2 Conformance is evaluated at the operational level and means that: All Level 1 conformances are met. CDASH_STD April 2010

12 CDASH V1.0 All data collection fields are defined using CDASH naming conventions in the operational database unless an equivalent SDTMIG variable can be used for data collection in a user-friendly manner (e.g., using recommended input format for data collection) All non-cdash fields in CRF follow CDASH recommendations for Creating Fields That Do Not Exist in CDASH (Section 2.4.3). All Best Practice recommendations in Section 3 of CDASH V1.1 are followed. CDASH_STD April 2010

13 CDASH V BTerms Used in this Document 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 the term data collection: Fields refers to data entry points as shown in an electronic or paper CRF. Variables refers to how the values entered into the CRF fields are stored in a clinical database. Value set refers to a list of valid responses that are provided to the data entry user for entering responses into a field. Study Treatment vs. Investigational (Medicinal) Product: the phrase study treatment has been used instead of investigational (medicinal) product 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, check boxes, radio buttons, drop-down lists, and so on). For the purposes of this document, these terms are used interchangeably BVariables and How to Use Them BCDASH Core Designations BDefinitions The concept of core designations is used as both a measure of compliance and a general guidance for sponsors. The CDASH core variables are categorized in the Core column in the domain tables as outlined in the CDASH standard. To facilitate classification of the different types of data collection fields, the following three categories were used: Highly Recommended Recommended/Conditional and Optional. CDISC assumes that sponsors will determine which data collection fields will be collected based on TA- specific data requirements, protocol, and other considerations. See Assumptions for further information. CDASH initially considered utilizing the SDTM Core Designations of Required, Expected, and Permissible to capitalize on prior understanding of these descriptive designations as well as enable a consistent categorization across CDASH and SDTM standards. Yet, when the CDASH domain tables were constructed, it quickly became apparent that CDASH core designations would often differ from SDTM core designations due to the inherent differences between the manner in which data is collected (to ensure most accurate data) and the structure in which it is reported and submitted. For example, a variable categorized as Required in the SDTM may not be required in CDASH if it can be a derived for SDTM rather than a field captured explicitly on a CRF. CDASH_STD April 2010

14 CDASH V BHighly Recommended The following tables provide some specific examples of these differences. CDASH_STD April 2010

15 BImplementation Examples of Highly Recommended Fields This table gives three examples of Highly Recommended CDASH fields that do not map to Required SDTM variables, and gives the reason for the difference in the core designations between the two standards. Domain Prompt Variable Name CDASH Core SDTM Variable Name AE Start Date AESTDAT HR AESTDTC See additional Information for Sponsors column EG IE ECG Performed Met criteria SDTM Core Reason for CDASH Core Designation Reason for difference with SDTM Core Exp The start date of an adverse event would always need to be collected. EGPERF HR EGSTAT Perm This is needed as a data management tool to verify that missing results are confirmed missing. IEYN HR NS NS This is a Yes/No question that is intended to be used primarily as a monitoring or data management tool to verify that the investigator/site reported any entry criteria that were not met for this subject. An AE Start Date would nearly always be collected so the Sponsor can determine whether the AE occurred prior to or following exposure to the study article. The CDASH core designation of HR indicates that this field should always be present in the AE CRF. However, if it is not collected in an unusual case, the AE start date column would still appear in a SDTM AE dataset, but simply contain a NULL (or blank) value. Thus, the SDTM core designation of Exp is appropriate for the submission standard. Since this flag field is primarily used for reconciliation of collected data not Required for submission. This field is not submitted and therefore has no SDTM Core designation. CDASH_UG April 2010

16 Recommended/Conditional A CDASH Recommended/Conditional field is a data collection field that should be collected on the CRF for specific cases or to address TA requirements (although it may be recorded elsewhere in the CRF or from other data collection sources). This is approximately equal to an Expected variable in the SDTM, which is defined as any variable necessary to make a record useful in the context of a specific domain BImplementation Examples of Recommended/Conditional fields Domain Prompt Variable Name CDASH Core SDTM Variable Name SDTM Core Reason for CDASH Core Designation Reason for difference with SDTM Core AE Start Time AESTTIM R/C NS None Collecting the time an AE was started is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example would be in an early phase study where the subject is under the direct care of the site at the time the event started and the study design is such that it is important to know the AE start time with respect to dosing. No SDTM Core designation since there is no direct one-to-one mapping to a variable for time AE started within the SDTM. If collected, AESTTIM would be derived into the AESTDTC variable in SDTM. DA Date Dispensed DADDAT R/C DADTC Exp The date study treatment dispensed should be recorded for each dispensation for a study with multiple periods or multiple products dispensed. No significant difference in Core designation. EX End Date EXENDAT R/C EXENDTC Perm The condition under which EXENDAT would be needed in a CRF is when a start date and end date are not expected to be on the same date. If the trial design indicates that the start and end date are on the same day, the end date is not required since it can be assigned to be equal to the start date. SDTM states that this may not be relevant for injections and has set the Core designation for this variable as Permissible (similar to optional) rather than Expected BOptional A CDASH Optional data collection field is one that is available for use if needed. This is roughly equivalent to a Permissible variable in the SDTM and should be used in a domain as appropriate when the data need to be collected or derived in the CRF. CDASH_UG April 2010

17 BImplementation Examples of Optional fields Domain Prompt Variable Name CDASH Core SDTM Variable Name SDTM Core Reason for CDASH Core Designation Reason for difference with SDTM Core AE Ongoing? AEONGO O NS NS This field will be completed to indicate that the AE has not resolved at the time of data collection. Upon study completion, it is expected that every reported AE should have either an End Date or the Ongoing field will be completed, but not both. The purpose of collecting this field is to help with data cleaning and monitoring, since this field provides further confirmation that the End Date was deliberately left blank. This is not a direct mapping to the SDTMIG variable AEENRF. The date of data collection in conjunction with End Date and the Ongoing CDASH fields would determine how the SDTMIG variable AEENRF would be populated. In some cases, this information may be determined from AE Outcome. ECG Subject Position EGPOS O EGPOS Perm Results may be affected by whether conditions for ECG as specified in the protocol were properly met. One common condition is the subject's position (e.g., Supine, Standing). If the protocol requires this type of information, then this question may be included to confirm that the subject's position matches the protocol. The following are examples of when it is not necessary to collect these data on the CRF: Position of the Subject is provided as part of the electronic data Position of the Subject is not pertinent to the protocol The protocol specifies only one possible position and the sponsor does not feel there is significant risk of the sites performing the ECG with the subject in the wrong position No significant difference in Core designation. IE Criterion Description IETEST O IETEST Req This information would either be populated on the ecrf when the site entered the IETESTCD and would not necessarily have to be a separate data collection field; or it would appear in the protocol entry criteria list, or on an eligibility worksheet for the subject. The corresponding IETESTCD is Highly The SDTM IETEST value is Required for submission but can be derived from the IETESTCD that is collected in the database. This allows IETEST to be Optional within CDASH. CDASH_UG April 2010

18 Domain Prompt Variable Name CDASH Core SDTM Variable Name SDTM Core Reason for CDASH Core Designation Reason for difference with SDTM Core Recommended and would need to be recorded in the CRF/eCRF for each criterion that was not met by the subject. The underlying database would then use the IETESTCD to populate IETEST for the submission dataset. CDASH_UG April 2010

19 BUsing Fields That Do Exist in CDASH Use CDASH naming conventions for all CDASH defined fields in the operational database. The CDASH naming conventions may be used as either the full variable name or the root (or core) name of the variables in the operational database as needed. The intention is to have end-to-end traceability of the variable name from the data capture system to the SDTM datasets. It is recognized that particularly in an EDC system, the variable name of a data collection field, as well as the name in the underlying database, may have various system components that become part of the item s identifier. EDC systems, prior to exporting data in a defined format, may require the variable name to include such database references as the EDC page name, the item group name, or perhaps a combination. Examples could include: <refname> CONMED_IG_CM.IT_CMINDC <refname> STDYDRUG_IG_EX.IT_EXSTDAT (mapped as part of EXSTDTC) <refname> STDYDRUG_IG_EX.IT_EXSTTIM (mapped as part of EXSTDTC) As stated above, as long as the CDASH field name is contained within the system variable name, the ecrf page/item would be considered CDASH conformant BCreating Fields That Do Not Exist in CDASH The CDASH team recognizes that adding new collection variables is often constrained by business rules and systems. The naming conventions and other variable creation recommendations in CDASH are designed to aid implementers and facilitate mapping to submission datasets. See Appendix B for more detailed implementation information and examples. Prior to adding any new variables to current domain models, review the CDASH model as well as this. When adding variables not already defined in a CDASH domain, they will fall under one of these categories: A variable that is used for data cleaning purposes only, and is not submitted in SDTM (e.g., were any concomitant medications taken?). A variable with a response that can be mapped directly into SDTM with no change from how it was collected (e.g., Adverse Event reported term). A variable that will eventually be mapped into SDTM, but is collected in such a way that it requires some sort of change from the way it was collected (e.g., collected dates and times that are reported in ISO 8601 format). In general, when an implementer is creating new data collection fields and the corresponding database variables, the process should follow, within the boundaries of your data management system, the general guidelines that are used for CDASH fields and variables. These guidelines are: For fields: CDASH_UG April 2010

20 With a direct mapping to an SDTM variable: If a value can be collected exactly as it will be reported in SDTM, the SDTM variable should be used in the operational database to streamline the mapping process. In other words, any collection variable whose meaning is the same as an SDTM variable should be a copy of the SDTM variable, and its label and meaning should not be modified for data collection. Implementers should follow CDISC variable fragment naming conventions. See SDTMIG V3.1.2 Appendices C1, C5, and D. Without a direct one-to-one mapping to SDTM: If a study requires a field that is not identical to an SDTM field, for example the data type in which it is collected is different from the SDTM data type, or the SDTM variable is derived from collected data, the operational database should use a different name from the SDTM variable into which it will be mapped. An example would be if a study collects Findings data in a denormalized format and then maps the data to the normalized SDTM format. Implementers should follow CDISC variable fragment naming conventions, and CDASH naming conventions where they exist (e.g., --DAT for dates, --TIM for times, --YN for prompts, etc). Use of Controlled Terminology for data collection: In general, if controlled terminology can be used for a data collection field, it should be used. The use of free text fields should be limited. If a CDISC Controlled Terminology list exists for the field, it should be used, or a subset of it should be used as appropriate for the study. ο Extensible Codelists may have sponsor/study specific terms added to them. Make sure a synonymous terms does not already exist in the code list ο Non-extensible code lists should be used as they are, or a subset of them should be used as appropriate for the study. See CDISC Controlled Terminology for information on requesting new terms for Codelists. ο If the study requires a different set of terms for any code list that exists in CDISC Controlled Terminology, ensure that the collected data can be mapped to the CDISC code list for submission. When creating new data collection fields, and to facilitate mapping of collected data into SDTM data sets Implementers should refer to the: List of reserved domain codes in the current SDTMIG and use those that are applicable for creating new variables. Variable naming fragments in the current SDTMIG and use those that are applicable for creating new variables BMapping from CDASH to SDTM Datasets The CDASH project identifies the basic data collection fields needed from a clinical, scientific, and regulatory perspective to enable more efficient data collection at the investigative sites. The SDTM and the SDTMIG provide a standard for the submission of data based on collected data. CDASH moves upstream in the data-flow and identifies a basic set of highly recommended and recommended/conditional data collection fields that are expected to be present on the majority of CRFs. When applicable the CDASH data collection fields can be mapped to the SDTM structure. When the data are identical between the two standards, the SDTMIG variable names are presented in the CDASH domain tables. In cases where the data are not identical, CDASH has suggested new variable names. As part of this mapping, SDTMIG variable names have been provided under the Additional Information for Sponsors column where applicable as an aid. CDASH_UG April 2010

21 SDTM and CDASH are clearly related. All SDTMIG Required variables have been discussed and included in the CDASH standard, determined to be derivable, or can be obtained from data sources other than the CRF. Therefore, there are instances where the variables do not exactly match due to their different purposes (i.e., data submission vs. data collection) BExamples of SDTM Variables Not Included in CDASH CDASH has attempted to approach data collection with efficiency and consistency, and has always kept the SDTM mapping as an ultimate goal. Therefore, when an SDTM variable is Required or Expected, CDASH has addressed this either by directly collecting the variable, or providing implementation guidance on how to obtain that variable from derivations of collected data, or mappings from the operational databases BExamples of CDASH Fields Not Included in SDTM The CDASH recommendation also includes some data collection fields that are not included in the SDTMIG (e.g., Were there any adverse events? or Were any concomitant medications taken? ). These collection fields are intended to assist in the cleaning of data and in confirming that no data are missing. To facilitate the use of these types of fields, suggested variable names are provided (e.g., AEYN, CMYN, CMONGO) in the Variable Name column and are shaded to denote that they are CDASH-suggested data collection variable names and not SDTMIG variable names BMapping collected dates and times to SDTM CDASH recommends the unambiguous format DD-MMM-YYYY where DD is the day as a 2-digit numeric value, MMM is the month as a 3- character letter abbreviation in the local language, and YYYY is the year as a 4-digit numeric value. Any date can be composed of one or more of the elements of year, month, day and time. These components can be stored in a single variable or as a separate variable for each of the components. BRTHDAT is used in the example below. CDASH_UG April 2010

22 The SDTMIG template uses ISO 8601 for calendar dates and times of day, which are expressed as follows: YYYY-MM-DDThh:mm:ss where: [YYYY] = four-digit year [MM] = two-digit representation of the month (01-12, 01=January, etc.) [DD] = two-digit day of the month (01 through 31) [T] = (time designator) indicates time information follows [hh] = two digits of hour (00 through 23) (am/pm is NOT allowed) [mm] = two digits of minute (00 through 59) [ss] = two digits of second (00 through 59) Other characters defined for use within the ISO 8601 standard are: [-] (hyphen): to separate the time Elements "year" from "month" and "month" from "day" and to represent missing date components. [:] (colon): to separate the time Elements "hour" from "minute" and "minute" from "second" CDASH_UG April 2010

23 The concept of representing date/time precision is handled through use of the ISO 8601 standard. According to ISO 8601, precision (also referred to by ISO 8601 as "completeness" or "representations with reduced accuracy") can be inferred from the presence or absence of components in the date and/or time values. Missing components are represented by right truncation or a hyphen (for intermediate components that are missing). If the date and time values are completely missing the SDTM date field should be null. Every component except year is represented as two digits. Years are represented as four digits; for all other components, one-digit numbers are always padded with a leading zero. (Source: SDTMIG V.3.1.2, section ) The table below provides examples of ISO 8601 representation complete date and truncated date/time values using ISO 8601 "appropriate right truncations" of incomplete date/time representations. Note that if no time component is represented, the [T] time designator (in addition to the missing time) must be omitted in ISO 8601 representation. Date and Time as Originally Recorded (CDASH format) Precision ISO 8601 Date/Time (SDTM format) 15 Dec :14 Complete date and time unknown seconds T13:14 15 Dec 2003 Complete date unknown time Dec 2003 Unknown day unknown time Unknown month, day and time 2003 In any process where a date is being captured in an electronic system, the entry field should be displayed to the user in a format that is consistent with the CDASH standard. As long as the displayed field is CDASH conformant, the date(/time) may be stored immediately in the data capture system and/or underlying database in the corresponding SDTMIG variable using the ISO 8601 format, and this will not violate CDASH conformance. CDASH_UG April 2010

24 BRELREC-Creating Relationships between Collected Case Report Form Data Data collected on Case Report Forms can have traceable relationships that can be represented in SDTM. In some companies, it can be common practice to collect Adverse Events (AE), and document if those AEs had a Concomitant Medication (CM) as an action taken. Similarly, Conmed CRFs can solicit if the reason the subject took the medication was due to an AE. If these relationships are documented on the CRF as questions and the AE and CM relationship collected, RELREC can be populated in SDTM. In order to be able to establish RELREC, the relationship MUST be collected on the CRF. There are many ways to establish a RELREC, the most common being between 2 records in separate datasets (or domains) such as AE and CM, LB and AE, and AE and DS. For the purpose of this section, the relationship between AE and CM, and AE and DS records will be described.. The Related Records (RELREC) special-purpose dataset is used to describe relationships between records for a subject (as described in this section), and relationships between datasets. In both cases, relationships represented in RELREC are collected relationships, either by explicit references or check boxes on the CRF, or by design of the CRF.A relationship is defined by adding a record to RELREC for each record to be related and by assigning a unique character identifier value for the relationship. Each record in the RELREC special-purpose dataset contains keys that identify a record (or group of records) and the relationship identifier, which is stored in the RELID variable. The value of RELID is chosen by the sponsor, but must be identical for all related records within USUBJID. It is recommended that the sponsor use a standard system or naming convention for RELID (e.g., all letters, all numbers, capitalized). Records expressing a relationship are specified using the key variables STUDYID, RDOMAIN (the two-letter domain code of the record in the relationship), and USUBJID, along with IDVAR and IDVARVAL. Single records can be related by using a unique-record-identifier variable such as --SEQ in IDVAR. Note: The variables RELID, RDOMAIN, IDVAR, and IDVARVAL are derived variables in SDTM and are not collected on the CRF. CDASH_UG April 2010

25 In Example 1 below, subject 001 had an Adverse Event (AESEQ=3) of Hypercholesterolemia on the 17-Sep It was categorized as ongoing, with a mild severity and an action taken of Other Medication. The Other medication which was given for the AE is Mevacor, shown in the CM file with a CMSEQ of 6. Similarly, in the CM file a conmed of Mevacor (CMSEQ=6) was taken on 14-Oct The dose was 40 mg once a day, and it was recorded to have been taken for AESEQ 3. This recorded information is sufficient enough to produce a RELREC, shown in the last table. The RELREC is related by AESEQ and CMSEQ. IN SDTM, RELREC relationships are at the record level within datasets; however the relationship needs to be created at the variable level within CDASH. CMSEQ STUDYID USUBJID CMTRT CMINDC CMDOSE CMDOSU 6 ABC-123 ABC Mevacor CMDOS FRQ CMSTDAT CMPRIO R CMENDAT CMONGO CMAENO Hypercholerst erolemia 40 mg QD 14-Oct-07 Y Y 3 AESEQ STUDYID USUBJID AETERM AESTDAT AEENDAT AEONGO AESEV AESER AEREL AEACN AEACNOTH AEOUT AEDIS 3 ABC-123 ABC Hypercholesterolemia 17-Sep-07 Y MILD N N NONE OTHER MEDICATION NOT RECOVERED NOT RESOLVED N Row STUDYID RDOMAIN USUBJID IDVAR IDVARVAL RELTYPE RELID 1 ABC-123 AE ABC AESEQ ABC-123 CM ABC CMSEQ 6 1 CDASH_UG April 2010

26 In Example 2 below, subject 001 was involved in a cholesterol lowering trial. An Adverse Event (AESEQ=3) of Hypercholesterolemia was recorded on 17- Sep It was categorized as ongoing, with a severity of severe and an action taken of Other Medication. AEDIS Did the adverse event cause the subject to be discontinued from the study? has been checked Yes The subject also discontinued the study on 30-Sep-2007 because of Hypercholesterolemia, as Lack of Efficacy. The AEDIS variable creates the relationship between the AE form and the End of Study form This recorded information is sufficient enough to produce a RELREC, shown in the table below. The RELREC is related by AESEQ and DSSEQ. IN SDTM, RELREC relationships are at the record level within datasets; however the relationship needs to be created at the variable level within CDASH. AESEQ STUDYID USUBJID AETERM AESTDAT AEENDAT AEONGO AESEV AESER AEREL AEACN AEACNOTH AEOUT AEDIS 3 ABC-123 ABC Hypercholesterolemia 17-Sep-07 Y SEVERE N N DRUG WITHDRAWN OTHER MEDICATION NOT RECOVERED NOT RESOLVED Y DSSEQ STUDYID USUBJID DSCAT DSTERM DSDECOD DSSTDAT 1 ABC-123 ABC DISPOSITION EVENT HYPERCHOLESTEROLEMIA LACK OF EFFICACY 30-SEP-2007 Row STUDYID RDOMAIN USUBJID IDVAR IDVARVAL RELTYPE RELID 1 ABC-123 AE ABC AESEQ ABC-123 DS ABC DSSEQ 1 1 CDASH_UG April 2010

27 2.5 14BGeneral Recommendations on Screen Failures Screen failure data are data collected for those who fail screening and who are not subsequently enrolled in the study. Section 10.1 of ICH E3 describes the reporting of subject disposition in the clinical study report. This section states that it may be relevant to provide the number of patients screened for inclusion and a breakdown of the reasons for excluding patients during screening, if this could help clarify the appropriate patient population for eventual drug use. Although screen failure data may not be relevant for all studies, CDISC recommends that screen failure data be proactively collected in all studies to avoid issues associated with retroactive collection of screen failure data, such as inaccuracies and workflow management. Proactive and timely collection of screen failure data may also be used to identify eligibility criteria that contribute to enrollment challenges. Using CDASH, the minimum data to be collected should include a subject identifier and reason for screen failure. The subject identifier is needed to avoid double counting subjects who repeat the screening procedure. The possible reasons for screen failure should optimally include refusal to participate and the individual ineligibility criteria. Typically, there is a reason on the End of Study form indicating Screen Failure. This information allows overall summarization of all subjects screened/enrolled and when captured, provides easy subject accountability for the Clinical Study Report. Other data may be considered for collection, such as date of informed consent, sex, race, date of birth or age, or other data to further describe the reason for ineligibility (e.g., the lab value that was out of range). The SDTM does not provide a separate domain specifically for screen failure data and does not require that the screen failure data be included in SDTM. Data for screen failure subjects, if submitted, should be included in the SDTM Demographics dataset, with ARMCD = SCRNFAIL" and ARM = Screen Failure. If Screen Failure is captured as a reason on the End of Study form, Sponsors should also include a record in the Disposition dataset indicating when the screen failure event occurred. Reference the SDTMIG V3.1.2 for further guidance on submitting Screen Failure data BOrder of Fields in Each Domain CDISC has ordered the fields in the CDASH domain tables using the order that was typically observed in the CRF samples that were reviewed. Although the layout of CRFs is out of scope for CDASH V1.0 and V1.1, as an aid to implementers, CDASH tables present the CRF fields in the order they would typically be found on a CRF. When deciding on the order of fields in a CRF, consider how the CRF is being used. When designing a CRF consider the following: Headings Place fields that are routinely collected on multiple forms at the top or beginning of the form. Providing the clinical site with a consistent order of these fields will result in more reliable data. For example, if the collection date and time are both collected, they should appear first and second respectively on each form where they are both collected. Clinical flow Fields should be placed on the form in the order that they are expected to be collected during the clinical assessment. It is acceptable to include fields from different domains on the same form. Some datasets have a more predictive clinical flow than others. For example if the clinician asks for a concomitant medication dose, they will most likely ask in this order: dose, unit, frequency and route. Another example would be CDASH_UG April 2010

28 if the clinician asks the subject for their adverse event relationship to a study treatment, this likely will be followed by asking the subject for their adverse event action taken regarding study treatment. Group related fields for a single clinical encounter together, although multiple clinical encounters (ex. visits or time points) may appear together on one form. For example, if heart rate and temperature are taken every hour for four hours on study day 1, the form can collect the data for Hour 1 (heart rate result and unit, temperature result and unit), followed by the data for hour 2, and followed by hour 3 and 4. In this scenario, there would be labels indicating each time point within the Day 1. Group related fields together. Test results and their associated units should always appear next to each other. For example, the results of the ECG test PR should be followed by units. Data that is dependent on other data should be placed in such as way that this dependence is obvious. For example, if there is a question where Other, specify is an option, the text box used to specify the other item should be placed immediately after the initial item, and should be indented to show it is a subpart of the original question. If the source data are collected on a separate source document and the data are transcribed to the CRF, the ideal CRF field order would follow the source data field order BNormalized vs. De-normalized Data Structures The CDASH Findings domain tables (i.e., DA, EG, IE, LB, SU, and VS) are presented in a structure that is similar to the SDTM submission model, which is to list the variable names and some examples of the tests in a normalized structure, even though many Data Management systems collect the data in a denormalized structure. Listed below are representations of data in their de-normalized and normalized structures. It is expected that implementers will need to modify to include protocol specific tests in a CRF presentation layout. Sponsors should use the CDASH recommendations to identify the types of data to collect while referring to the SDTM and CDISC Controlled Terminology for additional metadata, (e.g., labels, data type, controlled terminology, and so on). The format for data being exported from many DM systems is de-normalized. A de-normalized dataset is a dataset structured as a short and wide file. In this case (see ), the tests are all listed horizontally (de-normalized) across the page for each subject record. The file shows one record per subject visit, with all tests and results displayed horizontally across the page. This format is not optimal for data analysis and reporting as it is difficult to do accurate counts of data because all tests are on one line. Conversely, a normalized dataset is structured as long and narrow. The file shows one test per record or one test per row. In this case, (see ), the tests are all listed vertically (normalized) down the page for each test for each subject. The tests become standalone records as compared with a record per visit. This format is optimal for data mining as it allows a user to easily count tests and results. This format is also the format that was adopted by the CDISC SDS team. The CDASH Domain Teams have intentionally not reproduced other sections of the SDTM standard and implementers are asked to refer to the SDTM and SDTMIG on the CDISC website for additional information ( ). CDASH_UG April 2010

29 BLB Domain BDe-normalized Example LB Subject Initials Timepoint Draw_date Sodium Potassium Chloride Glucose Calcium Urea Nitrogen Creatinine Bilirubin AST ALT Protein Cholesterol Triglycerides Platelet Count 1 TP Screening 7-Aug TP Visit 1 14-Aug TP Visit 2 21-Aug CDASH_UG April 2010

30 BNormalized Example LB USUBJID LBSEQ LBTESTCD LBTEST LBCAT LBORRES LBORRESU LBORNRLO LBORNRHI LBSTRESC LBSTRESN LBSTRESU LBSTNRLO LBSTNRHI VISIT VISITNUM LBDTC ABC ALT ALANINE AMINOTRANSFERASE CHEMISTRY 18 U/L U/L 0 40 SCREENING ABC AST ASPARTATE AMINOTRANSFERASE CHEMISTRY 26 U/L U/L 3 44 SCREENING ABC BILI BILIRUBIN CHEMISTRY 7.1 µmol/l µmol/l 0 17 SCREENING ABC BUN BLOOD UREA NITROGEN CHEMISTRY 5.4 mmol/l mmol/l SCREENING ABC CA CALCIUM CHEMISTRY 2.48 mmol/l mmol/l SCREENING ABC CL CHLORIDE CHEMISTRY 98 mmol/l mmol/l SCREENING ABC CHOL CHOLESTEROL CHEMISTRY 6.36 mmol/l mmol/l SCREENING ABC CREAT CREATININE CHEMISTRY 72 µmol/l µmol/l SCREENING ABC GLUC GLUCOSE CHEMISTRY 4.8 mmol/l mmol/l SCREENING ABC PLAT PLATELET HEMATOLOGY ^9/L x10^9/l SCREENING ABC K POTASSIUM CHEMISTRY 4.8 mmol/l mmol/l SCREENING ABC PROT PROTEIN CHEMISTRY 80 g/l g/l SCREENING ABC SODIUM SODIUM CHEMISTRY 143 mmol/l mmol/l SCREENING ABC TRIG TRIGLYCERIDES CHEMISTRY 1.62 mmol/l mmol/l SCREENING ABC GLUC GLUCOSE CHEMISTRY 5.1 mmol/l mmol/l Visit CDASH_UG April 2010

31 BPros and Cons of Normalized vs. De-normalized LB Data Structures Dataset Data Structure Pros LB Normalized There is no additional mapping required for data analysis or submission. Example: LBTEST is already normalized to collect all verbatim test names performed by a clinical laboratory (e.g., Sodium, Potassium, and so on). LB Denormalized Variables are de-normalized and there is no need to populate the value-level metadata. Example: Variable Sodium represents the lab test name for Sodium. Cons The value-level metadata for LBTEST must be provided. The individual test names have to be collected on the CRFs and captured in the database, or derived in the dataset. Individual lab test names need to be merged and mapped to a single normalized variable (i.e., LBTEST) for data analysis/submission. Example: Individual lab test name of Sodium needs to be merged with other lab tests (e.g. Potassium, AST, etc) and mapped to a single variable LBTEST BVS Domain BDe-normalized Example VS CASE_ID VISITNUM SITEID SUBID VISDAT PAGE FORMNAME STUDYID PTINIT PULSE SYSBP DIABP TEMP RESP HEIGHT WEIGHT Mar-98 4 VITALS_1 ABC-124 TNK Apr-98 7 VITALS_2 ABC-124 TNK BNormalized Example VS Study Identifier (STUDYID) Domain Unique Subject Abbreviation Identifier (DOMAIN) (USUBJID) Vital Signs Sequence Test Short Vital Signs Test Name Number Name (VSTEST) (VSSEQ) (VSTESTCD) Result or Finding in Original Units (VSORRES) Original Units (VSORRESU) Character Result/Finding in Std Format (VSSTRESC) Numeric Result/Finding in Standard Units (VSSTRESN) Standard Baseline Flag Visit Name Units (VSBLFL) (VISIT) (VSSTRESU) Visit Number (VISITNUM) Date/Time of Measurements (VSDTC) Study Day of Vital Signs (VSDY) ABC-124 VS ABC DIABP DIASTOLIC BLOOD PRESSURE 85 mmhg mmhg - SCREENING ABC-124 VS ABC HEIGHT HEIGHT 63 in in - SCREENING ABC-124 VS ABC PULSE PULSE RATE 102 beats/min beats/min - SCREENING ABC-124 VS ABC RESP RESPIRATORY RATE 18 per min per min - SCREENING ABC-124 VS ABC SYSBP SYSTOLIC BLOOD PRESSURE 130 mmhg mmhg - SCREENING ABC-124 VS ABC TEMP TEMPERATURE 97.7 F F - SCREENING ABC-124 VS ABC WEIGHT WEIGHT lb lb - SCREENING CDASH_UG April 2010

32 Study Identifier (STUDYID) Domain Unique Subject Abbreviation Identifier (DOMAIN) (USUBJID) Vital Signs Sequence Test Short Vital Signs Test Name Number Name (VSTEST) (VSSEQ) (VSTESTCD) Result or Finding in Original Units (VSORRES) Original Units (VSORRESU) Character Result/Finding in Std Format (VSSTRESC) Numeric Result/Finding in Standard Units (VSSTRESN) Standard Baseline Flag Visit Name Units (VSBLFL) (VISIT) (VSSTRESU) Visit Number (VISITNUM) Date/Time of Measurements (VSDTC) Study Day of Vital Signs (VSDY) ABC-124 VS ABC DIABP DIASTOLIC BLOOD PRESSURE 76 mmhg mmhg - Visit ABC-124 VS ABC PULSE PULSE RATE 64 beats/min beats/min - Visit ABC-124 VS ABC RESP RESPIRATORY RATE 18 per min per min - Visit ABC-124 VS ABC SYSBP SYSTOLIC BLOOD PRESSURE 120 mmhg mmhg - Visit ABC-124 VS ABC TEMP TEMPERATURE 98.2 F F - Visit BPros and Cons of Normalized vs. De-normalized VS Data Structure Dataset Data Structure Pros VS Normalized There is no additional mapping required for data analysis/submission. Example: VSTESTCD is normalized to collect all short names for vital signs (e.g. DIABP, RESP, and so on). VS Denormalized Variables are de-normalized and there is no need to populate the value-level metadata. Example: Variable PULSE represents the vital sign name for Pulse rate. Cons The value-level metadata for VSTEST must be provided. The individual test short names have to be collected on the CRFs and captured in the database, or derived in the dataset. Individual variable s need to be merged and mapped to a single normalized variable for data analysis/submission. Example: Individual variable for PULSE needs to be merged with other vital sign names (e.g., TEMP, RESP, and so on) and mapped to a single variable VSTESTCD BQS Domain BDe-normalized Example QS SUBID VISDAT PAGE FORMNAME STUDYID PTINIT VMIMPROV M_IMPROV MINPROV NOCHNG 1 10-May-08 4 GLOBLCGI ABC-124 FMS Jun GLOBLCGI ABC-124 FMS Jul GLOBLCGI ABC-124 FMS Nov-08 4 GLOBLCGI ABC-124 LHH Dec GLOBLCGI ABC-124 LHH Jan GLOBLCGI ABC-124 LHH CDASH_UG April 2010

33 BNormalized Example QS Study Identifier (STUDYID) Domain Abbreviation (DOMAIN) Unique Subject Identifier (USUBJID) Sequence Number (QSSEQ) Question Short Name (QSTESTCD) Category of Question (QSCAT) Question Name (QSTEST) Finding in Original Units (QSORRES) Character Result/Finding in Std Format (QSSTRESC) Numeric Finding in Standard Units (QSSTRESN) Baseline Flag (QSBLFL) Visit Number (VISITNUM) Visit Name (VISIT) Planned Study Day of Visit (VISITDY) Date/Time of Finding (QSDTC) Study Day of Finding (QSDY) ABC-124 QS ABC CGIGLOBL Investigator Assessment Global Improvement No change Day ABC-124 QS ABC CGIGLOBL Investigator Assessment Global Improvement Much Improved WEEK ABC-124 QS ABC CGIGLOBL Investigator Assessment Global Improvement Very much improved WEEK ABC-124 QS ABC CGIGLOBL Investigator Assessment Global Improvement Minimally Improved Day ABC-124 QS ABC CGIGLOBL Investigator Assessment Global Improvement Much Improved WEEK ABC-124 QS ABC CGIGLOBL Investigator Assessment Global Improvement Very much improved WEEK BPros and Cons of Normalized vs. De-normalized QS Data Structures Dataset Data Structure Pros Cons QS Normalized There is no additional mapping required for data analysis/submission. Example: QSORRES is normalized to collect all findings as originally received or collected (e.g., No change, Very much improved, and so on). The value-level metadata for QSORRES must be provided. The terminology (discrete values) for the individual findings has to be captured in the database, or derived in the dataset. QS Denormalized Variables are de-normalized and there is no need to populate the value-level metadata. Individual variable s need to be merged and mapped to a single normalized variable for data analysis/submission. Example: Variable VMIMPROV represents the finding of Very much improved. Example: Individual variable for VMIMPROV needs to be merged with other findings (e.g., M_IMPROV, NOCHNG, and so on) and mapped to a single variable QSORRES. CDASH_UG April 2010

34 BNormalized Example DA Study Identifier (STUDYID) Domain Abbreviation (DOMAIN) Unique Subject Identifier (USUBJID) Sequence Number (DASEQ) Short Name of Accountability Assessment (DATESTCD) Name of Accountability Assessment (DATEST) Assessment Result in Original Units (DAORRES) Original Units (DAORRESU) Assessment Result in Std Format (DASTRESC) Numeric Result/Findin g in Standard Units (DASTRESN) Assessment Standard Units (DASTRESU) Visit Number (VISITNUM) Visit Name (VISIT) ABC-124 DA ABC DARETURN ABC-124 DA ABC DADISPEN ABC-124 DA ABC DADISPEN ABC-124 DA ABC DARETURN ABC-124 DA ABC DADISPEN ABC-124 DA ABC DADISPEN ABC-124 DA ABC DARETURN ABC-124 DA ABC DADISPEN ABC-124 DA ABC DARETURN ABC-124 DA ABC DADISPEN Return study medication Dispense study medication Dispense study medication Return study medication Dispense study medication Dispense study medication Return study medication Dispense study medication Return study medication Dispense study medication 2 TABLETS 2 2 TABLETS 3 WEEK 2 30 TABLETS TABLETS 3 WEEK 2 30 TABLETS TABLETS 2 BASELINE 0 TABLETS 0 0 TABLETS 3 WEEK 2 30 TABLETS TABLETS 3 WEEK 2 30 TABLETS TABLETS 2 BASELINE 5 TABLETS 5 5 TABLETS 3 WEEK 2 30 TABLETS TABLETS 3 WEEK 2 3 TABLETS 3 3 TABLETS 4 WEEK 3 30 TABLETS TABLETS 4 WEEK 3 CDASH_UG April 2010

35 BDe-normalized Example DA Study Identifier (STUDYID) Investigator Number (INVID) Subject Number (SUBID) Visit Number (VISITNUM) Visit Name (VISIT) Drug Dispensed Date (DISPDATE) Total Drug Dispensed (DISPAMT) Drug Units Dispensed (DISPAMTU) Drug Returned Date (RETURNDT) Total Drug Returned (RETAMT) Drug Units Returned (RETAMTU) ABC Week 2 31/Oct/ Tablets 31/Oct/ Tablets ABC Baseline 30/Sep/ Tablets Tablets ABC Week 2 14/Oct/ Tablets 14/Oct/ Tablets ABC Baseline 10/Oct/ Tablets Tablets ABC Week 2 24/Oct/ Tablets 24/Oct/ Tablets ABC Week 3 31/Oct/ Tablets 31/Oct/ Tablets BPros and Cons of Normalized vs. De-normalized DA Data Structures DA Normalized There is no additional mapping required for data analysis /submission. For example, a single variable DATEST is used to collect the accountability assessment (i.e.. DISPAMT and RETAMT ). The value-level metadata for DATEST must be provided. The individual subject characteristics have to be collected on the CRFs and captured in the database, or be derived in the dataset. DA Denormalized Variables are de-normalized and there is no need to populate the value-level metadata. For example, the variable DISPAMT represents the What is the amount dispensed? and RETAMT represents What is the amount returned? for the accountability assessment. Individual variables need to be merged and mapped to a single normalized variable for data analysis /submission. For example, individual variable RETAMT needs to be merged with other Name of Accountability Assessment (e.g. DISPAMT ) and mapped to a single variable DATEST BForm Level CRF Instructions BGeneral Design Considerations for Completion Instructions Whenever possible, details related to the completion of a single field should be placed with the field itself on the CRF. If this is not possible due to the medium and/or system being used to create the CRFs, then it is permissible to include the field level instructions at the top of the form in what is generally considered the form level instruction area. In some cases, such as when the form level instructions are very lengthy or include graphics or flowcharts, a separate CRF completion instruction guideline may be required. CDASH_UG April 2010

36 BGeneral Content Considerations for Completion Instructions When creating form level instructions for a CRF, the following points should be considered: The instructions should include clear references to the time period for which data are to be reported for the study, or to specific time windows that are allowed. The instructions should provide references to protocol sections for the specifics of and/or limitations on the data to be reported. The instructions should include any special instructions for additional reporting or actions required beyond what is collected on the CRF. The instructions should include considerations on how data collected on one CRF might have an impact on data that are reported on a different CRF. The instructions should refer to any special forms for reporting of protocol data of interest which is related to the CRF being completed but which might not be reported on that specific CRF BCDASH ODM BIntroduction The Operational Data Model (ODM) is a vendor neutral, platform independent format for interchange and archive of research data. The model includes the research data along with its associated metadata, administrative data, reference data and audit information. All of the information that needs to be shared among different software systems during the setup, operation, analysis, and submission or for long term retention is included in the model. ODM has been designed to be compliant with guidance and regulations published by the FDA for computer systems used in research trials. The ODM standard is intended to be both the formal specification and a user guide for transferring or archiving of research data. Please refer to the CDISC ODM standard located at for more information. CDASH-ODM metadata described here is an implementation of ODM that provides examples of basic case report form content. It may require modification to be applicable for a particular study or to be implementable in a particular database system. There are also other possible implementations that will conform to CDASH. For example, not all CDASH optional data fields are included in these examples. Also in some cases, such as Medical History, examples of how to collect data related to a specific condition (e.g. high blood pressure) or procedure (e.g. appendectomy) will be study specific. The primary purpose of these examples is to provide a starting point for creation of CDASH based CRFs. Some of the potential advantages of using CDASH-ODM are that it can be used in various systems to expedite the creation of CDASH conformant CRFs, it can create reusable mappings to SDTM, and it can be used as a foundation to create a metadata repository. CDASH and SDTM annotations are included in the Section 3 CRF examples as an aid to implementers. The intended purpose of the annotations is to relate or link the collection on the CRF to the CDASH and SDTM variables. The primary purpose of these examples is to provide a starting point for creation of CDASH based paper and EDC (Electronic Data Capture) CRFs using ODM. The EDC ODM examples are intentionally different in order to present as much variety as possible to assist the implementer. For example: 1) Character fields are defaulted at 999 characters with exceptions for those fields that would never need as many as 999 characters such as Coded fields like AEYN which uses the 1 character YN code list and the code list is not extensible CDASH_UG April 2010

37 Fields associated with units such as CMDOSEU Even though the SAS Transport Version 5 limit is 200 characters, SDTM submissions can accommodate text strings that exceed 200 characters by the use of Supplemental Qualifiers datasets. Please see the SDTMIG for further information regarding text strings greater than 200 characters. 2) Some forms, such as AE and CM, use items with ODM DataType date or partialdate, which only allows for a date component and not a time component. Other forms,such as DS, DV, EG and EX, use items with ODM DataType datetime or partialdatetime which include both date and time components. The date display used is DD-MMM-YYYY where MMM is the 3 character value for the month (e.g. MAR for MARCH) ODM prescribes the use of ISO8601 based date, time and datetime formats for electronic data transfer, irrespective of the manner in which these values are displayed. 3) Some items, such as SU Duration and EX Interruption Duration, use item with ODM DataType durationdatetime. These examples show a range of duration components (year, months, days, hours and minutes). It expected that a sponsor would restrict the available components as required. ODM prescribes the use of ISO8601 base duration formats for electronic data transfer, irrespective of the manner in which these values are displayed. 4) There are examples of both a pre-specified unit and a selection box to chose a unit. The EG form has Mean Ventricular Rate variable with a prespecified unit of BEATS/MIN ). The VS form for the Height variable has a selection box to chose the unit of cm or IN. 5) MH shows two pre-printed terms High Blood Pressure and Appendectomy, each using a different subset of items from the MH Domain. The last ItemGroup of the form shows the entry of a verbatim MH term using a different selection of items. 6) SC shows the entry of a variety of results through the repeated use of the SCORRES CDASH variable, including: a) decimal value for Gestational Age at Birth b) free text result for Education Level and c) coded result for Skin Type and Marital Status. 7) Two Vital signs forms are included. The first form is an example of singular collection for all of the tests. The second form divides the tests into groups, with each test/group also containing an item for Not Done and an item for Clinically Significant for that test. Additionally, in the second form the Blood Pressure test ItemGroup is repeating and contains an additional Time of measurement Item. This allows for multiple Blood pressure recordings at different times to be entered into the form BDescription The CDASH-ODM project was started in 2008 with the goal of developing the machine-readable metadata to accompany the 18 domains addressed in the CDASH standard. Common Identification Variables Common Timing Variables Adverse Events (AE) Comments (CO) Prior and Concomitant Medications (CM) Demographics (DM) Exposure (EX) Inclusion and Exclusion Criteria (IE) Laboratory Test Results (LB) Medical History (MH) Physical Examination (PE) Protocol Deviations (DV) CDASH_UG April 2010

38 Disposition (DS) Drug Accountability (DA) ECG Test Results (EG) Subject Characteristics (SC) Substance Use (SU) Vital Signs (VS) CDASH-ODM comprises elements from the SDTM, CDISC Controlled Terminology, CDASH data collection fields, extended ODM, operational ODM and best practice modelling structures. The ODM XML and an HTML representation of it, and implementation notes will be available to CDISC members at Annotated CRFs (paper renditions) and EDC forms are included in this for each domain. While CDASH-ODM does provide the common fields needed to create a basic CRF, implementers will need to augment them with therapeutic area specific data collection fields and other fields as needed due to any specific regulatory or local requirements. CDASH_UG April 2010

39 When creating the CDASH-ODM, it was quickly recognized that, particularly for findings domains such as Vital Signs, Labs, ECGs, etc., the CDASH standard does not identify individual tests that are conducted. The CDASH-ODM team provided some representative examples of tests, using tests and test codes from the CDISC Controlled Terminology code lists BUse of OIDs in CDASH file OIDs are employed in the CDASH ODM file in accordance with the CDISC ODM specification in order to reference definition elements, such as Forms, ItemGroups, Items and so on. Each definition element is given an OID, which represents a unique name for that element. When a reference must be made to an element, the reference is made using the element's OID. An OID does not provide any meaning beyond a "unique identifier" (in Database parlance, it is comparable to a primary key). More specifically, the CDISC ODM does not define OIDs as having any business meaning - i.e. the OID alone does not provide any means of determining the purpose of an element, or it's source such as any given section of the CDASH specification. In accordance with this usage, and in order to help avoid misinterpretation of the CDASH ODM, all OIDs are generated using a date pattern, which changes each time the CDASH team creates a new version of the CDASH ODM file. References from the CDASH ODM file to the appropriate section of the CDASH Specification or SDTM are provided by the ODM Alias mechanism alone. More information can be found in the CDISC ODM Specification version 1.3.0: OIDs - Section 2.11 "Element Identifiers and References" Alias - Section "Alias" CDASH_UG April 2010

40 Considerations for Implementation: 1) Set of values for datetime variables is truncated to 3 values. These fields would need to be modified to add complete lists to facilitate entry. 2) Several results fields in Findings are an ODM data type of float. All SDTM Findings results variable (--ORRES) are character, irrespective of the test. The ODM Findings results fields that are defined as float are: DA (Drug Accountability) Amount Returned, Amount Dispensed EG (Electrocardiogram): Summary (Mean) Ventricular Rate, PR, QRS, QT, QTc - Bazett s EX (Exposure): Total Volume, Infusion Rate, and Planned Dose are not SDTM variables. The values will be in SUPPEX with a character data type. SU (Substance Use): Gestational Age at Birth VS (Vital Signs): Height, Weight, Diastolic, Systolic, Pulse, Temperature 3) Most variables used a subset of the controlled terminology except AESEV (Adverse Event Severity), which uses the entire list and is not extensible. Some examples extend Terminology code lists with new values, such as Race OTHER and Blood Pressure Location ANKLE. Yet other items use code lists which do not exist in SDTM Terminology at all (e.g. Substance Use NEVER, CURRENT, FORMER, or Frame size CDASH_UG April 2010

41 3.0 2BDomain Implementation Reference BCommon Identifier Variables The table below compares common variables that are used in CDASH and SDTM. Some common variables such as DOMAIN are derived (not collected) and only used in SDTM. An explanation as to why some variables are not used in CDASH has also been provided. Question Text CDASH Field CDASH Core SDTM Variable Name SDTM Variable Label SDTM Core SDTM Type CDASH Explanation SDTM Description What is the Sponsor identifier? What is the study identifier? SPONSOR O NA NA NA NA An identifier for the entity with the overall regulatory responsibility for the Protocol. Since Study IDs and subsequent identifiers within the study (e.g., SITEID) are unique to a Sponsor, the Sponsor ID may be needed to uniquely identify records to external partners and regulatory agencies. STUDYID HR STUDYID Study Identifier Req Char Unique Identifier for a study that is assigned by the clinical researcher or research-sponsoring organization and is unique for the researcher or research-sponsoring organization. While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be derived into the database or created and populated during SDTM dataset creation before submission. NA NA NA DOMAIN Domain Abbreviation Req Char Two-character abbreviation for the domain. This field is typically not captured on a CRF as it is not meaningful to personnel at the investigative sites. This field can be derived into the database or created and populated during SDTM dataset creation before submission. Unique identifier for a study. Two-character abbreviation for the domain most relevant to the observation. The Domain abbreviation is also used as a prefix for variables to ensure uniqueness when datasets are merged. CDASH_UG April 2010

42 Question Text CDASH Field CDASH Core SDTM Variable Name SDTM Variable Label SDTM Core SDTM Type CDASH Explanation SDTM Description What is the investigator identifier? INVID O INVID Investigator Identifier Permissible Char Unique Investigator Identifier (alias) code for a researcher at a study site who oversees all aspects of the study at a site, including protocol submission for IRB approval, participant recruitment, informed consent, data collection, and analysis. An identifier to describe the Investigator for the study. May be used in addition to the SITEID. Not needed if SITEID is equivalent to INVID. ONLY in DM Dataset. Site Identifier SITEID HR SITEID Study Site Identifier Req Char Study site identifier (alias) that is assigned by the clinical researcher or research sponsoring organization and is unique within the study. (Might not be unique across studies.) Unique identifier for a study site within a submission. ONLY in DM Dataset. What is the subject identifier SUBJID HR SUBJID Subject Identifier for the Study Req Char Unique subject identifier within a site and a study. Subject identifier used within the study. Often the ID of the subject as recorded on a CRF- ONLY in DM Dataset. NA NA NA USUBJID Unique Subject Identifier NA NA NA --SEQ Sequence Number Req Char Identifier used to uniquely identify a subject across all studies for all applications or submissions involving the product. This is a useful identifier for combining research results data for a study subject when the subject is known to have participated in more than one trial for a given treatment (e.g. for analyses such as "overall exposure to study drug"). Generally, this identifier is assigned retrospectively, but might be assigned during the second trial when the subjects are known to have been in an earlier trial (e.g. follow-on trials). Req Num Sequence Number given to ensure uniqueness of subject records within a domain. This field is not required on the CRFs Identifier used to uniquely identify a subject across all studies for all applications or submissions involving the product. Sequence number to ensure uniqueness of records within a dataset for a subject (or within a parameter, in the case of the CDASH_UG April 2010

43 Question Text CDASH Field CDASH Core SDTM Variable Name SDTM Variable Label SDTM Core SDTM Type CDASH Explanation SDTM Description but may be used to ensure proper entry of some types of data. Sponsors will need to impute an appropriate sequence number during SDTM dataset creation before submission. Trial Summary domain). May be any valid number (including decimals) and does not have to start at 1. Should be assigned to be in a consistent chronological order. NA NA NA --GRPID Group ID Perm Char Used to tie together a block of related records in a single domain for a subject. NA NA NA --REFID Reference ID Perm Char Internal or external identifier such as a serial number on an SAE reporting form. NA NA NA --SPID Sponsor ID Perm Char Sponsor-defined reference number. Perhaps pre-printed on the CRF as an explicit line identifier or defined in the sponsor s operational database (derived) (e.g., line number on an Adverse Event page). For paper AE CRFs, it can be beneficial to use a sequence number in a data query to clearly communicate to the site the specific record in question. NA VISITNUM NA VISITNUM Visit Number Exp Num Numerical representation of the visit. Identifier (alias) for a clinical study encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject. NA VISIT HR VISIT Visit Name Perm Char Textual representation of the visit number. Identifier (alias) for a clinical study encounter that encompasses planned and Optional group identifier, used to link together a block of related records within a subject in a domain. Also used to link together a block of related records in the Trial Summary dataset (Section 3.4). Optional internal or external identifier such as lab specimen ID, or UUID for an ECG waveform or a medical image. Sponsor-defined identifier. Example: pre-printed line identifier on a Concomitant Medications page. Clinical encounter number. Numeric version of VISIT, used for sorting. Protocol-defined description of a clinical encounter. CDASH_UG April 2010

44 Question Text CDASH Field CDASH Core SDTM Variable Name (Date of collection) (Time of Collection) --DAT --TIM HR R/C --DTC SDTM Variable Label Date/Time of Collection NA NA NA --STRTPT Start Relative to Reference Time Point NA NA NA --STTPT Start Reference Time Point SDTM Core SDTM Type Exp Char Test Date CDASH Explanation unplanned trial interventions, procedures, and assessments that may be performed on a subject. A visit has a start and an end, each described with a rule. Time test was performed (if applicable) Permissible Char Derived Variable should not be populated in CDMS. This variable can be added into data after capture. It is derived by comparing the answer to the question against the STTPT date. For controlled terminology, refer to SDTMIG Permissible Char Sponsor defined variable. Not recommended to include in CDMS. SDTM Description Collection date and time of an observation represented in IS character format. Identifies the start of the observation as being before or after the sponsor-defined reference time point defined by variable --STTPT. Description or date/time in ISO 8601 character format of the sponsor-defined reference point referred to by --STRTPT. Examples: " " or "VISIT 1". NA NA NA --ENRTPT End Relative to Reference Time Point NA NA NA --ENTPT End Reference Time Point Permissible Char Derived Variable should not be populated in CDMS. This variable can be added into data after capture. It is derived by comparing the answer to the question against the ENTPT date. For controlled terminology, refer to SDTMIG Permissible Char Sponsor defined variable. Not recommended to include in CDMS. Identifies the end of the observation as being before or after the sponsor-defined reference time point defined by variable ENTPT. Description or date/time in ISO 8601 character format of the sponsor-defined reference point referred to by --ENRTPT. Examples: " " or "VISIT 2". CDASH_UG April 2010

45 Question Text CDASH Field CDASH Core SDTM Variable Name SDTM Variable Label SDTM Core SDTM Type CDASH Explanation SDTM Description CDASH_UG April 2010

46 3.2 20BAdverse Events (AE) These recommendations are for non-solicited or pre-specified adverse events. As with all the data collection variables recommended in CDASH Standard Version 1.0, it is assumed that sponsors will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., TAspecific data elements and others as required per protocol, business practice and operating procedures). Sponsors should define the appropriate collection period for adverse events. All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables BCDASH to SDTM Mapping AE Question Text CDASH Field CDASH Core SDTM Variable Name SDTM Core Implementation Notes Were any adverse events experienced? AEYN O NS NS Can be represented as a question with possible responses of Y or N. The purpose for collection of this field is purely administrative in nature. Thus, it is recommended that the information not be submitted as part of a SDTM submission. Only AEs that have actually occurred appear in the AE SDTM domain. AE Number AESPID O AESPID Perm Can be represented as open entry field designed to capture either numeric or alphanumeric responses based on sponsor convention. The purpose of this field is administrative in nature and can be used to link intervention related records to a specific event across domains (e.g., link AE domain records to CM domain records). In these cases, a RELREC record using AESPID may be created to communicate this relationship to a review agency. CDASH_UG April 2010

47 Question Text CDASH Field CDASH Core SDTM Variable Name SDTM Core Implementation Notes What is the adverse event term? AETERM HR AETERM Req Can be represented either as an open entry field to capture verbatim terms reported by subjects or could be pre-printed in the situation where solicited AEs of interest are captured. If a study collects both pre-specified adverse events as well as free-text events, the value of AEPRESP should be Y for all pre-specified events and null for events reported as free-text. AEPRESP is a permissible field and may be omitted from the dataset if all adverse events were collected as free text. The SDTMIG V3.1.2 (p. 98) says this about pre-specified Adverse Event: If it is important to know which adverse events from a pre-specified list were not reported as well as those that did occur, these data should be submitted in a Findings class dataset such as Findings About Events and Interventions (FA, 598HSection 6.4). A record should be included in that Findings dataset for each pre-specified adverse-event term. Records for adverse events that actually occurred should also exist in the AE dataset with AEPRESP set to Y. When adverse events are collected with the recording of free text, a record may be entered into the sponsor s data management system to indicate no adverse events for a specific subject. For these subjects, do not include a record in the AE submission dataset to indicate that there were no events. Records should be included in the submission AE dataset only for adverse events that have actually occurred. In most cases, the verbatim term (i.e. investigator-reported term) will be classified based on a standard medical dictionary such as MedDRA, after the data have been collected on the CRF. The dictionary-related data will be stored in fields not defined by CDASH. NA NA NA AEDECOD Req This REQUIRED field in SDTM is not accounted for in the CDASH standard since it is defined as a derived variable and not a data collection field that would appear on the CRF itself.. Sponsors will populate this through classification routines in preparation for creating and submitting SDTM datasets and/or sponsors will include a comment in the define data definition document to state that the data was not collected. NA NA NA AEBODSYS Exp This EXPECTED field in SDTM is not accounted for in the CDASHG standard since it is defined as a derived variable and not a data collection field that would appear on the CRF itself.. Sponsors will populate this through classification routines in preparation for creating and submitting SDTM datasets and/or sponsors will include a comment in the define data definition document to state that the data was not collected. Does the subject have <specific adverse evetn>? What is the date the adverse event AEOCCUR O N/A N/A This field is used to capture the occurrence of a pre-specified AE and should not be used for spontaneously reported events. There is no AEOCCUR variable in the SDTMIG since the AE domain in SDTMIG is only used to submit events that actually occurred. The values collected using AEOCCUR in the case report form may be submitted in the Findings About (FA) domain in an SDTM submissions. AESTDAT HR AESTDTC Exp Within most data collection environments, the date and time will be captured as distinct fields. Whether collected separately or together, the data will need to be transformed and/or reported in CDASH_UG April 2010

48 Question Text CDASH Field CDASH Core SDTM Variable Name started? SDTM Core Implementation Notes ISO8601 format for SDTM submission. At what time did the adverse event start? AESTTIM R/C What date did the adverse event end? AEENDAT HR AEENDTC Exp Within most data collection environments, the date and time will be captured as distinct fields. Whether collected separately or together, the data will need to be transformed and/or reported in ISO8601 format for SDTM submission. At what time did the adverse event end? AEENTIM R/C Is the adverse event ongoing? What was the severity of the adverse event? What is the toxicity grade of the adverse event? Is the adverse event serious? AEONGO O NS NS Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. The purpose for collection of this field is purely administrative in nature. Thus, it is recommended that the information not be submitted as part of a SDTM submission. AESEV HR AESEV Perm Field should be represented as either a list of values or checkbox indicating the severity according to CDISC-controlled terminology. In studies using a standard toxicity scale such as Common Terminology Criteria for Adverse Events v3.0 (CTCAE), published by the NCI (National Cancer Institute), AETOXGR should be used instead of AESEV. In most cases, either AESEV or AETOXGR is populated but not both. There may be cases when a sponsor may need to populate both variables. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the define.xml external code list attributes. AETOXGR HR AETOXGR Perm Field should be represented as either a list of values or checkbox indicating the toxicity according to the toxicity scale defined in the protocol. In studies using a standard toxicity scale such as Common Terminology Criteria for Adverse Events v3.0 (CTCAE), published by the NCI (National Cancer Institute), AETOXGR should be used instead of AESEV. In most cases, either AESEV or AETOXGR is populated but not both. There may be cases when a sponsor may need to populate both variables. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the define.xml external code list attributes. AESER HR AESER Exp This field can be collected: As the only serious AE indicator on a CRF Collected in addition to the SAE types or derived as a result of responses to the SAE types; if deriving, please refer to the SDTMIG for the full list of potential --AESxxxx categories that are permissible. If the details regarding a Serious AE need to be collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type below. CDASH_UG April 2010

49 Question Text CDASH Field CDASH Core SDTM Variable Name SDTM Core Implementation Notes Is the adverse event associated with a congenital anomaly or birth defect? Did the adverse event result in persistent or significant disability or incapacity? Did the adverse event result in death? Did the adverse event result in initial or prolonged hospitalization for the patient? Is the adverse event life threatening? Is the adverse event associated with other serious or AESCONG R/C AESCONG Perm Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. If categories of serious events are collected secondarily to a leading question, the values of the variables that capture reasons an event is considered serious (i.e., AESDISAB, AESCONG, etc.) may be null. For example, if Serious is answered No, the values for these variables may be null. However, if Serious is answered Yes, at least one of them will have a Y response. Others may be N or null, according to the sponsor s convention. AESDISAB R/C AESDISAB Perm Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. If categories of serious events are collected secondarily to a leading question, the values of the variables that capture reasons an event is considered serious (i.e., AESDISAB, AESCONG, etc.) may be null. For example, if Serious is answered No, the values for these variables may be null. However, if Serious is answered Yes, at least one of them will have a Y response. Others may be N or null, according to the sponsor s convention. AESDTH R/C AESDTH Perm Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. If categories of serious events are collected secondarily to a leading question, the values of the variables that capture reasons an event is considered serious (i.e., AESDISAB, AESCONG, etc.) may be null. For example, if Serious is answered No, the values for these variables may be null. However, if Serious is answered Yes, at least one of them will have a Y response. Others may be N or null, according to the sponsor s convention. AESHOSP R/C AESHOSP Perm Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. If categories of serious events are collected secondarily to a leading question, the values of the variables that capture reasons an event is considered serious (i.e., AESDISAB, AESCONG, etc.) may be null. For example, if Serious is answered No, the values for these variables may be null. However, if Serious is answered Yes, at least one of them will have a Y response. Others may be N or null, according to the sponsor s convention. AESLIFE R/C AESLIFE Perm Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. If categories of serious events are collected secondarily to a leading question, the values of the variables that capture reasons an event is considered serious (i.e., AESDISAB, AESCONG, etc.) may be null. For example, if Serious is answered No, the values for these variables may be null. However, if Serious is answered Yes, at least one of them will have a Y response. Others may be N or null, according to the sponsor s convention. AESMIE R/C AESMIE Perm Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. If categories of serious events are collected secondarily to a leading question, the values of the variables that capture reasons an event is considered serious (i.e., AESDISAB, AESCONG, etc.) CDASH_UG April 2010

50 Question Text CDASH Field CDASH Core SDTM Variable Name important medical events? SDTM Core Implementation Notes may be null. For example, if Serious is answered No, the values for these variables may be null. However, if Serious is answered Yes, at least one of them will have a Y response. Others may be N or null, according to the sponsor s convention. What was the relationship to study treatment? What action was taken with study treatment? What other action was taken in response to this adverse event? What was the outcome of this adverse event? Did the adverse event cause the subject to be discontinued from the study? AEREL HR AEREL Exp This should be created with a defined code list on the field. There is currently no recommendation or requirement in the CDISC Terminology for specific values. Two possible sets of responses are typically seen across the industry. One set involves the ICH E2A and E2B examples NOT RELATED, UNLIKELY RELATED, POSSIBLY RELATED, RELATED. The other possibility is the use of Y and N. Controlled Terminology may be defined in the future. It is recommended that you check with the appropriate regulatory authority for population of this variable so that it meets their expectations for your submission. AEACN HR AEACN Exp Field should be represented as either a list of values or checkbox indicating the type of action taken with study treatment using the CDISC-controlled terminology. AEACNOTH O AEACNOTH Perm There is no controlled terminology on this field and sponsors can choose to represent this on the CRF as a free text box or, if possible/desired, create sponsor-controlled terminology. AEOUT HR AEOUT Perm Field should be represented as either a list of values or checkbox indicating the outcome of the AE using the CDISC-controlled terminology. AEDIS O NS NS Can be represented as either a checkbox that would store a Y or NULL on the database or as a question with possible responses of Y or N. If collected, it is recommended that the relationship between the AE causing discontinuation and the discontinuation record itself be created in the RELREC special-purpose domain of the submission. Section 8.2 of the SDTM IG explains the process for creating a RELREC between the AE and DS domains. CDASH_UG April 2010

51 BImplementation Examples AE BExample 1 This is an example of an AE CRF that collects AEYN. This is a log style collection of AEs with pre-printed line numbers. In this example AESER is collected in addition to the seriousness criteria. Row 1 shows an example of a subject that does not have any AEs to report. There will be no records for the subject in the AE SDTM submission dataset. Rows 2 and 3 show examples of a subject that has AEs to report. Row AEYN AESPID AETERM AESTDAT AESTTIM AEENDAT AEENTIM AEONGO AESEV AETOXGR 1 N 2 Y 1 HEADACHE 02-JAN :12 02-JAN :34 MODERATE 3 Y 2 DIZZINESS 04-FEB-2004 Y SEVERE Row AESER AESCONG AESDISAB AESDTH AESHOSP AESLIFE AESMIE AEREL AEACN 1 (cont) 2 (cont) N Y DOSE NOT CHANGED 3 (cont) Y N Y N Y N N Y DOSE REDUCED Row AEACNOTH AEOUT AEDIS 1 (cont) 2 (cont) RECOVERED/RESOLVED N 3 (cont) Y NOT RECOVERED/NOT RESOLVED N CDASH_UG April 2010

52 BExample 2 This is an example of an AE CRF that collects AEYN. This is a visit-based collection of AEs with line numbers. In this example, AESER is not collected; only the serious criteria responses are collected. Row 1 shows an example of a subject that does not have any AEs to report. Rows 2, 3, and 4 show examples of a subject that has AEs to report. Row AEYN AESPID AETERM AESTDAT AESTTIM AEENDAT AEENTIM AEONGO AESEV AETOXGR 1 N 2 Y 1 HEADACHE 02-JAN :12 02-JAN :34 MODERATE 3 Y 2 DIZZINESS 04-FEB-2004 Y SEVERE 4 Y 3 DIZZINESS 04-FEB-2004 Y SEVERE Row AESCONG AESDISAB AESDTH AESHOSP AESLIFE AESMIE AEREL AEACN AEACNOTH AEDIS 1 (cont) 2 (cont) N N N N N N Y 3 (cont) N Y N Y N N Y 4 (cont) N Y N Y N N Y DOSE NOT CHANGED DOSE NOT CHANGED DOSE REDUCED N Y Y N N N CDASH_UG April 2010

53 BExample 3 This is an example of an AE CRF that does not collect AEYN or line numbers. Collection is log style. In this example, only AESER is collected, Headache and Dizziness are solicited AEs Rows 1 and 2 show an example of solicited / pre-specified Adverse Events. Row 3 shows an example of a spontaneously reported Adverse Event. Row AEPRESP AETERM AESTDAT AESTTIM AEENDAT AEENTIM AEONGO AETOXGR 1 Y HEADACHE 02-JAN :12 02-JAN :34 GRADE 1 2 Y DIZZINESS 04-FEB-2004 Y GRADE 4 3 STIFF NECK 02-MAR :02 03-MAR :30 GRADE 4 Row AESER AEREL 1 (cont) N Y 2 (cont) Y Y 3 (cont) CDASH_UG April 2010

54 BCompletion Instructions Adverse Events (AE) All Serious Adverse Events (AEs), regardless of relationship to study drug, must be reported via telephone or fax within 24 hours of discovery Record the AEs and corresponding information on the AE Record CRF through the <protocol-specified period>. Record all AEs except <list of protocol-defined exceptions> on the AEs module after informed consent is obtained. Safety information (e.g., AE, SAE) identified for all subjects must be recorded on source documents from the time the ICF is signed. CDASH_UG April 2010

55 BODM CRF Examples AE BPaper CRF Example AE CDASH_UG April 2010

56 CDASH_UG April 2010

57 BEDC CRF Example AE CDASH_UG April 2010

58 3.3 21BComments (CO) With CDASH v1.0, CDISC decided there would be no mandatory data elements for inclusion in a separate Comments CRF. This decision was consistent with currently evolving common practices and the ICH Guidelines. This decision does not pertain to solicited free-text comment data collection fields that may appear within another established domain, and is not meant to discourage Investigators from providing unsolicited comments where they are appropriate. The CO Domain Team consensus and recommendation is that implementers avoid the creation of a separate General Comments CRF and provide free text fields that are associated with other data collection fields on existing CRFs when additional information related to those fields is needed. It is incumbent upon the study teams to design and utilize the data collection tools capable of capturing data that is useful for analysis purposes. Therefore, code lists should be developed for data collection fields as much as possible, and free text fields should be limited to those that are required for the study. Individual sponsor companies must determine their own path in collecting unsolicited comments on CRFs, and this should be done with input from the Review Division that will receive the submission BCDASH to SDTM Mapping CO Examples are only those present on other domains where comments are used. See the SDTMIG for instructions on mapping comments BImplementation Examples CO N/A BForm Level Completion Instructions CO CDASH does not recommend the use of a separate Comments CRF, so no form level instructions are provided for a Comments page. For comments related to a specific field on another CRF, provide instructions on what is expected for each comment field in that CRF s field-level completion instructions BODM CRF Examples CO No CRF is recommended for general comments, so no examples are provided BPaper CRF Example CO Not applicable BEDC CRF Example CO Not applicable CDASH_UG April 2010

59 3.4 2BConcomitant Medication (CM) BATC Classifications The Anatomical Therapeutic Chemical (ATC) is a classification system in which drugs are divided into different groups according to the organ or system on which they act, and their chemical, pharmacological and therapeutic properties. See for more information about ATC coding BCDASH to SDTM Mapping CM The core designations specified in the CDASH CM domain are representative of the fields required for general medication reporting and do not address the core designation requirements of specific CDASH implementations. In the case of medications of interest, the core designations for fields in the CM domain may vary for a specific implementation of the CDASH standard and/or data analysis requirements. All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Were any medications taken? What is the medication identifier? What was the term for the medication/ therapy taken? Did the subject take <specific CMYN O NS NS The purpose of this field is to help with data cleaning and monitoring. CMYN will not be included as part of the SDTMIG CM domain for a submission. CMSPID O CMSPID Perm Sponsor-defined reference number, perhaps pre-printed on the CRF as an explicit line identifier or defined in the sponsor s operational database (derived) (e.g., line number on a concomitant medication page). For paper Prior and Concomitant Medication CRFs, it can be beneficial to use a sequence number in a data query to clearly communicate to the site the specific record in question. If CMSPID contains line numbers, it can also be used to reflect a collected relationship in RELREC between a concomitant medication and an Adverse Event that uses AESPID for line numbers. CMTRT HR CMTRT Req In most cases, the verbatim drug name or therapy will be coded to a standard dictionary such as WHO DRUG after the data have been collected on the CRF. For the collection of a verbatim drug name or therapy, the recommendation is to ask the sites to provide the full trade or proprietary name since that is more exact than the generic name. The full trade name provides the base generic and the appropriate salt for a particular drug. For coding purposes it also helps with ATC selection. For example, the medication Tylenol with codeine # 1 will have a different ATC code than the medication Tylenol with codeine #3. CMOCCUR O CMOCCUR Perm CMOCCUR in CDASH maps directly to CMOCCUR in an SDTM submission. CDASH_UG April 2010

60 Question Text Variable Name CDASH Core SDTM Variable Name medication / treatment>? SDTM Core (v ) Implementation Notes What were the active ingredient(s)? For what indication was the medication/ therapy taken? What was the ID of the adverse event for which the medication was taken? What was the ID of the medical history condition for which the medication was taken? CMINGRD O NS NS This field may be collected in addition to CMTRT to provide more detailed information to assist in coding to a medical dictionary such as WHO DRUG Enhanced Format C, which now codes to the ingredient level for many trade named medications. For example, the active ingredients for the medication Dolman may be different depending on where it was manufactured. In Spain, Dolman contains acetylsalicylic acid, ascorbic acid, and codeine phosphate. In Italy and the Czech Republic, Dolman contains tenoxicam. In Estonia and Latvia, Dolman contains dexketoprofen trometamol. CMINDC R/C CMINDC Perm This additional information is collected on the CRF when the sponsor wants to capture the reason(s) why the subject took a particular medication. This information can then be used, as appropriate, for: Coding to a medical dictionary Analysis, i.e., in the classification of medications Reconciliation of medications taken by a subject with their provided medical history and AEs or SAEs as part of the data cleaning and monitoring process. CMAENO O NS NS Intent is to establish a link between the adverse event and the medication taken for the adverse event, but there may be other ways to collect this type of information. Utilizing this variable to maintain a link to a sequence number associated with an AE may result in unnecessary data cleaning work. Potential reconciliation issues occur for example, if the AE line number is deleted or a new AE is added due to a query response or a correction by the clinical site or an AE verbatim is split for coding. CMAENO will not be included in the SDTM CM domain in submissions. CMMHNO O NS NS Intent is to establish a link between the medical history condition and the medication taken for the medical history condition, but there may be other ways to collect this type of information. Utilizing this variable to maintain a link to a sequence number associated with an MH condition may result in unnecessary data cleaning work. Potential reconciliation issues occur for example, if the MH line number is deleted or a new MH is added due to a query response or a correction by the clinical site or an MH verbatim is split for coding. CMMHNO will not be included in the SDTM CM domain in submissions. What was the individual dose of the medication/ therapy? CMDSTXT O CMDOSTXT (Character) CMDOSE (Numeric) Perm Perm Where this level of dosing information is required by a sponsor, this field may be included. Defining this data collection field as a dose text field allows for flexibility in capturing text dose entries. CMDSTXT may be used to collect dosing in any format. If it is a non-numeric value it will map to CMDOSTXT in SDTM data. If it is a numeric value it will map to CMDOSE in SDTM data. CDASH_UG April 2010

61 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What was the total daily dose of the medication/ therapy? What was the unit of the medication/thera py? CMDOSTOT O CMDOSTOT Perm In some clinical trials, individual doses are more likely to be collected. In clinical trials when dosing data do not need to be that precise, e.g., in later phase trials, the total daily dose may be all that is collected. For general medication, it is not recommended to use Total Daily Dose. Instead, if needed for analysis, this can be calculated or derived from other fields such as Units, Dose, and Frequency to avoid confusion and calculation by the clinical site. Implementers should not include a derived Total Daily Dose in the SDTM CM domain. CMDOSU O CMDOSTOT Perm When sponsors collect data for amount of dose taken (i.e., Dose, Total Daily Dose, Unit ) must be collected as well. CMDOSU: The UNIT code list that is associated with this field contains some values that may also be considered formulations (e.g., capsule, tablet, puff). There may be some cases in which the use of these values is appropriate for CMDOSU, such as when this is the only information that can be obtained from the subject. What was the dose form of the medication/thera py? What was the frequency of the medication/thera py? What was the route of administration of the medication/thera py? What was the start date of the medication/thera py? CMDOSFRM O CMDOSFRM Perm CDASH recognizes that some drugs have multiple forms and this field may be needed to code the drug to an ATC level. However, in general, this level of detail should not be necessary except for medications of interest. CMDOSFRQ O CMDOSFRQ Perm When collected, the recommendation is to collect dosing information in separate fields for specific and consistent data collection and to enable programmatically utilizing these data for analysis. See below for the rest of the dosing information components (Dose per Administration, and Unit.) CMROUTE R/C CMROUTE Perm This additional information may be important to collect on the CRF when the sponsor would want to capture a medication s route of administration for purposes such as coding and the medication may have more than one route. Some companies may use route in coding medications to be able to choose a precise preferred name and ATC code. CMSTDAT HR CMSTDTC Perm The preferred method is to collect a complete Start Date. Partial dates (i.e., providing year only) for medications started a considerable amount of time before the start of study are acceptable. For the SDTM dataset, the SDTM variable CMSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into CMSTDTC using the ISO 8601 format. CDASH_UG April 2010

62 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Was the medication/thera py taken prior to the study? What was the start time of the medication/thera py? What was the end date of the medication/thera py? Is the medication / therapy still ongoing? What was the end time of the medication/thera py? CMPRIOR R/C CMSTRF Perm If instead of Start Date, information such as BEFORE or DURING or AFTER is collected, this information is derived in the CMSTRF variable. This variable is not a direct mapping to CMSTRF. CMSTRF is only populated if the start date (CMSTDAT) is not specified. If there is no start date (CMSTDAT), then the value of CMPRIOR is used to determine how CMSTRF is populated in the SDTM data set, following the rules described in the SDTM assumption. See section 3.1 for additional information about relative timing variables. CMSTTIM R/C CMSTDTC Perm Recommend collecting the time a medication was started when a protocol or data collection scenarios supports it. Typically, a start time is not collected unless the subject is under the direct care of the site at the time a medication is taken. For the SDTM-based dataset, the SDTM variable CMSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into CMSTDTC using the ISO 8601 format. CMENDAT HR CMENDTC Perm The assumption is that sponsors should either have a complete end date or will indicate that the medication or therapy was ongoing at the end of the study. For the SDTM-based dataset, the SDTM variable CMENDTC is derived by concatenating CDASH End Date and Time (if time is collected) into CMENDTC using the ISO 8601 format. CMONGO O CMENRF Perm This box should be checked to indicate that the medication or therapy has not stopped at the time of data collection. At study completion, it is expected that every reported medication or therapy should have either End Date or be checked as Ongoing, but not both. This variable is not a direct mapping to CMENRF. CMENRF is only populated if the end date (CMENDAT) is not specified. If there is no end date (CMENDAT), then the value of CMONGO is used to determine how CMENRF is populated in the SDTM data set, following the rules described in the SDTM assumption. CMENTIM R/C CMENDTC Perm Recommend collecting the time a medication was ended when a protocol or data collection scenario supports it. Typically, an end time is not collected unless the subject is under the direct care of the site at the time a medication is stopped and can be accurately reported. For the SDTM-based dataset, the SDTM variable CMENDTC is derived by concatenating CDASH End Date and Time (if time is collected) into CMENDTC using the ISO 8601 format BImplementation Examples CM BExample 1 Spontaneous concomitant medications with dosing information and ingredients to help in coding. CDASH_UG April 2010

63 Row 1 shows an example where the subject did not take any concomitant medications. There will be no record for the subject in the CM dataset. Rows 2 through 5 show an example of a subject that took several concomitant medications. Note that Row 2 contains only the response to the form-level question Did the subject take any medications? and Rows 3 through 5 contain the actual medications that were reported. Row 3 shows an example where the ingredients are listed to assist in coding the medication. The start and end dates are partial dates, and the medication is ongoing. One record for the subject will appear in the CM dataset, and the two ingredients listed in row 3 will appear as two records in the supplemental qualifiers domain for CM (SUPPCM). Rows 4 and 5 show examples of medications where ingredients are not listed, either because they were not available or because they were not considered necessary for coding purposes, but additional dosing information is available. Row USUBJID CMYN CMTRT CMINGRD CMINDC CMDSTXT CMDOSU CMDOSFRM CMDOSFRQ 1 XYZ-0001 N XYZ-0002 Y XYZ VIVELLE ETHINYLESTRADIOL, NORGESTIMATE ESTROGEN DEFICIENCY - - PATCH TW 4 XYZ COREG - HYPERTENSION mg TABLET QD 5 XYZ CAPOTEN - HYPERTENSION 25 mg TABLET BID Row CMSTDAT CMPRIOR CMENDAT CMONGO 1 (cont) (cont) (cont) JAN Y 4 (cont) - Y - Y 5 (cont) - Y 01-MAR CDASH_UG April 2010

64 BExample 2 Spontaneous concomitant medications with links to related records in the medical history. Row 2 shows an example where the subject s medication is linked to a Medical History record. The line number of the medication is stored in CMSPID, and the corresponding line number on the Medical History CRF is stored in CMMHNO. That relationship can be documented by creating a record in the RELREC dataset. Rows 3 and 4 show an example where the dose frequency for the medication was changed during the study treatment period. In Row 2, the medication was started prior to study treatment and ended during study treatment. In Row 3, the medication continued with a new dose frequency and was not ongoing when the study treatment period ended. Row 5 shows an example where the medication was started prior to study treatment but only the year was known. The medication is ongoing when the study treatment period ended, so there is no end date. Row USUBJID CMYN CMSPID CMTRT CMINDC CMMHNO CMDSTXT CMDOSU CMDOSFRM 1 XYZ-0011 Y XYZ MAXALT MIGRAINE 3 5 mg TABLET 3 XYZ ZYLOPRIM GOUT mg TABLET 4 XYZ ZYLOPRIM GOUT mg TABLET 5 XYZ AMBIEN CR INSOMNIA mg TABLET Row CMDOSFRQ CMSTDAT CMPRIOR CMENDAT CMONGO 1 (cont) (cont) ONCE - Y 10-APR (cont) BID MAR MAR (cont) TID - Y 01-JUN (cont) QD Y BExample 3 Pre-specified medications of interest. In this example, the sponsor only wants to know whether or not the subject takes any of the four pre-printed blood thinners during study treatment. For each subject, four rows contain the pre-specified medications of interest. The investigator checks YES only those medications that the subject has taken. Rows 1 through 4 show an example where the subject has taken each of the pre-specified medications and all additional information has been completed. The final submission dataset will contain four records for the subject. CDASH_UG April 2010

65 Rows 5 through 8 show an example where the subject has taken only one of the medications, and the investigator has completed the additional information for that medication. The final submission dataset will contain only one record for the subject. Row USUBJID CMOCCUR CMSPID CMTRT CMPRESP CMDSTXT CMDOSU CMDOSFRM 1 XYZ-0113 Y 1 PREDNISONE Y 5 mg TABLET 2 XYZ-0113 Y 2 NSAID Y 100 mg TABLET 3 XYZ-0113 Y 3 COUMADIN Y 5 mg TABLET 4 XYZ-0113 Y 4 PLAVIX Y 12.5 mg TABLET 5 XYZ-0012 N 1 PREDNISONE Y XYZ-0012 Y 2 NSAID Y 700 mg TABLET 7 XYZ-0012 N 3 COUMADIN Y XYZ-0012 N 4 PLAVIX Y Row CMDOSFRQ CMSTDAT CMPRIOR CMENDAT CMONGO 1 (cont) ONCE - Y 10-APR (cont) BID MAR MAR (cont) TID - Y 01-JUN (cont) QD Y 5 (cont) (cont) ONCE JUL JUL (cont) (cont) BForm Level Completion Instructions CM Record all <protocol-specified inclusions> medications taken within <protocol-specified period>. Do not record < list of protocol-defined exceptions>. <protocol medications of interest > must be recorded on the <name of special medication CRF> CDASH_UG April 2010

66 BODM CRF Examples CM BPaper CRF Example CM CDASH_UG April 2010

67 BEDC CRF Example CM CDASH_UG April 2010

68 3.5 23BDemographics (DM) BCDASH to SDTM Mapping DM These recommendations are for Demography data. The Demography domain is a special purpose domain that collects specific data elements that are mapped to SDTM. Additional data elements may be collected on the same page as Demography data, but those elements will be mapped to other Domains. All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What is the subject s date of birth? BRTHDAT HR BRTHDTC Perm BRTHDAT is the variable for date of birth. The sponsor may choose to database the date of birth as a single variable (BRTHDAT), or as separate variables for each component of the date/time (BRTHYR, BRTHMO, BRTHDY, BRTHTIM see below). The sponsor may choose a method based on database considerations, or for regulatory reasons. It is expected that what is collected for BRTHDAT (complete date or whichever components are collected) is reported in the SDTM BRTHDTC in the ISO 8601 format. If data are collected in a manner resulting in a reduced precision level, then the AGE (SDTM required variable), if not collected on the CRF, should be derived using a documented algorithm that describes how the age was derived and/or imputed for those birth dates collected with reduced precision. What is the subject s year of birth? BRTHYR (Year component of BRTHDAT) HR BRTHDTC (year component) Perm Year of Birth is the collected variable used for recording the year component of the Date of Birth. What is the subject s month of birth? BRTHMO (Month component of BRTHDAT) R/C BRTHDTC (month component) Perm Month of Birth is the collected variable used for recording the month component of the Date of Birth. The month of birth should be collected unless an Ethics Committee or local Data Protection Authorities (DPA) disagrees with the collection of the complete date of birth due to privacy concerns. In this case it might be best to omit this component of the Date of Birth to assuage those concerns. What is the subject s day of birth? BRTHDY (Day component of BRTHDAT) R/C BRTHDTC (day component) Perm Day of Birth is the collected variable used for recording the day component of the Date of Birth. The day of birth should be collected unless an Ethics Committee or local Data Protection Authorities (DPA) disagrees with the collection of the complete date of birth due to privacy concerns. In this case it might be best to omit this component of the Date of Birth to assuage those concerns. CDASH_UG April 2010

69 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What is the time of the subject s birth? BRTHTIM (Time component of BRTHDAT) O BRTHDTC (time component) Perm The level of detail collected by Time of Birth may be necessary for analysis for some pediatric, natal or neonatal studies. What is the subject s age? What is the age unit used? What is the date of collection? What is the sex of the subject? What is the ethnicity of the subject? AGE O AGE Exp If Age is collected, it should be collected as a number and, to be correctly interpreted, the age value needs to be associated to a variable for the Age Unit. It may be necessary to know when the age was collected as an age may need to be recalculated for analysis, such as deriving age at a reference start time (RFSTDTC for SDTM). If AGE is collected, then it is recommended that the date of collection also be recorded, either separately or by association to the date of the visit. AGEU O AGEU Exp If Age is captured on the CRF, the age unit must be known to make the Age value meaningful. The age unit might be collected on the CRF, in those cases where the protocol allows for any age group, or it may be pre-printed on the CRF (typically with the unit of "years"). DMDAT R/C DMDTC Perm If date of collection is collected it will map to DMDTC in SDTM. SEX HR SEX Req Collect the subject s sex or gender, as reported by subject or caretaker. This is the self-reported sex of the individual and/or is the clinician s assignment based on a physical examination. This is a phenotypic assessment and a genotypic assessment (see Section Collecting Sex, Ethnicity and Race). Values collected on the CRF should be from the CDISC Code list C66731 (M F U UN) ETHNIC R/C ETHNIC Perm Study participants should self-report ethnicity, with ethnicity being asked about before race. If more detailed characterizations of ethnicity are collected to enhance data quality and consistency, it is recommended that they be collapsible up to the two categories for reportable ethnicity, as needed for reporting to FDA under its guidance. Other regulatory bodies may expect the reporting of ethnicity values (different than the US FDA), which more appropriately reflect the population of their areas (e.g., Japanese ancestry for MHLW reporting to Japan). These may be collected as an extension to the suggested NCI- CDISC code list. CDASH_UG April 2010

70 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What is the race of the subject? RACE R/C RACE Exp If multiple races are collected, an alternate sponsor-defined variable structure may be required. Study participants should self-report race, with race being asked about after ethnicity. (The FDA guidance suggests that individuals be permitted to designate a multiracial identity. Check all that apply at the time of collection.) The categories listed in the FDA Guidance are as follows: -American Indian or Alaska Native -Asian -Black or African American* -Native Hawaiian or Other Pacific Islander -White *For studies where data are collected outside the US, the recommended categories are the same except for Black instead of Black or African American. If more detailed characterizations of race or ethnicity are collected to enhance data quality and consistency, it is recommended that they be collapsible up to the five minimum designations for race, as well as the two categories for reportable ethnicity, as needed for reporting to FDA under its guidance. When more detailed categorizations are desired, the use of race and vocabulary tables located within Health Level Seven s Reference Information Model Structural Vocabulary Tables is recommended, as they are designed to collapse up in this manner. Specify other race. RACEOTH O SUPPDM. QNAM (value of RACEOTH) (Nonstandard variable) When creating the Demographics form, it is suggested that you include the five standard race categories. If you choose, you might include another value of "Other, specify" with a free text field for extending the list of values. The RACEOTH variable contains the free text added by the site. The value(s) added in the optional variable might or might not "collapse up" into one of the five categories specified by the FDA Guidance. See SDTM for examples of reporting this implementation. NA NA NA ARM Req NA NA NA ARMCD Req NA NA NA COUNTRY Req CDASH_UG April 2010

71 BImplementation Examples DM BExample 1 This is an example of a Demography CRF that collects primary race only. For one subject, only the year and month of birth were collected BPaper Case Report Form (DM) Demographics Date of Birth Sex Race (DD/MMM/YYYY) 1 Male 2 Female (Select all that apply) / _/ 1 White 2 Black/African American Ethnicity 3 Asian 1 Hispanic 2 Non- Hispanic 4 Native Hawaiian/Other Pacific Islander 5 American Indian/Alaska Native 99 Other Specify: BRTHDTC (Perm) AGE (Exp) AGEU (Exp) SEX (Req) RACE (Exp) ETHNIC (Perm) YEARS FEMALE NATIVE HAWAIIAN OR OTHER PACIFIC ISLANDER HISPANIC OR LATINO YEARS FEMALE BLACK OR AFRICAN AMERICAN YEARS UNKNOWN AMERICAN INDIAN OR ALASKAN NATIVE NOT HISPANIC OR LATINO NOT HISPANIC OR LATINO T19:39 2 MONTHS MALE ASIAN HISPANIC OR LATINO T00:30 4 DAYS FEMALE WHITE NOT HISPANIC OR LATINO CDASH_UG April 2010

72 BExample 2 See the SC Section for an example of a DM CRF that collects some SC data BForm Level Completion Instructions DM Record data for all fields on this page. CDASH_UG April 2010

73 BODM CRF Examples DM BPaper CRF Example DM CDASH_UG April 2010

74 BEDC CRF Example DM CDASH_UG April 2010

75 3.6 24BDisposition (DS) The information eventually submitted in the SDTMIG DS domain can be captured on many other CRFs. Most typical are: Demographics, Randomization and End of Study BCDASH to SDTM Mapping DS All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v.3.1.2) Implementation Notes To which period of the trial does this disposition refer? EPOCH R/C EPOCH Perm Typically, the trial epoch will be pre-printed on the CRF as the title of the page; however, some companies have a standard CRF module that includes a pick-list of epochs. See SDTMIG for further information regarding EPOCH. What was the subject's status? DSDECOD (or DSTERM) HR DSDECOD and DSTERM Req Controlled terminology is available for DSDECOD, and CDASH strongly recommends that it be used (the current, approved controlled terminology list is under discussion for completeness, accuracy, and extensibility). The Subject Status data collection field should be presented on the CRF as a check box linked to an item from the approved controlled terminology list (DSDECOD). For those companies that wish to collect sponsor- and/or study-specific reasons for discontinuation (DSTERM), CDASH recommends that these reasons be pre-printed on the CRF, with check boxes for completion wherever possible, as sub-categories of the appropriate DSDECOD item. However, CDASH recommends limiting the use of sponsor- and study-specific reasons in order to promote consistent use of terminology and hence permit the combination of data across multiple sponsors. In some circumstances (e.g. DSDECOD = Withdrawal by subject or Other ), where additional information may be valuable but where it may not be possible to specify sub-categories explicitly, specify lines may be inserted next to the appropriate controlled terminology items to permit this information to be collected. The controlled terminology list may be filtered to omit terms that are NA for a study or particular milestone. 1 DSTERM may be used by itself to collect verbatim disposition terms when no code list is provided for DSDECODE on the CRF. Either DSTERM or DSDECODE must be on the CRF. 1 The controlled terminology item Completed may be omitted if completion is not possible due to study design; Completed should be clearly defined either on the CRF or in CRF Completion Instructions (in the latter case, preferably on the facing page to the CRF (for paper CRFs), or in a pop-up window on the screen (for electronic CRFs)); CDASH_UG April 2010

76 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v.3.1.2) Implementation Notes Specify other status DSTERM HR DSTERM Req DSTERM is used to collect the verbatim term for subject status when Other is selected from the DSDECOD code list. This field would only be used with the Prompt and Completion Instructions provided as an Other, Specify field in conjunction with DSDECODE. What was date the subject completed or discontinued? DSSTDAT R/C DSSTDTC (date component) Exp Define in the protocol and/or CRF Completion Instructions the criteria for completion of each trial epoch for which a disposition CRF will be provided. Define also the date of completion or discontinuation. Only collect the date of completion or discontinuation on the disposition CRF module if the same information is not being collected on another CRF module. For example, if the date of the last dose is defined to mark the end of the Treatment Phase epoch, and is collected on the Exposure form, then this field would not be collected on the Disposition CRF module. If not collected elsewhere, this variable should be collected on the Disposition CRF module. For the SDTM-based dataset, the SDTMIG variable DSSTDTC is derived by concatenating CDASH Date and Time of Completion or Discontinuation (if time is collected) into DSSTDTC using the ISO 8601 format. What was time the subject completed or discontinued? DSSTTIM O DSSTDTC (time component) Exp Define in the protocol and/or CRF Completion Instructions the criteria for completion of each trial epoch for which a disposition CRF will be provided. Define also the date of completion or discontinuation. Collecting the time of completion or discontinuation is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. Typically, it is not recommended that a time be collected unless the subject is under the direct care of the site at the time of the event. Only collect the time of completion or discontinuation on the disposition CRF module if the same information is not being collected on another CRF module. For example, if the time of the last dose is defined to mark the end of the Treatment Phase epoch, and is collected on the Drug Exposure form, then this field would not be collected on the Disposition CRF module. For the SDTM-based dataset, the SDTMIG variable DSSTDTC is derived by concatenating CDASH Date and Time of Completion or Discontinuation (if time is collected) into DSSTDTC using the ISO 8601 format. Was treatment unblinded by the site? Will the subject continue? DSUNBLND O NS NS None. DSCONT O NS NS Sponsor should specify what the next phase of the trial or the related trial is. Completed should be defined in the protocol, and the definition provided in the CRF or CRF Completion Instructions must be consistent with the contents of the protocol; Completed should be separated from the other terms (reasons for non-completion) in the CRF lay-out in order to re-emphasize its importance CDASH_UG April 2010

77 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v.3.1.2) Implementation Notes What is the next period the subject will continue to? DSNEXT O NS NS Sponsor should specify what the next phase of the trial or the related trial is. NA NA NA DSCAT Req Use to distinguish between Protocol Milestones, Disposition Events and Other Events. See SDTMIG V3.1.2 for implementation instructions BImplementation Examples DS BDisposition Example 1 In this example, a DS CRF collects multiple disposition events at different time points in the study indicated by EPOCH. There are also several protocol milestones which are indicated by DSCAT = 'PROTOCOL MILESTONE'. DSTERM is populated with controlled terminology with the same value as DSDECOD except in the case when there is free text for DSTERM such as 'Subject moved'. In this case, the controlled terminology is only in DSDECOD (LOST TO FOLLOW-UP). Notes: 1. Not all variables specified in the CDISC DS domain are present on the CRF (e.g., DSSCAT, DSSTDY). Since they are not used; the variables are not present on the DS dataset. However, all required and expected variables are present and populated. 2. In the Events observation class, the date/time of the Disposition Event is the DSSTDTC variable. The date of collection of the disposition information is the DSDTC variable. 3. EPOCH can be derived from VISITNUM. In the example below, when VISITNUM = 0, then EPOCH = SCREENING. EPOCH is populated when DSCAT is a disposition event and null when DSCAT is a protocol milestone. There are multiple disposition events for each subject: Subject has 3 records to indicate the completion of 3 stages of the study, which are screening, treatment phase and follow-up. Protocol milestone records for informed consent and randomization are also included. Subject is a screen drop. Screen drops are identified by a DSDECOD that is not equal to 'COMPLETED' for the SCREENING stage. This is an example of the submission of the verbatim reason for discontinuation in DSTERM. Subject completed the screening stage but did not complete the treatment stage. Subject died on October 29, 2003 (see DSSTDTC) after the completion of treatment, but prior to the completion of follow-up. Note that the date of collection of the event information was on October 31, 2003 (DSDTC). Subject discontinued study treatment due to an AE, but went on to complete the follow-up phase of the trial. The following table is sample data that illustrates the above bullet points. CDASH_UG April 2010

78 STUDYID DOMAIN USUBJID DSSEQ DSTERM DSDECOD DSCAT VISITNUM EPOCH DSDAT DSSTDAT Row 1 ABC123 DS INFORMED CONSENT OBTAINED INFORMED CONSENT OBTAINED PROTOCOL MILESTONE 0 21-SEP SEP-2003 Row 2 ABC123 DS COMPLETED COMPLETED Row 3 ABC123 DS RANDOMIZED RANDOMIZED DISPOSITION EVENT PROTOCOL MILESTONE 0 SCREENING 29-SEP SEP SEP SEP-2003 Row 4 ABC123 DS COMPLETED COMPLETED DISPOSITION EVENT 2 TREATMENT PHASE 31-OCT OCT-2003 Row 5 ABC123 DS COMPLETED COMPLETED DISPOSITION EVENT 3 FOLLOW-UP 15-NOV NOV-2003 Row 6 ABC123 DS INFORMED CONSENT OBTAINED INFORMED CONSENT OBTAINED PROTOCOL MILESTONE 0 21-NOV NOV-2003 Row 7 ABC123 DS SUBJECT DENIED MRI PROCEDURE PROTOCOL VIOLATION DISPOSITION EVENT 0 SCREENING 22-NOV NOV-2003 Row 8 ABC123 DS INFORMED CONSENT OBTAINED INFORMED CONSENT OBTAINED PROTOCOL MILESTONE 0 15-SEP SEP-2003 Row 9 ABC123 DS COMPLETED COMPLETED Row 10 ABC123 DS RANDOMIZED RANDOMIZED DISPOSITION EVENT PROTOCOL MILESTONE 0 SCREENING 22-SEP SEP SEP SEP-2003 Row 11 ABC123 DS SUBJECT MOVED LOST TO FOLLOW-UP DISPOSITION EVENT 1 TREATMENT PHASE 31-OCT OCT-2003 Row 12 ABC123 DS INFORMED CONSENT OBTAINED INFORMED CONSENT OBTAINED PROTOCOL MILESTONE 0 15-SEP SEP-2003 Row 13 ABC123 DS COMPLETED COMPLETED Row 14 ABC123 DS RANDOMIZED RANDOMIZED DISPOSITION EVENT PROTOCOL MILESTONE 0 SCREENING 22-SEP SEP SEP SEP-2003 Row 15 ABC123 DS COMPLETED COMPLETED DISPOSITION EVENT 2 TREATMENT PHASE 15-OCT OCT-2003 Row 16 ABC123 DS SUBJECT DIED DEATH DISPOSITION EVENT 1 FOLLOW-UP 31-OCT OCT-2003 Row 17 ABC123 DS INFORMED CONSENT OBTAINED INFORMED CONSENT OBTAINED PROTOCOL MILESTONE 0 28-SEP SEP-2003 Row 18 ABC123 DS COMPLETED COMPLETED DISPOSITION EVENT 0 SCREENING 02-OCT OCT-2003 CDASH_UG April 2010

79 STUDYID DOMAIN USUBJID DSSEQ DSTERM DSDECOD DSCAT VISITNUM EPOCH DSDAT DSSTDAT Row 19 ABC123 DS RANDOMIZED RANDOMIZED PROTOCOL MILESTONE 1 02-OCT OCT-2003 Row 20 ABC123 DS ANEMIA ADVERSE EVENT DISPOSITION EVENT 2 TREATMENT PHASE 17-OCT OCT-2003 Row 21 ABC123 DS COMPLETED COMPLETED DISPOSITION EVENT 3 FOLLOW-UP 02-NOV NOV BDisposition Example 2 In this example, the sponsor has chosen to simply submit whether or not the subject completed the study. Examples are shown of one subject who completed the study, and two subjects who discontinued the study prior to completion. In this very straightforward situation, only required and expected variables have been included. STUDYID DOMAIN USUBJID DSSEQ DSTERM DSDECOD DSSTDAT Row 1 ABC456 DS COMPLETED COMPLETED 21-SEP-2003 Row 2 ABC456 DS SUBJECT TAKING STUDY MED ERRATICALLY PROTOCOL VIOLATION 29-SEP-2003 Row 3 ABC456 DS LOST TO FOLLOW-UP LOST TO FOLLOW-UP 15-OCT BDisposition Example 3 In this example, the sponsor collects whether or not the subject completes the treatment and follow-up phases as well as whether the subject s treatment assignment was unblinded. The date of the unblinding is represented in DSSTDTC. Note that maintaining the blind as per protocol is not considered to be an event since there is no change in the subject s state. STUDYID DOMAIN USUBJID DSSEQ DSCAT EPOCH DSTERM DSDECOD DSSTDAT Row 1 ABC789 DS DISPOSITION EVENT Row 2 ABC789 DS DISPOSITION EVENT Row 3 ABC789 DS DISPOSITION EVENT TREATMENT PHASE COMPLETED COMPLETED 12-SEP-2004 FOLLOW-UP COMPLETED COMPLETED 20-DEC-2004 TREATMENT PHASE SKIN RASH ADVERSE EVENT 30-SEP-2004 Row 4 ABC789 DS OTHER EVENTS TREATMENT PHASE SUBJECT HAD SEVERE RASH TREATMENT UNBLINDED 01-OCT-2004 Row 5 ABC789 DS DISPOSITION EVENT FOLLOW-UP COMPLETED COMPLETED 28-DEC-2004 CDASH_UG April 2010

80 BForm Level Completion Instructions DS Record all relevant protocol milestones, such as Informed Consent Obtained, or Randomized. Once the subject has completed or discontinued from the study, record the subject s final disposition on this page. CDASH_UG April 2010

81 BODM CRF Examples DS BPaper CRF Example DS BEDC CRF Example DS CDASH_UG April 2010

82 3.7 25BDrug Accountability (DA) The CDASH Drug Accountability domain defines the variables needed to collect information about drug dispensed to and returned from clinical trial subjects. The Drug Accountability (DA) variables are sometimes used to calculate the subject s compliance with the study treatment however, based on the study design, this may not provide the most accurate information, as medication that is not returned may not necessarily have been consumed by the subject, thereby giving a false estimate of compliance. In addition, the SDTMIG standard separates DA from compliance and treats each differently. The name of the study treatment (DATEST values) can be pre-specified on the CRF if the data are collected in a de-normalized format. The SDTMIG states "one record per drug accountability finding per subject." The combined use of the SDTMIG variables provides the ability to uniquely identify findings. The term dispensed refers to when the test article/study product is given to the subject. This is independent of other dosing conditions specified in the protocol. The inclusion of a DA CRF/eCRF is optional. The DA Domain Team recommends that this data collection instrument not be used for single dose studies. The Domain Team discussed various drug accountability scenarios for single dose studies and concluded that this standard would be of limited value for studies with a single dose BCDASH to SDTM Mapping DA Refer to Section 2.7 for more information about normalized versus de-normalized structures for Findings Domains. This section will provide two options for collection of Drug Accountability data. All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables BMapping to SDTM from Normalized DA Collection Question Text Was drug accountability performed? What type of treatment was dispensed or returned? What was the name of the study treatment dispensed or returned? Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes DAPERF O NS NS Indicate whether or not drug accountability was done. This may be implemented for an entire Drug Accountability or on a visit-by-visit basis. This is intended to be used as a data management tool to verify that results missing from the CRF were intentional. For the SDTM-based dataset, the SDTMIG variable DASTAT can be derived from DAPERF. DACAT O DACAT Perm The CDASH DA team suggests that DACAT and DASCAT can be used to identify the treatment, kit identifiers, etc. to allow linking the DA records back to the Exposure (EX) records. DASCAT O DASCAT Perm The CDASH DA team suggests that DACAT and DASCAT can be used to identify the treatment, kit identifiers, etc. to allow linking the DA records back to the Exposure (EX) records. CDASH_UG April 2010

83 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What date was the study treatment (dispensed or returned)? What is the treatment label identifier? DADAT R/C DADTC Exp The date study treatment dispensed / returned should be recorded for each dispensation for a study with multiple periods or multiple products dispensed. For the SDTM-based dataset, the SDTMIG variable DADTC is derived by putting the CDASH DADAT(and DATIM, if used) into DADTC using the ISO 8601 format. DAREFID O DAREFID Perm Is this the amount dispensed or the amount returned? DATEST HR DATEST and Req Req DATEST and DATESTCD can both be populated from the collection of DATEST. The CDISC Controlled Terminology should be used for Amount Dispensed (DISPAMT) and Amount Returned (RETAMT). DATESTCD What is the amount dispensed or the amount returned? DAORRES HR DAORRES and Exp For a study with multiple periods or multiple products dispensed, drug accountability should be assessed for each dispensation. In this case, a sequence number or a group ID should be used to tie together a block of related records and to link dispensed product to returned product. DASTRESC Exp What are the units of study treatment dispensed or returned? DAORRESU HR DAORRESU Perm Unit of product dispensed (i.e., tablets). The unit will need to be pre-printed on the CRF or a field provided on the CRF to capture it. DAORRESU: The UNIT code list that is associated with this field contains some values that may also be considered formulations (e.g., capsule, tablet, puff). There may be some cases in which the use of these values is appropriate for collecting DAORRESU, such as when no more specific dispensing or return information can be collected without unblinding the data. CDASH_UG April 2010

84 BMapping to SDTM from De-normalized DA Collection Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Was drug accountability performed for dispensed study treatment? DISPAMT.DAPERF O NS NS Indicate whether or not drug accountability was done for dispensing. This may be implemented for an entire Drug Accountability or on a visit-by-visit basis. This is intended to be used as a data management tool to verify that results missing from the CRF were intentional. For the SDTM-based dataset, the SDTMIG variable DASTAT can be derived from DAPERF. What type of treatment was dispensed? What was the name of the study treatment returned? DISPAMT.DACAT O DACAT Perm The CDASH DA team suggests that DACAT and DASCAT can be used to identify the treatment, kit identifiers, etc. to allow linking the DA records back to the Exposure (EX) records. DISPAMT.DASCAT O DASCAT Perm The CDASH DA team suggests that DACAT and DASCAT can be used to identify the treatment, kit identifiers, etc. to allow linking the DA records back to the Exposure (EX) records. What is the dispensed DISPAMT.DAREFID O DAREFID Perm The use of a label identifier can be used to create links between DA and EX records. treatment label identifier? What date was the study treatment dispensed? DISPAMT.DADAT R/C DADTC Exp The date study treatment dispensed should be recorded for each dispensation for a study with multiple periods or multiple products dispensed. For the SDTM-based dataset, the SDTMIG variable DADTC is derived by putting the DADAT(and DATIM, if used) into DADTC using the ISO 8601 format. What is the amount dispensed? DISPAMT.DAORRES HR DATESTCD and DATEST and DAORRES and DASTRESC Req Req Exp For a study with multiple periods or multiple products dispensed, drug accountability should be assessed for each dispensation. In this case, a sequence number or a group ID should be used to tie together a block of related records and to link dispensed product to returned product. DISPAMT would be mapped to SDTMIG variables DISPSAMT (derived to) =DATESTCD, Dispensed Amount (derived to) =DATEST, and the value collected in DISPAMT = DAORRES. The DAORRES value would be standardized (if needed) and populated into DASTRESC (and DASTRESN if numeric). Exp What are the units of study treatment dispensed? Was drug accountability performed for returned study treatment? DISPAMT.DAORRESU HR DAORRESU Exp Unit of product dispensed (i.e., tablets). The unit will need to be pre-printed on the CRF or a field provided on the CRF to capture it. Maps to SDTMIG variable DAORRUSU where DATESTCD=DISPAMT DAORRESU: The UNIT code list that is associated with this field contains some values that may also be considered formulations (e.g., capsule, tablet, puff). There may be some cases in which the use of these values is appropriate for collecting DAORRESU, such as when no more specific dispensing information can be collected without unblinding the data. RETAMT.DAPERF O NS NS Indicate whether or not drug accountability was done for return. This may be implemented for an entire Drug Accountability or on a visit-by-visit basis. This is intended to be used as a data management tool to verify that results missing from the CRF CDASH_UG April 2010

85 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes were intentional. For the SDTM-based dataset, the SDTMIG variable DASTAT can be derived from DAPERF. What type of treatment was returned? What was the name of the study treatment returned? RETAMT.DACAT O DACAT Perm The CDASH DA team suggests that DACAT and DASCAT can be used to identify the treatment, kit identifiers, etc. to allow linking the DA records back to the Exposure (EX) records. RETAMT.DASCAT O DASCAT Perm The CDASH DA team suggests that DACAT and DASCAT can be used to identify the treatment, kit identifiers, etc. to allow linking the DA records back to the Exposure (EX) records. What is the returned RETAMT.DAREFID O DAREFID Perm The use of a label identifier can be used to create links between DA and EX records. treatment label identifier? What was the date the study treatment was returned? RETAMT.DADAT R/C DADTC Exp The date study treatment returned should be recorded for each return for a study with multiple periods or multiple products returned. For the SDTM-based dataset, the SDTMIG variable DADTC is derived by putting the DARDAT into DADTC using the ISO 8601 format. What is the amount returned? RETAMT.DAORRES HR DATESTCD and DATEST and DAORRES and DASTRESC Req Req Exp For a study with multiple periods or multiple products returned, drug accountability should be assessed for each return. In this case, a sequence number or a group ID should be used to tie together a block of related records and to link dispensed product to returned product. RETAMT would be mapped to SDTMIG variables RETAMT (derived to) =DATESTCD, Returned Amount (derived to) =DATEST, and the value collected in RETAMT = DAORRES. The DAORRES value would be standardized (if needed) and populated into DASTRESC (and DASTRESN if numeric). Exp What are the units of RETAMT.ORRESU HR DAORRESU Exp Unit of product returned (i.e., tablets). study treatment returned? The unit will need to be pre-printed on the CRF or a field provided on the CRF to capture it. Maps to SDTMIG variable DAORRESU where DATESTCD=RETAMT DAORRESU: The UNIT code list that is associated with this field contains some values that may also be considered formulations (e.g., capsule, tablet, puff). There may be some cases in which the use of these values is appropriate for collecting DAORRESU, such as when no more specific return information can be collected without unblinding the data. CDASH_UG April 2010

86 BImplementation Examples DA Rows 1 and 2 show subject was dispensed 8 tablets of study medication on 02 Jan 2009 and returned 0 tablets on 09 Jan Row 3 shows 8 tablets of placebo dispensed to subject on 03 Jan This subject either dropped out or the Drug Accountability CRF was not completed for the return of the Placebo tablets for this subject because there is no RETAMT record. Rows 4 and 5 shows subject was dispensed 8 tablets of study medication on 04 Jan 2009, returned 2 of them on 09 Jan USUBJID DADAT DATESTCD DATEST DAORRES DAORRESU DACAT DASCAT JAN-2009 DISPAMT Dispensed Amount 8 Tablets Study Medication Bottle A JAN-2009 RETAMT Returned Amount 0 Tablets Study Medication Bottle A JAN-2009 DISPAMT Dispensed Amount 8 Tablets Placebo Bottle B JAN-2009 DISPAMT Dispensed Amount 8 Tablets Study Medication Bottle A JAN-2009 RETAMT Returned Amount 2 Tablets Study Medication Bottle A BForm Level Completion Instructions DA All investigational product dispensed to and returned by the subject should be recorded on this page. CDASH_UG April 2010

87 BODM CRF Examples DA BPaper CRF Example DA BEDC CRF Example DA CDASH_UG April 2010

88 3.8 26BECG (ECG) BECG Test Results (EG) CDASH provides guidance on collection of ECG data under three different scenarios represented in the following process flow diagrams. Site performs ECG, or distributes device such as a Holter monitor to the subject Site sends ECG results or device to sponsor selected central ECG vendor for analysis. Central ECG vendor analyzes data Report may be sent from central ECG vendor to site Results data are sent from central ECG vendor to sponsor Site enters date ECG performed and/or ID information on CRF or ecrf CRF pages or ecrf data are transmitted to Sponsor CRF data are used to ensure that results data file is complete Scenario 1: Central Processing CDASH_UG April 2010

89 Site performs ECG Site enters ECG results on CRF or ecrf Site may or may not assess clinical significance of results CRF pages or ecrf data are transmitted to Sponsor Scenario 2: Local Processing Site performs ECG, or distributes device such as a Holter monitor to the subject Site enters date ECG performed and/or ID information on CRF or ecrf CRF pages or ecrf data are transmitted to Sponsor CRF data are used by Sponsor to ensure that results data file is complete Site sends ECG results or device to sponsor selected central ECG vendor for analysis. Central ECG vendor analyzes data Report/data sent from central ECG vendor to site for assessment of clinical significance Site enters data related to clinical significance CRF pages or ecrf data are transmitted to Sponsor Results data are sent from central ECG vendor to sponsor Scenario 3: Central Processing with Secondary Site Assessment of Clinical Significance CDASH_UG April 2010

90 BCDASH to SDTM Mapping EG Although ECGs have three scenarios, this does not affect the variables to be submitted, therefore, there is just one mapping table included in the. All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Was the ECG performed? EGPERF Scenario 1: HR Scenario 2: HR Scenario 3: HR NS NS This may be implemented for an entire ECG or on a test-by-test basis This is intended to be used as a data management tool to verify that results missing from the electronic transfer were intentional. For the SDTM-based dataset, the SDTMIG variable EGSTAT can be derived from EGPERF. EGSTAT will have a value of NOT DONE or null. What was the ECG reference identifier? EGREFID Scenario 1: O Scenario 2: Not Applicable Scenario 3: O EGREFID Perm This may be used to provide additional detail to ensure the electronic data file is complete. Since Scenario 2 assumes that the data will only be recorded on the CRF, no reference ID is usually applicable. If the date and/or time of collection are insufficient to identify that the electronic transfer is complete, a reference ID may be a means to reconciling the electronic data. However, care should be taken that a reference ID is easily identified and transcribed by the site. For example, an ID with too many digits in it is prone to transcription errors and may cause more work than benefit. What was the method used to measure ECG? EGMETHOD Scenario 1: O Scenario 2: O Scenario 3: O EGMETHOD Perm Unless the study design permitted the sites to make a decision about the method of ECG they will use, this would not be collected as a question on the CRF. In cases where the study design is such that the method is known ahead of time for all measurements, then the value for EGMETHOD could be derived in the SDTM datasets rather than collecting it on the CRF. What was the position of the subject during ECG measurement? EGPOS Scenario 1: O Scenario 2: O Scenario 3: O EGPOS Perm If the study design allows for the site to perform the ECG with the subject in a choice of positions, then this should be collected on the CRF. However, if the position of the subject is not relevant, or if it can be derived from the protocol (e.g. all measurement are done with the subjects) then the CRF should not include this field. What was the ECG date? EGDAT Scenario 1: HR Scenario 2: HR Scenario 3: HR EGDTC Exp A complete date is expected. The date of collection may be derived from the date of visit and if so, a separate assessment date field is not required. For the SDTM-based dataset, the SDTMIG variable EGDTC is derived by putting the EGDAT (and EGTIM when collected) into DADTC using the ISO 8601 format. CDASH_UG April 2010

91 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What was the planned time point of the measurement? EGTPT Scenario 1:R/C Scenario 2:R/C EGTPT Perm Planned time point would be needed to differentiate for multiple sequential assessments. It is recommended that time points should be pre-printed on the CRF rather than collected in a field that requires the site to enter text. Scenario 3:R/C What was the ECG time? EGTIM Scenario 1:R/C Scenario 2:R/C EGDTC Exp Especially important when multiple assessments are done on one day. When it is needed, the time of collection may be collected in addition to a date of collection. It may also be collected instead of a date of collection when date of collection is derived from the date of visit. Scenario 3:R/C For the SDTM-based dataset, the SDTMIG variable EGDTC is derived by putting the EGDAT (and EGTIM when collected) into DADTC using the ISO 8601 format. What was the ECG test name? EGTEST Scenario 1: NA Scenario 2: HR EGTEST and Req Required to identify the test. It is recommended that the test names be pre-printed on the CRF. Note: This field is subject to controlled terminology. Some of this terminology is worded differently than sites may be used to. For example," Summary (Mean) QRS Duration" as opposed to "QRS Duration". Scenario 3: HR EGTESTCD What was the result of the ECG? EGORRES Scenario 1: NA Scenario 2: HR Scenario 3:R/C EGORRES and EGSTRESC Exp Key data collected. What were the ECG result units? EGORRESU Scenario 1: NA Scenario 2: HR Scenario 3: O EGORRESU Exp May be included if not standardized. Was the ECG clinically significant? EGCLSIG Scenario 1: NA Scenario 2: O Scenario 3: HR maps to SUPPEG where QNAM = EGCLSIG Perm May be included if required by the protocol. CDASH_UG April 2010

92 BImplementation Examples EG BExample 1 The site performs the ECG on equipment that electronically transfers the measurements to a central ECG vendor, who provides the measurements and an overall assessment of the results directly to the Sponsor. The Sponsor would like to use the CRF data to ensure that the electronic data files are complete. This falls under Scenario BExample 2 The site performs the ECG measurements and reports them along with an overall assessment on the CRF. This is Scenario BExample 3 The site distributes a Holter monitor to the subjects at Visit 1. The subject wears the monitor for 24 hours and returns it to the site. The site then sends the measurements from the Holter monitor to a central ECG vendor who provides the data electronically to the sponsor and sends a report to the site. The investigator provides their assessment of clinical significance to any abnormal measurements. This is Scenario BExample 4 The site performs the ECG on equipment that electronically transfers the measurements to a central ECG vendor. The Sponsor does not require any reconciliation of the electronic data received by the ECG vendor. In this situation, no CRF for ECG data is required. It is not necessary for the site to provide any additional information to that which the Sponsor is already receiving electronically from the ECG vendor BExample 5 The site performs the ECG measurements, and the study design only requires a simple assessment of the clinician's overall impression of whether the results are normal or abnormal as well as the clinical significance of the interpretation. It is extremely common for sponsors to combine the interpretation and clinical significance into a single response as illustrated below. Some of the rationale for this design was to ensure clinical significance was only associated with an abnormal result and thereby reduce the need for queries, and to reduce the number of items the clinician was required to mark. This design is not CDASH-conformant because clinical significance should be collected as a separate field. For EDC studies, the features of the EDC system can be used to only permit clinical significance to be entered if the interpretation was given as "abnormal". CDASH_UG April 2010

93 Non-conformant example: Normal If abnormal, please describe: ECG Interpretation Abnormal, not clinical significant Abnormal, clinically significant The CDASH-conformant version of this CRF is given below. Note that the order of the questions and layout may be changed without affecting the conformance. CDASH-conformant example: ECG Interpretation Normal Abnormal Clinically significant? Yes No Abnormality BForm Level Completion Instructions EG ECG tracings should <protocol-specified process for tracing retention or forwarding>. Please remember that an abnormality on an ECG may represent a new adverse event. Record all Adverse Events on the Adverse Events CRF. CDASH_UG April 2010

94 BODM CRF Examples EG BPaper CRF Example EG CDASH_UG April 2010

95 CDASH_UG April 2010

96 CDASH_UG April 2010

97 CDASH_UG April 2010

98 CDASH_UG April 2010

99 BEDC CRF Example EG CDASH_UG April 2010

100 CDASH_UG April 2010

101 CDASH_UG April 2010

102 3.9 27BExposure (EX) This proposal includes the SDTMIG-based variables that appear in the SDTMIG The SDTMIG defines the EX domain model as follows: The Exposure domain model records the details of a subject s exposure to protocol-specified study treatment. Study treatment may be any intervention that is prospectively defined as a test material within a study, and is typically but not always supplied to the subject. Examples include but are not limited to placebo, active comparator, and study treatment. Treatments that are not protocol-specified should be recorded in the Concomitant Medications (CM) domain. The dose variables in this proposal refer to the collection of the actual dose rather than the planned dose BCDASH to SDTM Mapping EX All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Was dosing administered as planned? EXYN O NS NS This variable is used for data cleaning and monitoring purposes. It does not map to an SDTMIG variable in the EX domain, but can be used to collect compliance data for dosing. What was the treatment start date? What was the treatment start time? What is the treatment label identifier? What was the treatment end date? EXSTDAT HR EXSTDTC EXP The Start Date of Treatment must be captured in order to calculate the subject s exposure to the study treatment. EXSTTIM R/C EXSTDTC EXP The Start Time of study treatment is recommended / conditional because not all study designs require capturing the time the subject was exposed to the study treatment. The majority of Clinical Pharmacology / Phase I studies capture start time(s) of study treatment to enable analysis of PK data. Often for Phase II-IV studies, the level of precision that the start time provides is not necessary for analysis because the start and stop dates are usually sufficient. EXREFID R/C EXREFID Perm EXREFID may be useful in linking DA and EX records. EXENDAT R/C EXENDTC PERM The End Date of exposure is recommended /conditional depending on the study design. For single dose studies, the end date may not need to be collected because it can be determined from the start date. The End Date will need to be populated in the database for reporting purposes. CDASH_UG April 2010

103 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What was the treatment end time? EXENTIM R/C EXENDTC PERM The Stop Time of study treatment is recommended / conditional because not all study designs require capturing the time the subject was exposed to the study treatment. The majority of Clinical Pharmacology / Phase I studies capture stop time(s) of study treatment to enable analysis of PK data. Often for Phase II-IV studies, the level of precision that the stop time provides is not necessary for analysis because the stop date is usually sufficient. What was the dose per administration? EXDSTXT R/C EXDOSE or EXDOSTXT EXP The Dose of study treatment should be captured on the CRF page when the study design of the trial includes multiple dosing schemas. If the same dose is administered to all subjects throughout the trial, it is not necessary to collect the dose on the CRF. The dose can be populated in the clinical trial database. EXDOSTXT may be used to submit non-numeric responses. EXDOSE should be used if the responses are numeric. What were the units for the dose? EXDOSU R/C EXDOSU EXP If the dose is captured on the CRF page, the unit must also be present. The unit will need to be preprinted / pre-populated on the CRF or a field provided on the CRF to capture it. EXDOSU: The UNIT code list that is associated with this field contains some values that may also be considered formulations (e.g., capsule, tablet, puff). There may be some cases in which the use of these values is appropriate for collecting EXDOSU, such as when no more specific dosage information can be collected without unblinding the data. What was the lot number of the study treatment used? What was the kit number of the study treatment used? What was the study treatment? Was the dose adjusted from planned? What was the reason the dose was adjusted? EXLOT O EXLOT PERM The lot number of the study treatment should only be captured when needed for analysis. EXKIT O NS NS EXKIT may be useful in linking EX and DA records. EXTRT R/C EXTRT REQ Depending on the study design, it may not be necessary to capture the name of the study treatment on the CRF. For example, if the study is a dose comparison of the same drug, it would not be necessary to record the treatment name on the CRF. However, the name of the study treatment would need to be populated in the clinical trial database. EXDOSADJ O NS NS This yes/no question provides a definitive response weather or not the dose was adjusted. Variable EXADJ will capture the reason/explanation why the dose was changed. This question should be used as a data cleaning tool and should not be present in SDTM. EXADJ O EXADJ PERM The reason for dose adjustment should be used when the study design permits multiple changes to dosing. Dosing changes often occur in Oncology studies. CDASH_UG April 2010

104 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What was the frequency of study treatment dosing? What was the route of administration for the study treatment? What was the formulation of the study treatment? If the dose was interrupted, how long was the interruption? EXDOSFRQ O EXDOSFRQ PERM The frequency of study treatment administration should be captured when needed for analysis. Often the frequency of study treatment administration remains fixed and constant during the study. In this scenario the frequency does not need to be captured on the CRF and may be pre-populated in the clinical trial database. EXROUTE R/C EXROUTE PERM The route of study treatment administration should be captured when needed for analysis. Often the route of study treatment administration remains fixed and constant during the study. In this scenario the route does not need to be captured on the CRF and may be pre-populated in the clinical trial database. EXDOSFRM R/C EXDOSFRM PERM The formulation of study treatment should be captured when needed for analysis. Often the formulation (e.g. tablets, capsules) of study treatment administration remains fixed and constant during the study. In this scenario the formulation does not need to be captured on the CRF because it can be pre-populated in the clinical trial database. EXINTRP O NS NS Does not map directly to SDTM although there is an EXDUR variable for Duration of treatment that is PERM. For some study designs it may be necessary to know how long the study treatment was interrupted. If the start and stop dates and times of each administration are captured on a daily basis, the interruption may derived from this data. However, sometimes only start and stop dates are collected for each treatment period without collecting the start and stop times. In this scenario it would not be possible to calculate the duration of the interruption. It is anticipated that this data collection field would typically be used for infusion studies where the length of the interruption needs to be captured. If the dose was interrupted, what were the units for the duration? EXINTRPU O NS NS The unit of the interruption needs to be captured when EXINTP is captured. What was the anatomical location of the administration? What was the total volume of study treatment administered? EXLOC O EXLOC PERM The location of study treatment administration should only be captured when it is needed for analysis purposes. For example, for a dermatological study the location of where a study treatment ointment was applied would probably need to be captured. EXVOLT O NS NS This data collection field should be used when the Total Volume Administered needs to be collected. For example, this could be used for an infusion study when the total volume of saline and study treatment needed to be captured. This value can be submitted using supplemental qualifiers. See further instructions in SDTMIG. CDASH_UG April 2010

105 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What were the units for the volume of study treatment administered? What was the study treatment infusion rate? What were the units for the infusion rate? What was the planned time point for study treatment? Did subject complete the full course of study treatment? What was the planned dose per administration? What were the units for the planned dose? EXVOLTU O NS NS The unit needs to be captured when the total volume administered is captured. This value can be submitted using supplemental qualifiers. See further instructions in SDTMIG. EXFLRT O NS NS This data collection field is to capture the rate of an infused study treatment. The flow rate should be captured only when needed for analysis purposes. This value can be submitted using supplemental qualifiers. See further instructions in SDTMIG. EXFLRTU O NS NS The unit needs to be captured when the flow rate is captured. This value can be submitted using supplemental qualifiers. See further instructions in SDTMIG. EXTPT O EXTPT PERM The planned time point is a text description of the time when a dose should be given. EXMEDCMP O NS NS This variable is used for data cleaning purposes and does not map to SDTM. EXPDOSE O NS NS This value can be submitted using supplemental qualifiers. See further instructions for SUPPEX in SDTMIG. This is not currently an SDTM variable, but is under discussion by the SDS team. EXPDOSU O NS NS This value can be submitted using supplemental qualifiers. See further instructions for SUPPEX in SDTMIG. This is not currently an SDTM variable, but is under discussion by the SDS team. CDASH_UG April 2010

106 BImplementation Examples EX BExample 1 This section provides an example of how exposure data could be collected via a CRF using CDASH standards. Subject takes a 30 mg tablet of Drug A three times a day starting on 05 January 2009, and ends on 10 January Subject takes a 50 mg capsule of Drug B twice a day starting on 06 January 2009, and ends of 15 January Subject takes a 40 mg capsule of Drug C twice a day starting on 10 January 2009, and is ongoing. USUBJID EXTRT EXSTDAT EXENDDT EXDOSE EXDOSU EXDOSFRM EXDOSFRQ Drug A 05 Jan Jan mg Tablet TID Drug B 06 Jan Jan mg Capsule BID Drug C 10 Jan mg Capsule BID BForm Level Completion Instructions EX This page is used to record <include protocol-specified information to be reported> for all investigational product taken by the subject as per the protocol. Investigational product dispensed to a subject but not actually taken must not be recorded on this page but must be reflected in the Drug Accountability CRF(s). The exposure CRF page must be consistent with the Drug Accountability CRFs. CDASH_UG April 2010

107 BODM CRF Examples EX BPaper CRF Example EX CDASH_UG April 2010

108 CDASH_UG April 2010

109 BEDC CRF Example EX CDASH_UG April 2010

110 CDASH_UG April 2010

111 BInclusion and Exclusion Criteria (IE) These recommendations are for the inclusion or exclusion criteria that are identified during the eligibility process as "not met" for subjects who are subsequently enrolled in the study. It is not intended to collect protocol deviations or violations that occur after enrollment. As with all the data collection variables recommended in the CDASH Standard Version 1.0, it is assumed that sponsors will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., TA-specific data elements and others as required per protocol, business practice, and operating procedures). The following table includes the CDASH recommendations for collecting IE data and mapping it to the Required variables in an SDTMIG IE dataset BCDASH to SDTM Mapping IE All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core Implementation Notes Did the subject meet all eligibility criteria? IEYN HR NS NS This is a Yes/No question that is intended to be used primarily as a monitoring or data management tool to verify that the investigator/site reported any entry criteria that were not met for this subject. The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that if the other fields on the CRF were left blank, it was intentional. While IEYN will not be directly included as part of the SDTMIG IE Domain for submission, a negative response in this field may be used to derive data into IEORRES. Any Inclusion criterion recorded would imply a No response for IEORRES, and any Exclusion criterion would imply a Yes response for IEORRES. What is the identifier of the criterion the subject did not meet? What is the description of the criterion the IETESTCD HR IETESTCD Req This is a sponsor-defined identifier that uniquely identifies a criterion in the TI table. This field is required to appear on the CRF, but may be null if all criteria are met. If it is null, there would be no record in the SDTMIG IE submission dataset. If inclusion and exclusion criteria lists are independently numbers (e.g., inclusion , exclusion ), then this identifier must include a means of identifying the type of criterion (i.e., inclusion or exclusion). An example of how this may be done is to use I001-I100 for inclusion and E001-E100 for exclusion criteria. The examples provided are only examples; an individual organization's numbering scheme may be different. Although multiple responses should be allowed on the CRF, CDASH does not have a recommendation for how many unmet criteria should be allowed. CDASH recommends that the sponsor determine how many lines are needed on the CRF based on their experience. In some studies there may not be any subjects enrolled with unmet eligibility criteria. In this case, there would not need to be any SDTMIG IE dataset in the submission. IETEST O IETEST Req This is the wording of the entry criterion taken from the protocol. Must match the IETEST in the SDTMIG TI dataset. CDASH_UG April 2010

112 Question Text Variable Name CDASH Core SDTM Variable Name subject did not meet? SDTM Core Implementation Notes EDC The primary use of this field would be on an ecrf in an EDC system. This field could be automatically populated when the Criterion Identifier is populated, and then be verified by the PI to ensure the right Identifier was selected, or it could be selected from a drop-down list and the IETESTCD could be automatically populated. Paper Only the IETESTCD should be recorded on the CRF for any criteria that the subject did not meet or pass. The monitoring process should include a cross-verification of entry criteria against the medical records for each subject to ensure that any criteria not met were recorded on the CRF. What was the category of the criterion? IECAT O IECAT Req If the Sponsor is using unique identifiers for the criteria, the category can be included in the identifier. For example, all inclusion identifiers might begin with INC and all exclusion identifiers might begin with EXC. In this case the category may be derived from the identifier. NA NA NA IEORRES Req IEORRES in SDTM datasets is used to submit a yes or no response for criteria that are not met. If a criterion is recorded on the CRF the value of IEORRES may be blank in the dataset because there is no NO or YES response as an original response. NA NA NA IESTRESC Req IESTRESC is the standardized value for the IEORRES value. Since only records for subjects who did not pass all entry criteria are submitted in the IE dataset, the value of IESTRESC may be derived from any response in IETESTCD. Any IECAT record with a value of INCLUSION would derive an N response into IESTRESC to indicate that the Inclusion Criterion was not met. Any IECAT record with a value of EXCLUSION would derive a Y response into IESTRESC to indicate that the subject qualified for the exclusion criterion. CDASH_UG April 2010

113 BImplementation Examples IE BExample 1 This is an example of an IE paper CRF that collects IEYN and IETESTCD (the identifier for the criteria that are not met). In this example, a worksheet would be used per subject by the site to record all the responses to the inclusion and exclusion criteria. This worksheet would be a source document for that subject. The following is an example of a worksheet used during screening for subject 1003: Subject: 1003 Protocol: 123XYZ Criterion Identifier (record this identifier on the CRF for any criterion that is not met Criterion by this subject) Inclusion Criteria Yes or No INC1101 Subject between the ages of 18 and 45 Yes INC1102 Male; or Female with no child-bearing potential Yes INC1103 Exclusion Criteria History of elevated intra-ocular pressure between 20 and 25 for less than six months EXC2301 History of cancer No EXC2302 History of drug abuse No EXC2303 History of diabetes No EXC2304 Elevated liver enzymes at screening No EXC2305 History of cardiovascular disease Yes Yes CDASH_UG April 2010

114 This worksheet would be considered a source document for this subject and maintained in the Investigator s study files for that subject. The data would then be filled in for this subject on the paper CRF: Protocol 123XYZ Site: Subject: E Did Subject meet all eligibility criteria for the study? Yes No X If No, list all criteria that were not met below: EXC2305 TRW 05-May-2008 Finally the data entered from the CRF would be entered in the Sponsor s database and the resulting SDTM+/- output would result: Rows 1, 4, and 5 show an example of subjects that met all the eligibility criteria. Rows 2 and 3 show examples of subjects that did not meet all eligibility criteria, including subject 1003 from the CRF example. Row SubjectID IEYN IETESTCD Y N INC N EXC Y CDASH_UG April 2010

115 Y The table is SDTM +/- because no data is submitted for subjects who meet all eligibility criteria. The records for subjects 1001, 1004 and 1005 would be removed during the preparation of the SDTM datasets. The IETESTCDs would be used for subjects 1003 and 1004 to map in the IETEST and other variables required in the SDTMIG dataset BExample 2 This is an example dataset from an EDC IE CRF that collects IEYN for each subject, and IETEST for any criteria that are not met by a subject. IEYN and IETEST fields use drop-down lists. When IETEST is recorded for a subject, IETESTCD and IECAT are displayed for the site to verify. Rows 1, 4, and 5 show an example of subjects that met all the eligibility criteria. Rows 2 and 3 show examples of subjects that did not meet all eligibility criteria. Row* SubjectID* IEYN** IETESTCD* IETEST** IECAT* Y N INC1101 Subject between the ages of 18 and 45 INCLUSION N EXC2305 History of cardiovascular disease EXCLUSION Y Y *Columns highlighted in red are displayed (only) in EDC. **Columns in black are entered by the site using a list of values from the system BForm Level Completion Instructions IE All procedures must be performed and the subject s eligibility determined within <protocol-specified time period> prior to study medication administration. Complete the Inclusion / Exclusion Worksheet as source document for recording a Yes or No response to each criterion. Record ONLY the Inclusion or Exclusion criteria that the subject did NOT meet on this CRF BODM CRF Examples IE There were no CRF ODM examples produced for IE because the list of values for each study would come from the entry criteria for that study. See the examples in section BPaper CRF Example IE Not included in ODM examples. CDASH_UG April 2010

116 BEDC CRF Example IE Not included in ODM examples. CDASH_UG April 2010

117 BLab Test Results (LB) CDASH provides guidance on collection lab data under three different scenarios represented in the following process flow diagrams: Site obtains lab sample. Site sends to a Sponsor determined central lab" for analysis Central lab analyses sample Site enters only data sample taken and ID data into CRF or ecrf system Scenario 1: Central Processing Results data sent to sponsor from central lab Report (usually) sent to site CRF pages or ecrf data transmitted to Sponsor Site obtains lab sample. Site sends to their lab for analysis (or analyses onsite) Site may or may not assess clinical significance Copy of analysis retained at site Site enters all data into CRF or ecrf system CRF pages or ecrf data transmitted to Sponsor Scenario 2: Local Processing CDASH_UG April 2010

118 Site obtains lab sample and sends to a "Sponsor determined central lab" for analysis Central lab analyses sample. Results data sent to sponsor from central lab Report/data sent to Site for assessment of clinical significance. Site enters data into CRF or ecrf system Copy of analysis retained at Site CRF pages or ecrf data transmitted to Sponsor Site enters date taken and ID data into CRF or ecrf system. CRF pages or ecrf data transmitted to Sponsor Scenario 3: Central Processing with Secondary Site Assessment of Clinical Significance CDASH_UG April 2010

119 BCDASH to SDTM Mapping LB Although labs have three scenarios, this does not affect the variables to be submitted, therefore, there is just one mapping table included in this. All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Was the lab performed? LBPERF Scenario 1: HR Scenario 2: HR Scenario 3: HR NS NS This may be implemented for an entire panel, or on a test-by-test basis. This is intended to be used as a data management tool to verify that missing results are confirmed missing. For SDTM based datasets, LBPERF may be used to populate the SDTMIG variable LBSTAT. What was the lab Specimen collection date? LBDAT Scenario 1: HR Scenario 2: HR Scenario 3: HR LBDTC Exp A complete date is expected. The date of collection may be derived from the date of visit and if so, a separate assessment date field is not required. For the SDTM-based dataset, the SDTMIG variable LBDTC is derived by putting the LBDAT (and LBTIM when collected) into DADTC using the ISO 8601 format. What was the lab specimen collection time? LBTIM Scenario 1: R/C Scenario 2: R/C Scenario 3: R/C Especially important when multiple assessments are done on one day. When it is needed, the time of collection may be collected in addition to a date of collection. It may also be collected instead of a date of collection when date of collection is derived from the date of visit. For the SDTM-based dataset, the SDTMIG variable LBDTC is derived by putting the LBDAT (and LBTIM when collected) into DADTC using the ISO 8601 format. What was the lab panel name? LBCAT Scenario 1: R/C Scenario 2: R/C LBCAT Exp Included as needed for clarity (e.g., HEMATOLOGY, URINALYSIS, CHEMISTRY). Scenario 3: R/C What was the lab panel name? LBSCAT Scenario 1: R/C Scenario 2: R/C LBSCAT Perm Included as needed for clarity (e.g., HEMATOLOGY, URINALYSIS, CHEMISTRY). Scenario 3: R/C What was the planned time point of the lab? LBTPT Scenario 1: R/C Scenario 2: R/C LBTPT Perm Planned time point would be needed to differentiate for multiple sequential assessments. It is recommended that time points should be pre-printed on the CRF rather than collected in a field that requires the site to enter text. CDASH_UG April 2010

120 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Were the protocol-defined testing conditions met? LBCOND Scenario 1: R/C Scenario 2: R/C Scenario 3: R/C LBFAST (for example, otherwise, NS Perm The specific testing conditions required should be pre-printed on the CRF, such as Did subject meet fasting requirements?. Results may be affected by whether conditions for testing were properly met (e.g., fasting). This may not be relevant for all tests. What was the condition of the specimen? LBSPCCND Scenario 1: NA Scenario 2: R/C Scenario 3: NA LBSPCCND Perm Results may be affected by whether conditions for specimen were properly met (e.g., HEMOLYZED, ICTERIC, LIPEMIC) What is the test name? LBTEST Scenario 1: NA Scenario 2: HR Scenario 3: HR LBTEST and LBTESTCD Req Required to identify the test. It is recommended that the test names be pre-printed on the CRF. This field is subject to CDISC Controlled Terminology. Refer to the current Controlled Terminology for Lab Test names. What was the result of the test? LBORRES Scenario 1: NA Scenario 2: HR LBORRES Exp Key data collected. Scenario 3: R/C What were the units for the result? LBORRESU Scenario 1: NA Scenario 2: R/C Scenario 3: NA LBORRESU Exp May be included if not standardized. What was the lower limit of the reference range for this test? What was the high limit of the reference range for this test? LBORNRLO LBORNRHI Scenario 1: NA Scenario 2: R/C Scenario 3: NA Scenario 1: NA Scenario 2: R/C Scenario 3: NA LBORNRLO LBORNRHI Exp Exp LBORNRLO and LBORNRHI should be populated only for continuous results; LBSTNRC should be populated only for non-continuous results. These data may be obtained from the lab or the electronic equipment. These data could be derived from a site or lab specific set of normal ranges stored in a look up table. See SDTMIG for details on mapping on selecting the proper variable name. Was the result for this test abnormal? LBNRIND Scenario 1: NA Scenario 2: R/C Scenario 3: NA LBNRIND Exp Abnormal flags may be included if not derived or determined programmatically after data collection. Was this result clinically significant? LBCLSIG Scenario 1: NA Scenario 2: R/C Scenario 3: HR NS NS May be included if required by the protocol. May be submitted using supplementation qualifiers. See the SDTMIG for full instructions. LBCLSIG maps to SUPPLB QVAL where QNAM = LBCLSIG CDASH_UG April 2010

121 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What was the name of the laboratory used? LBNAM Scenario 1: NA Scenario 2: R/C Scenario 3: NA LBNAM Perm May be included on CRF if multiple labs are used by a site. If collecting lab names as free text, sponsors might consider developing a LAB ID so that different ways of writing the names of certain labs will not appear in datasets as different labs. What was the accession number? LBREFID Scenario 1: R/C Scenario 2: R/C Scenario 3: R/C LBREFID Perm This can be used to confirm that the appropriate data record is present in the electronic transfer May be included for linking back to specimens (e.g., Specimen ID) BImplementation Examples BForm Level Completion Instructions LB Clinically significant results must be reported with the protocol required lab test and on the Adverse Event CRF. Changes that are worsening must be reported on the Adverse Event CRF. If a laboratory test is found to be clinically significant but is not a protocol required test or listed on the CRF, be sure to record an adverse event. Verify lab results against laboratory <protocol-specific> requirements. Ensure that all pertinent laboratory normal ranges/units and laboratory certification for all laboratories used during the study have been provided to the sponsor with a copy in your Study Files. This is required for regulatory and database purposes. CDASH_UG April 2010

122 BODM CRF Examples LB BPaper CRF Example LB CDASH_UG April 2010

123 CDASH_UG April 2010

124 CDASH_UG April 2010

125 BEDC CRF Example LB CDASH_UG April 2010

126 CDASH_UG April 2010

127 CDASH_UG April 2010

128 BMedical History (MH) BCDASH to SDTM Mapping MH All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Has the subject experienced any past and/ or concomitant diseases or past surgeries? What is the medical history identifier? Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes MHYN O NS NS This prompt question is collected as an aid to monitoring and data processing, and should not be included in an SDTM submission. It is included in CDASH as an optional field for administrative purposes. Some sponsors find this data useful as an aid to data cleaning. It may also be useful in an EDC system for displaying forms dynamically based on the response to this question. MHSPID O MHSPID Perm If the CRF has pre-printed row numbers for Medical History data, these may be used to populate MHSPID in the SDTM submission. NA MHCAT R/C MHCAT Perm There is no recommendation for Question Text because this would be pre-printed on the NA MHSCAT R/C MHSCAT Perm CRF/eCRF. The type of medical history that is being recorded may be categorized and sub-categorized according to the needs of the study. These categories may or may not be pre-printed on the CRF, or pre-populated in an EDC system. What is the verbatim term for the medical history condition/event? Is the medical history disease/condition or event still ongoing? Is the medical history disease/condition under control? MHTERM HR MHTERM Req Medical History terms may be reported spontaneously or may be pre-populate in the CRF. MHONGO O NS NS If an end date is not provided for the reported term, it may be useful to know whether the medical history condition is still ongoing at the time of data collection. This information can be used to populate relative timing variables, such as MHENREF or MHENRTPT. MHCTRL O NS NS If an end date is not provided for the reported term it may be useful to know whether the medical history condition has been controlled at the time of data collection. CDASH_UG April 2010

129 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Does the subject have <specific condition>? MHOCCUR O MHOCCUR Perm If Medical History conditions are pre-populated in the CRF, a Yes/No question for whether the condition is present in this study subject may be used on the CRF. MHOCCUR is an optional variable that can be used to capture whether a pre-specified MHTERM is present for this subject. Example: Does the subject have high blood pressure? OR Has the subject had <specific procedure>? Example: Has the subject had an appendectomy? What was the date the medical history event or condition started? What was the date the medical history event or condition ended? MHSTDAT O MHSTDTC Perm If a start date for the Medical History term is needed in the CRF, MHSTDAT is used on the CRF to collect the date a user-friendly, unambiguous format (e.g., 05-May-2009). This CDASH date is then transformed into an ISO 8601 format for the submission variable MHSTDTC). Note that Medical History dates are often incomplete dates and may only contain the month and year, or possibly only the year or a possible range of years (e.g., somewhere between 1994 and 1996). MHENDAT O MHENDTC Perm If a start date for the Medical History term is needed in the CRF, MHSTDAT is used on the CRF to collect the date a user-friendly, unambiguous format (e.g., 05-May-2009). This CDASH date is then transformed into an ISO 8601 format for the submission variable MHSTDTC). Note that Medical History dates are often incomplete dates and may only contain the month and year, or possibly only the year or a possible range of years (e.g., somewhere between 1994 and 1996). What was the date that the medical history was collected? BImplementation Examples MH MHDAT O MHDTC Perm This is the date the Medical History data were recorded. May be derived from the Visit Date in the CRF/eCRF. This may be used as a reference time point (MHSTTPT or MHENTPT) if no MHENDAT is collected to indicate when the medical history condition ended in relation to the collection date. The following Medical History CRF is provided as an example of one possible way to represent the CDASH model in a simple Medical History form. The table that follows the CRF example is the sample output from the operational database for this subject s CRF. The output has not yet been converted to SDTM even though some of the variables, such as MHTERM, will map directly to an SDTM variable. CDASH_UG April 2010

130 STUDYID DOMAIN Subject VISITDATE MHTERM MHSTDAT MHONGO 287CL4569 MH R MAY-2009 PSORIASIS Y 287CL4569 MH R MAY-2009 CHF DEC 1999 Y 287CL4568 MH R MAY-2009 KIDNEY STONES 31OCT1982 N 287CL4568 MH R MAY-2009 BROKEN WRIST (RIGHT ARM) MARCH 2005 N 287CL4568 MH R MAY-2009 TONSILLECTOMY 1975 N 287CL4568 MH R MAY-2009 MUMPS 1964 N 287CL4568 MH R MAY-2009 FRACTURED R TIBIA 1963 N BForm Level Completion Instructions MH Any relevant abnormalities, surgeries, allergies, diseases or disorders that start <protocol-specified time frame> must be included on this record. Any relevant abnormalities, diseases or disorders that start after the signing of the informed consent must be recorded as an adverse event. If a condition listed on the Medical History page worsens in intensity and/or frequency after the start of study medication, record on the Adverse Events page. CDASH_UG April 2010

131 <protocol medical history of interest > must be recorded on the <name of special medical history CRF>. CDASH_UG April 2010

132 BODM CRF Examples MH BPaper CRF Example MH BEDC CRF Example MH CDASH_UG April 2010

133 CDASH_UG April 2010

134 BPhysical Exam (PE) BCDASH to SDTM Mapping PE Best Practice Approach Following this approach, if the sponsor chooses to create a PE CRF to capture Was the Physical Examination performed? and Date/Time of Examination, these optional fields are intended for monitoring and data cleaning only. Data collected would not be submitted in a PE dataset since they are collected on the Medical History and Adverse Events forms. When using the PE Best Practice Approach, the SDTM PE dataset is not expected, and there would be no data to submit in the SDTMIG PE dataset BTraditional Approach All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core Implementation Notes Was the physical examination performed? PEPERF O NS NS If this information is collected, it is primarily used for data cleaning. It can also be used to populate the PESTAT variable either for the whole exam, or for individual PETESTCD/PETESTs. What was the physical examination date? What was the physical examination time? What is the sponsor-defined ID? PEDAT R/C PEDTC Exp The date of examination may be derived from the date of visit and therefore a separate assessment date field is not required. For the SDTM dataset, PEDTC is derived by concatenating PEDAT & PETIM (if time is collected) into PEDTC using the ISO 8601 format. PETIM O For the SDTM dataset, PEDTC is derived by concatenating PEDAT & PETIM (if time is collected) into PEDTC using the ISO 8601 format. PESPID O PESPID Perm 1:1 mapping to SDTM CDASH_UG April 2010

135 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core Implementation Notes What was the body system examined? PETEST HR PETEST and PETESTCD Req Sponsor should pre-populate CRF with all body systems to be examined. The use of a complete list of body systems eliminates the need for an Other, specify category as any abnormalities identified should fall under one of the pre-specified categories. Even if the sponsor does not require all body systems to be examined at a given time point, the complete list should still be used. Instructions should be given to the site to record Not Done in Exam Result field for any systems not examined. If PEYN = No, Create one record for the visit and populate PETEST with subject level value Physical Examination per SDTM Were the results normal, abnormal or not done? PERES HR PEORRES and PESTRESC Exp For each body system listed on the CRF, provide the following options for results: Normal, Abnormal and Not Done. Sites should be directed to complete overall assessment for each exam category/body system listed. If the examined body system is Normal, then populate PEORRES with the value NORMAL per SDTMIG If the body system is not examined, then the value in PEORRES should be Null and the value in PESTAT should be NOT DONE. If the examined body system is Abnormal, then the value of PEORRES should contain the text of the abnormal findings from PEDESC. If the sponsor s data collection system allows for up front recording of the abnormality and status using one variable, then the SDTMIG variable name PEORRES should be used in place of CDASH variables PERES and PEDESC. If the exam was not performed or PEYN = No, PEORRES is null per SDTM If the result was abnormal, what were the findings? PEDESC HR PEORRES and PESTRESC Exp Map text entered under abnormal findings in PEDESC to PEORRES. If the sponsor s data collection system allows for recording the abnormality and status using one variable, then the SDTMIG variable name, PEORRES should be used in place of CDASH variables PERES and PEDESC. Was the physical examination result clinically significant? What was the role of the person performing the physical examination? PECLSIG O NS NS If this level of information is needed for reconciliation with adverse events, this field may be added to the CRF. May be mapped to SUPPPE QVAL where QNAM = PECLSIG. See SDTMIG for full instructions on supplemental qualifiers. PEEVAL O PEEVAL Perm Used only for subjective results. For records that contain collected or derived data, value is null. CDASH_UG April 2010

136 BImplementation Examples PE Best Practice Approach Row 1: Shows an example of a subject whose physical examination was completed on a specified date. Row 2: Shows an example of a subject whose physical examination was completed at a specified date and time. Row 3: Shows an example of a subject whose physical examination was not performed on a specified date. Row USUBJID PEYN PEDAT PETIM Y 08-APR Y 15-APR : N 16-APR BTraditional Approach These examples use PERES & PEDESC Row 1: Shows an example of a subject whose physical examination was performed with a normal result. Row 2: Shows an example of a subject whose physical examination was performed with an abnormal result. Row 3: Shows an example of a subject whose physical examination was performed. However, this body system was not examined. Row 4: Shows an example of a subject whose physical examination was not performed. Row USUBJID PEYN PEDAT PETIM PESPID PETEST PERES PEDESC PECLSIG PEEVAL Yes 08-APR :15 1 SKIN Normal Yes 08-APR :15 2 HEART Abnormal Heart murmur No Yes 08-APR :15 3 HEENT Not Done No 10-MAY These examples use PEORRES in place of PERES & PEDESC Row 1: Shows an example of a subject whose physical examination was performed with a normal result. Row 2: Shows an example of a subject whose physical examination was performed with an abnormal result. Row 3: Shows an example of a subject whose physical examination was performed. However, this body system was not examined. Where PEORRES is Not Done, Not Done can be mapped to PESTAT and PEORRES set to null when creating the SDTM dataset. Row 4: Shows an example of a subject whose physical examination was not performed and the test is populated with Physical Examination Row USUBJID PEYN PEDAT PETIM PESPID PETEST PEORRES PECLSIG PEEVAL Yes 08-APR :15 1 SKIN Normal - - CDASH_UG April 2010

137 Row USUBJID PEYN PEDAT PETIM PESPID PETEST PEORRES PECLSIG PEEVAL Yes 08-APR :15 2 HEART Heart murmur No Yes 08-APR :15 3 HEENT Not Done No 10-MAY PHYSICAL EXAMINATION BForm Level Completion Instructions PE The physical examination must be performed by a qualified health care professional (i.e., MD, PA or NP) listed on the FDA form Any clinically significant physical exam abnormalities, as defined and documented by the investigator, newly arising or worsening after the signing of the ICF, must be recorded on the AE Record CRF. Abnormalities at <protocol-specific time period> must be recorded on the Medical History or AE Record CRF. If the physical finding started prior to the signing of the Informed Consent Form (ICF), then it must be recorded on the medical history page. If the physical finding started after signing the ICF, it must be recorded as an AE. CDASH_UG April 2010

138 BODM CRF Examples PE BPaper CRF Example PE BEDC CRF Example PE CDASH_UG April 2010

139 BProtocol Deviations (DV) BCDASH to SDTM Mapping DV All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes Were there any protocol deviations? What was the protocol deviation type? What was the protocol deviation term? DVYN O NS NS May be derived in the analysis (submission) dataset if not collected on a CRF. DVDECOD R/C DVDECOD Perm This may be derived from a collected verbatim term. If a verbatim term is not collected using DVTERM, then a list of values may be provided in the DVDECOD field. Either DVTERM or DVDECOD should be on the CRF if protocol deviations are collected. DVTERM R/C DVTERM Req Recommended if collecting protocol deviations on a CRF. Either DVTERM or DVDECOD should be on the CRF if protocol deviations are collected. What was the protocol deviation start date? What was the protocol deviation start time? What was the protocol deviation end date? What was the protocol deviation end time? What is the protocol deviation ID? DVSTDAT O DVSTDTC Perm This may be derived if not collected on a CRF. For the SDTM-based dataset, the SDTMIG variable DVSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into DVSTDTC using the ISO 8601 format. DVSTTIM O For the SDTM-based dataset, the SDTMIG variable DVSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into DVSTDTC using the ISO 8601 format. DVENDAT O DVENDTC Perm For the SDTM-based dataset, the SDTMIG variable DVENDTC is derived by concatenating CDASH End Date and Time (if time is collected) into DVENDTC using the ISO 8601 format. DVENTIM O For the SDTM-based dataset, the SDTMIG variable DVENDTC is derived by concatenating CDASH End Date and Time (if time is collected) into DVENDTC using the ISO 8601 format. DVSPID O DVSPID Perm Can be pre-printed on the CRF as an explicit line identifier or defined in sponsor s operational database (e.g., Line number on a CRF page). CDASH_UG April 2010

140 BImplementation Examples DV BExample 1 This section provides an example of data collected on a protocol deviations CRF. The DVDECOD column is for controlled terminology, whereas the DVTERM is free text. Row 1: Shows an example of a subject that does not have any protocol deviations to report. Row 2: Shows an example of a subject who took a prohibited medication during the study (only collecting Start Date since only one occurrence). Row 3: Shows an example of a subject who took a prohibited concomitant medication over a period of time. Row 4: Shows an example of a subject participating in a prohibited activity. Row 5: Shows an example of a subject who took a prohibited medication during a study (using the DVDECOD rather than DVTERM). Row USUBJID DVSPID DVYN DVTERM DVDECOD DVSTDAT DVSTTIM DVENDAT DVENTIM No Yes TOOK ASPIRIN - 08-AUG Yes DRUG XXX ADMINISTERED DURING STUDY TREATMENT PERIOD - 05-SEP SEP Yes PARTICIPATED IN XXXX PROHIBITED ACTIVITY - 01-AUG :20 01-AUG : Yes - PROHIBITED MEDS 06-SEP BForm Level Completion Instructions DV Provide explanations for any protocol deviations. Enter a brief description or explanation. Do not use abbreviations. CDASH_UG April 2010

141 BODM CRF Examples DV BPaper CRF Example DV BEDC CRF Example DV CDASH_UG April 2010

142 3.15 Subject Characteristics (SC) (Findings) As mentioned earlier, the CDASH process began by using the SDTMIG as a model to identify data domains or categories of data for CDASH Standard Version 1.0 and example CRFs to identify regularly used variables, aligned to these SDTMIG domains. The Subject Characteristics domain was identified as a necessary domain to include in CDASH Standard Version 1.0 as it has been included as one of the SDTMIG domains since Version 3.0. The SDTM model (Version 1.1) states that the demographics domain describes the essential characteristics of the study subjects and is used by reviewers for selecting populations for analysis." (p. 13). Neither the SDTM nor the SDTMIG explicitly define what data are in the Subject Characteristics domain, but the SDTMIG does say that: "...data in this domain is collected only once per subject" (p. 29) "Subject Characteristics is for data not collected in other domains that is subject-related." (p. 83) and "The structure for demographic data is fixed and includes date of birth, age, sex, race, ethnicity and country. The structure of subject characteristics is based on the Findings SDTM Observation Class and is an extension of the demographics data, allowing the reporting of "non-essential" subject characteristics that might be useful as additional population selection criteria for analysis. Subject Characteristics consists of data that are collected once per subject (per test) and that is not expected to change during the trial. The SDTMIG states that "Subject Characteristics contains data such as additional information about race, subject initials, economic information, and eye color." (p. 83) The example CRFs that the SC Domain Team reviewed indicated a wide variety of data collected as Subject Characteristics. Some examples of these questions include: Marital status, Economic status, Education level achieved. These data might be useful for risk-benefits analyses or for quality of life analyses. Another example that the team identified is "Gestational age at birth". The SDTM VS domain utilizes a normalized data structure, i.e., one variable, SCTEST, is used to capture the test name and another variable, SCORRES, is used to capture the result. The SC Domain Team considered providing two options for the SC domain table; a normalized structure similar to that of SDTM and the other suggesting unique variables for each test. The normalized structure is recommended and is consistent with other Findings domains. If Subject Characteristics are collected then the table below describes what variables should be collected. CDASH_UG April 2010

143 BCDASH to SDTM Mapping SC All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core Have relevant subject characteristics been collected? SDTM Variable Name SDTM Core (v ) Implementation Notes SCPERF O NS NS The intent/purpose of collecting this field is to help with data cleaning and monitoring. SCPERF will not be included as part of the SDTMIG SC Domain for submission. [Subject Characteristic Question] SCTEST HR SCTEST and SCTESTCD Req It is recommended that the questions be pre-printed on the CRF Name of the subject characteristic being queried. {SCCD} [Subject Characteristic Answer/Result] SCORRES HR SCORRES and SCSTRESC Exp NA Examples of Subject Characteristics Questions Question Text Variable Name Definition Case Report Form Completion Instructions Additional Information for Sponsors 1 What is the subject's Gestational Age at Birth? SCTEST The age (in weeks) of the newborn infant, counted from the woman's last menstrual period (LMP) or health status indicators/clinical Estimate (CE). NA. A constant that may be useful for analysis in pediatric or neonatal study analyses. 2 What is the subject's childbearing potential? SCTEST Subject s childbearing potential. Check the correct box to indicate the subject s childbearing potential, or postmenopausal or sterilized as required for the form. NA. 3 What is the subject's highest education level achieved? SCTEST Education level achieved at start of study (Reference date). NA. NA. 4 What is the subject s skin classification SCTEST A classification system used to categorize the sensitivity of a subject's skin to sunlight. Skin Classification Skin type rating in the Fitzpatrick Skin Type classification system. 5 What is the subject s marital status? SCTEST A demographic parameter indicating a person's current conjugal status. Current Marital Status NA CDASH_UG April 2010

144 Question Text Variable Name Definition Case Report Form Completion Instructions Additional Information for Sponsors 4 [Sub-study Participation Question] SCTEST Sub-study participation information. NA. For some studies sub-study information is captured, such as subject is on fasting sub-study or subject is on PK sub-study. CDASH_UG April 2010

145 BImplementation Examples SC BExample 1 This section provides an example SDTM data from various SC questions: SCTEST Subject Initials Childbearing Potential Eye Color Skin Classification Marital Status SCORRES JEN Sterilized Hazel Type3 Married CDASH_UG April 2010

146 BExample 2 In the following example, subject level data is collected with the Demographics (DM) data, and mapped to Subject Characteristics (SC) The first two tables display the data collected in the Demography CRF: Study Identifier (STUDYID) Investigator Number (INV_NUM) Subject Number (SUBJ_NUM) Visit Number (VIS_NUM) Subject Initials (SUB_INIT) Visit Date (DMDAT) Date of Informed Consent (CONSNTDT) Date of Birth (BRTHDAT) SEX (SEX) Race (RACE) 1 ABC D-C 04/15/03 04/15/03 10/19/39 Male Caucasian 2 ABC DMK 10/06/03 10/06/03 01/31/83 Female Caucasian 3 ABC DEC 09/09/03 09/09/03 09/19/62 Male Caucasian 4 ABC JMK 09/18/03 09/18/03 08/13/47 Female Caucasian 5 ABC AAC 09/15/03 09/15/03 07/06/63 Female Caucasian High School Graduate/GED (HS_GRAD) Some College (SOM_COLL) College Graduate (COL_GRAD) Graduate Degree or Higher (GRAD_DEG) Brown Eyes (EYES_BRN) Blue Eyes (EYES_BL) Green Eyes (EYES_GR) Hazel Eyes (EYES_HZ) CDASH_UG April 2010

147 This table displays the SC dataset that is produced from the data collected in the Demography CRF above. Study Identifier (STUDYID) Domain Abbreviation (DOMAIN) Unique Subject Identifier (USUBJID) Sequence Number (SCSEQ) Subject Characteristic Short Name (SCTESTCD) Subject Characteristic (SCTEST) Result or Finding in Original Units (SCORRES) ABC-124 SC ABC EDU Education High School Graduate/GED Character Result/Finding in Std Format (SCSTRESC) High School Graduate/GED Date/Time of Collection (SCDTC) ABC-124 SC ABC INIT Subject Initials D-C D-C ABC-124 SC ABC EYECLR Eye Color Green Green ABC-124 SC ABC EDU Education College Graduate College Graduate ABC-124 SC ABC INIT Subject Initials DMK DMK ABC-124 SC ABC EYECLR Eye Color Blue Blue ABC-124 SC ABC EDU Education College Graduate College Graduate ABC-124 SC ABC INIT Subject Initials DEC DEC ABC-124 SC ABC EYECLR Eye Color Brown Brown ABC-124 SC ABC EDU Education College Graduate College Graduate ABC-124 SC ABC INIT Subject Initials JMK JMK ABC-124 SC ABC EYECLR Eye Color Blue Blue ABC-124 SC ABC EDU Education High School Graduate/GED High School Graduate/GED ABC-124 SC ABC INIT Subject Initials AAC AAC ABC-124 SC ABC EYECLR Eye Color Blue Blue BForm Level Completion Instructions SC CDISC does not recommend specific form level help for the Subject Characteristics Domain. CDASH_UG April 2010

148 BODM CRF Examples SC BPaper CRF Example SC CDASH_UG April 2010

149 BEDC CRF Example SC CDASH_UG April 2010

150 BSubstance Use (SU) BCDASH to SDTM Mapping SU All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes What was the type of substance used? Has the subject ever used the substance? What was the category of substance used? SUTRT HR SUTRT Req This field will collect the name of the substance that is used by the subject. In some CRFs, this will be pre-printed on the CRF. SUNCF HR SUOCCUR Perm Used to specify substances and solicit a Never, Current, or Former response to whether the subject uses those substances. Data map to SUOCCUR, which uses the NY, controlled terms. Never maps to N in SUOCCUR; Current and Former map to Y in SUOCCUR. SUCAT O SUCAT Perm The CRF may collect the category of the substance used. The category is defined by the Sponsor according to the requirements for the study. What was the amount of substance used? SUDSTXT O SUDOSTXT, or SUDOSE Perm This field will collect the amount of the substance that is used by the subject. Since this can either be a number or a character response, the value collected in this field may map to either SUDOSTXT or SUDOSE in SDTM. A single field is provided in the CRF to the site for ease of use. What was the unit of the substance used? What was the frequency of substance use? What was the start date of substance use? What was the end date of substance use? What was the duration of substance use? What was the unit of duration of SUDOSU O SUDOSU Perm If a unit is collected on the CRF, the data collected will map to UNIT controlled terms. Sponsor should either use the UNIT controlled terms in the CRF, or ensure the responses collected will map into this code list. SUDOSFRQ O SUDOSFRQ Perm If frequency of use is collected on the CRF, the data collected will map to map to FREQ controlled terms. Sponsor should either use the UNIT controlled terms in the CRF, or ensure the responses collected will map into this code list. SUSTDAT O SUSTDTC Perm If collected in the study, the date the subject started using this substance will be collected on the CRF in a user friendly format. The date will be reformatted into an ISO 8601 format for the SDTM variable SUSTDTC. SUENDAT O SUENDTC Perm If collected in the study, the date the subject stopped using this substance will be collected on the CRF in a user friendly format. The date will be reformatted into an ISO 8601 format for the SDTM variable SUENDTC. SUCDUR O SUDUR Perm This should only be collected on the CRF if this level of detail is needed and if SUSTDAT & SUENDAT are not collected on the CRF. The sponsor-defined options (e.g., weeks, months, years, etc.) should be pre-printed on the CRF SUCDURU O to avoid making this a free text field. This will allow the response to be translated into ISO 8601 format. CDASH_UG April 2010

151 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core (v ) Implementation Notes substance use? For the SDTM-based dataset, the SDTMIG variable SUDUR can be derived by concatenating the CDASH duration and duration unit s variables BImplementation Examples SU STUDYID SUBJID VISITDATE SUTRT SUNCF RR567 EGL MAY-2009 ALCOHOL NEVER RR567 EGL MAY-2009 TOBACCO NEVER RR567 EGL MAY-2009 CAFFEINATED CURRENT RR567 SML AUG-2009 ALCOHOL CURRENT RR567 SML AUG-2009 TOBACCO NEVER RR567 SML AUG-2009 CAFFEINATED FORMER CDASH_UG April 2010

152 BForm Level Completion Instructions SU Record the substance(s) usage of the subject. Be sure the information regarding substance(s) usage is in compliance with any specific inclusion/exclusion criteria of the protocol. CDASH_UG April 2010

153 BODM CRF Examples SU BPaper CRF Example SU CDASH_UG April 2010

154 BEDC CRF Example SU CDASH_UG April 2010

155 BVital Signs (VS) BCDASH to SDTM Mapping VS All CDASH variables and all Required and Expected SDTMIG variables are included in the mapping table except the common identifier variables. See section 3.1 for details on common identifier variables. Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core Additional Information for Sponsors Were vital signs collected? On what date were the measurements performed? At what time were the measurements performed? What is the Sponsor-Defined Identifier? VSPERF O NS NS If used, may be used to derive the Not done for VSSTAT VSDAT VSTIM R/C R/C VSDTC Exp The date of measurement can usually be derived from the date of visit and in such cases a separate measurement date field is not required. For the SDTM dataset, VSDTC is derived by concatenating VSDAT and VSTIM (if time is collected) into VSDTC using the ISO 8601 format. VSSPID O VSSPID Perm 1:1 mapping to SDTM What is the vital sign name? VSTEST HR VSTEST and Req It is recommended that the test names be pre-printed on the CRF. Populate VSTESTCD with corresponding VSTEST short names when creating SDTM VS dataset. VSTESTCD Req Indicate if the measurement was not done. VSSTAT R/C VSSTAT Perm If CRF design provides for individual status check boxes where site can indicate Not Done for the given parameter, collect the Not Done responses with VSSTAT. If a value exists in VSORRES, then VSSTAT is Null. If CRF guidelines direct site to enter Not Done (or similar text) in the result field, then map the Not Done value to VSSTAT. Otherwise if a numeric value exists in VSORRES, then the value of VSSTAT is Null. This field is used to assist in data monitoring and cleaning What was the result of the measurement? VSORRES HR VSORRES and VSSTRESC Exp If there are a limited number of pre-defined values for the result or finding, consider using controlled terminology for consistency in data collection. Otherwise collect original results or findings as free text or numeric values. and VSSTRESN What was the unit of the measurement? VSORRESU HR VSORRESU and VSSTRESU Exp It is recommended that the units be sponsor-defined and pre-printed on the CRF when possible. CDASH_UG April 2010

156 Question Text Variable Name CDASH Core SDTM Variable Name SDTM Core Additional Information for Sponsors Was the result clinically significant? At what location was the measurement taken? In what position was the subject during the measurement? VSCLSIG O NS NS If this level of information is needed, it may be added to the CRF. VSCLSIG may map to SUPPVS where QNAM = VSCLSIG. See the SDTMIG for more information about supplemental qualifiers. VSLOC O VSLOC Perm Location may be pre-defined as part of CRF label or it may be selected from a pre-defined list of values. Location may refer to a single test or possibly a group of tests. VSPOS O VSPOS Perm Position may be pre-defined as part of CRF label or site may be given one or more options to select. NA NA NA VSBLFL Exp See SDTMIG for information about baseline flags in Findings domains. NA NA NA VISITNUM Exp If this value is calculated, captured or pre-populated in an EDC system, map from there. VISITNUM may not be captured on a CRF, but may be printed on a paper CRF along with a VISIT name. NA NA NA VISIT Perm Typically pre-defined on the CRF. There may be situations where the clinical encounter name is selected on the CRF. If this is the case, it is preferred to design the CRF where these names are selected from pre-defined values. VISIT may also be derived from values on the CRF. For example, a combination of Cycle & Day may map to the VISIT. What is the planned time point for this measurement? VSTPT R/C VSTPT Perm If applicable, it is preferable to pre-define these values on the CRF (pre-print on paper) when measurements are required at multiple time points within a visit. A common scenario is to collect multiple time points within a day, though time points may be any set of timed assessments within a defined visit. CDASH_UG April 2010

157 BImplementation Examples VS BNormalized Examples These first two sets of examples show vitals collected by visit on individual CRFs vs. in a log style form. Row 1: Shows an example of a test performed at a specific time point. Row 2: Shows an example of a test that was not done at a specific time point. Rows 3 and 4: Show a pair of tests performed at a specific time point, by location and position, noted as clinically significant. Row 5: This example shows a test performed at a visit without a specific time point. In this set of examples, one set of vitals is collected at each visit. Pre-printed line numbers are not included on the CRF. Some visits have pre-printed planned time points, others have only a visit name on the collection day. Row USUBJID VSDAT VSTIM VSTPT VSTEST VSSTAT VSORRES VSORRESU VSCLSIG VSLOC VSPOS APR : APR :15 POST DOSE 2 HRS POST DOSE 2 HRS HEIGHT - 72 IN WEIGHT NOT DONE APR :15 POST DOSE 4 HRS SYSTOLIC BLOOD PRESSURE mmhg Y RIGHT ARM SITTING APR :15 POST DOSE 4 HRS DIASTOLIC BLOOD PRESSURE - 80 mmhg Y RIGHT ARM SITTING APR PULSE - 65 BEATS/MIN CDASH_UG April 2010

158 In this set of examples, vitals are collected log style with pre-printed line numbers. Note the addition of VSSPID. Row USUBJID VSDAT VSTIM VSSPID VSTPT VSTEST VSSTAT VSORRES VSORRESU VSCLSIG VSLOC VSPOS APR : APR :15 2 POST DOSE 2 HRS HEIGHT - 72 IN POST DOSE 2 HRS WEIGHT NOT DONE APR :15 1 POST DOSE 4 HRS SYSTOLIC BLOOD PRESSURE mmhg Y RIGHT ARM SITTING APR :15 2 POST DOSE 4 HRS DIASTOLI C BLOOD PRESSURE - 80 mmhg Y RIGHT ARM SITTING APR PULSE - 65 BEATS/MIN In this set of examples, vitals are collected on different days with only the date and result entered. Units are pre-printed on the CRF. Rows 1 and 2: Show an example of two tests planned for the same visit. The first is performed and the second is not done. Rows 3 and 4: Show a pair of tests with one set of units. Rows 5 and 6: This is an example where all tests for a planned visit are not performed. Row USUBJID VSDAT VSTEST VSSTAT VSORRES VSORRESU APR-2009 HEIGHT - 72 IN APR-2009 WEIGHT NOT DONE APR-2009 SYSTOLIC BLOOD PRESSURE mmhg APR-2009 DIASTOLIC BLOOD PRESSURE - 80 mmhg APR-2009 PULSE NOT DONE APR-2009 TEMPERATURE NOT DONE - - CDASH_UG April 2010

159 BDe-normalized Examples This set of examples demonstrates the above vitals collected log style with pre-printed line numbers in de-normalized format. Row 1: Shows an example of a four tests collected at a specific time point. One of the tests, Weight, was skipped. Blood pressure was noted by location and body position. Row 2: Shows an example of a two tests performed at a specific time point. Row 3: This example shows missed vitals measurements at a visit without a specific time point. Row USUBJID VSDAT VSTIM VSSPID VISIT VSTPT HEIGHT HEIGHTU HEIGHTND WEIGHT WEIGHTU WEIGHTND APR :15 1 DAY APR :15 2 DAY 1 POST DOSE 2 HRS 72 IN X POST DOSE 4 HRS APR WEEK Row SYSBP DIABP BPU BPND BPLOC BPPOS PULSE PULSEU PULSEND mmhg - RIGHT ARM SITTING 65 BEATS/MIN mmhg LEFT ARM STANDING 70 BEATS/MIN X RIGHT ARM SITTING - - X CDASH_UG April 2010

160 BForm Level Completion Instructions VS If several vital signs measurements fall within the visit window, use the <protocol-specific process for reporting the measurement for the window>. If there is a change in the vital signs that is deemed clinically significant by the investigator, record the finding as an Adverse Event. CDASH_UG April 2010

161 BODM CRF Examples VS BPaper CRF Example VS CDASH_UG April 2010

162 CDASH_UG April 2010

163 CDASH_UG April 2010

164 BEDC CRF Example VS CDASH_UG April 2010

165 CDASH_UG April 2010