CDASH Tutorial Elke Sennewald Berlin 19 February 2009

CDASH Tutorial Elke Sennewald Berlin, 19 February 2009 1

Learning Objectives • Learn more about CDASH V 1. 0 • Identify the domains addressed • Understand the content of domains • Get insight into design decisions • Understand CDASH team recommendations 2

General Remarks • CDASH: A set of ‘content standards’ • Initial scope: 16 core safety domains • The term “CRF” used throughout this document refers to both paper and electronic formats, unless otherwise specified • Not CRF layouts • “Fields” refers to fields that are commonly seen on the CRF. • “Variables” refers to what is seen in a clinical database. • “Study treatment” has been used in order to include all types of study designs and products. • Different data collection mechanisms can be used to control how data are collected, e. g. , tick boxes, check boxes, radio buttons, drop -down lists, etc. These terms will be used interchangeably. 3

Contents Sections 1 to 4 • Section 1: Orientation – purpose and goals of the CDASH project as well as – organization of CDASH Standard Version 1. 0. • Section 2: CDASH Alignment with Other Standards – relationship of CDASH Standard Version 1. 0 to the Study Data Tabulation Model Implementation Guide (SDTMIG), controlled terminology and other non-CDISC standards. • Section 3: Best Practice Recommendations – for creating data collection instruments – Frequently Asked Questions (FAQs) section • Section 4: Overview of CDASH Domain Tables – – new ideas and approaches recommended by the CDASH Domain Teams data collection fields noted not necessary to collect core designations used throughout CDASH Standard Version 1. 0 explains the table headers used in the domain tables. 4

Contents Section 5: CDASH Domain Tables • Approach taken regarding common identifier and timing variables • Metadata tables and/or recommendations for the following domains: - Adverse Events (AE) - Comments (CO) - Prior and Conc. Med. (CM) - Demographics (DM) - Disposition (DS) - Drug Accountability (DA) - ECG Test Results (EG) - Exposure (EX) - Inclusion and Exclusion Criteria (IE) - Laboratory Test Results (LB) - Medical History (MH) - Physical Examination (PE) - Protocol Deviations (DV) - Subject Characteristics (SC) - Substance Use (SU) - Vital Signs (VS) 5

Contents Sections 6 and 7 • Section 6: Change Control and the Process for Creating New CDASH Domains – describes the procedure for change control and maintenance of CDASH Standard Version 1. 0 as well as the – procedure for creating new CDASH domains. • Section 7: Appendices – provides additional background material regarding the CDASH project as well as – references and supplemental information relevant to implementation of CDASH Standard Version 1. 0 6

Core Designations for Basic Data Collection Fields • Highly Recommended: A data collection field that should be on the CRF (e. g. , a regulatory requirement). • Recommended/Conditional: A data collection field that should be collected on the CRF for specific cases or to address TA requirements (may be recorded elsewhere in the CRF or from other data collection sources). • Optional: A data collection field that is available for use if needed. 7

Explanation of Table Headers 1. Data Collection Field: Basic data to be collected. 2. Variable Name: Lists the SDTM-based variable name defined in the SDTMIG. (CDASH variable name shaded) 3. Definition: Describes the purpose of the data collection field. Reference to the code list will be provided, in the format {code list name} 4. Case Report Form Completion Instructions: how to enter collected information on the CRF. 5. Additional Information for Sponsors: Contains further information 6. CDASH Core: Contains the CDASH core designations 8

Example Question or data being collected 9

Example EDC or database variable name Unshaded = SDTM name Shaded = CDASH specific 10

Example Purpose of the field May or may not mirror the text in the SDTMIG CRF text examples are presented in italics 11

Example Reference to the code list: {code list name} 12

Example Suggested instructions to give to the sites for completing the CRF These will vary depending upon the protocol 13

Example More information that explains the field, helps with implementation or clarifies intent Not only for sponsors but for anyone who is using the standard 14

Example Degree of ‘required-ness’ - Highly recommended - Recommended / Conditional - Optional 15

Core Domains • Common Identifier Variables • Exposure (EX) • Common Timing Variables • Inclusion and Exclusion Criteria (IE) • Adverse Events (AE) • Laboratory Test Results (LB) • Comments (CO) • Medical History (MH) • Prior and Conc. Med. (CM) • Physical Examination (PE) • Demographics (DM) • Protocol Deviations (DV) • Disposition (DS) • Vital signs (VS) • Drug Accountability (DA) • Subject Characteristics (SC) • ECG Test Results (EG) • Substance Use (SU) 16

Domain Review: AE • Where any AEs experienced? • Serious Event • Line # • Serious Event Type • Adverse Events Text • Relationship to Study Treatment • Start Date / Start Time • Action Taken with Study Treatment • End Date / End Time • Other Action Taken • Ongoing • Outcome • Severity • Adverse Event that Caused Study Discontinuation 17

Domain Review: AE • Where any AEs experienced? • Serious Event • Line # • Serious Event Type • Adverse Events Text • Relationship to Study Treatment • Start Date / Start Time • Action Taken with Study Treatment intent/purpose is to help with Action Taken • End Date The / End Time • Other • • • data cleaning and monitoring. It provides Ongoingverification that all other fields • Outcome on the CRF were deliberately left blank. Disposition (DS) • Adverse Event that Caused Study Note: AEYN will not be included as part of Discontinuation Severity the SDTMIG AE Domain for submission. 18

Domain Review: AE • Where any AEs experienced? • Serious Event • Line # • Serious Event Type • Adverse Events Text • Relationship to Study Treatment • Start Date / Start Time • Action Taken with Study Treatment Sponsor-defined • End Date / End Time • Other Action Taken • • • reference number. Ongoing Perhaps pre-printed on • Outcome the CRF as an explicit Disposition (DS) • Adverse Event that Caused Study line identifier or defined Discontinuation in the sponsor’s Severity operational database (derived) 19

Domain Review: AE • Where any AEs experienced? • Serious Event • Line # • Serious Event Type • Adverse Events Text • Relationship to Study Treatment • Start Date / Start Time • Action Taken with Study Treatment • End Date / End Time date. Action of data collection in • The Other Taken • Ongoing • Disposition (DS) • Severity conjunction with End Date and • the Outcome Ongoing CDASH fields determine how the • would Adverse Event that Caused Study SDTMIG variable AEENRF will Discontinuation be populated. 20

Domain Review: AE • Where any AEs experienced? • Serious Event • Line # • Serious Event Type • Adverse Events Text • Relationship to Study Treatment • Action Taken with Study Treatment • Other Action Taken • Outcome • Adverse Event that Caused Study Discontinuation If the details regarding a Serious • Start Time AE need Date to be /collected in the clinical it is • End database, Date / Endthen Time recommended that a separate • Ongoing Yes/No variable be defined for each Serious AE type, e. g. : • Disposition (DS) Congenital Anomaly or Birth Defect Initial or Prolonged Hospitalization • Life Severity Threatening Death 21

Domain Review: AE • Where any AEs experienced? • Serious Event • Line # • Serious Event Type CDISC controlled • Adverse Events terminology should be. Text used • Relationship to Study Treatment to indicate the action taken • the Start Date / Start Time with study treatment in response the AE. • Endto. Date / End Time Other Action: Free text field. • Ongoing Example: Treatment Unblinded, Primary Care • Disposition (DS) Physician Notified. • Severity • Action Taken with Study Treatment • Other Action Taken • Outcome • Adverse Event that Caused Study Discontinuation 22

Domain Review: Comment Just say no ICH E 3 & E 6: no requirement that indicate unsolicited comments should be included in a submission dataset. Recommendation: only the parameters captured in appropriate CRF data collection fields are considered clinical study data that is submitted to regulatory parties in datasets; all other comments are considered unsolicited comments. 23

Domain Review: Prior & Conc. Med. • Where any medications taken? • Unit • Line # • Dose Form • Medication Name • Frequency • Active Ingredient(s) • Route • Indication • Start Date / Start Time • AE Line # • Mark if taken prior to study • MH Line # • End Date • Dose • Mark if Ongoing • Total Daily Dose 24

Domain Review: Prior & Conc. Med. • Where any medications taken? • Line # • Medication Name • Active Ingredient(s) • Indication • AE Line # • MH Line # • Dose • Unit Intent is to establish • a link Dose Form the adverse between event / medical history condition and • the. Frequency medication taken for the adverse event. • Route May result in unnecessary data • Start Date / Start Time cleaning work. • will Mark priorintothe study Note: not ifbetaken included SDTMIG CMDate domain in • End submissions. • Mark if Ongoing • Total Daily Dose 25

Domain Review: Prior & Conc. Med. • Where any medications taken? • Unit • Line # • Dose Form • Medication Name • Frequency • Active Ingredient(s) • Route • Indication • Start Date / Start Time • AE Line # • Mark if taken prior to study • MH Line # • End Date • Dose • Mark if Ongoing • Total Daily Dose 26

Domain Review: Prior & Conc. Med. • Where any medications taken? • Unit • Line # • Dose Form • Medication Name • Frequency • Active Ingredient(s) • Route • Indication • Start Date / Start Time • AE Line # • Mark if taken prior to study • MH Line # • End Date • Dose • Mark if Ongoing • Total Daily Dose 27

Domain Review: Prior & Conc. Med. • Where any medications taken? • Unit • Line # • Dose Form • Medication Name • Frequency • Active Ingredient(s) • Route • Indication • Start Date / Start Time • AE Line # • Mark if taken prior to study • MH Line # • End Date • Dose • Mark if Ongoing • Total Daily Dose 28

Domain Review: Demographics • Date of Birth (and time) • Age – Year of Birth • Age Units – Month of Birth • Today’s date – Day of Birth • Sex • Ethnicity • Race – Time of Birth 29

Domain Review: Demographics • Date of Birth (and time) – Year of Birth – Month of Birth – Day of Birth – Time of Birth • Age Subjects in countries where • Age Units privacy rules preclude the collection of personal containing • data Today’s date more detail than the year of birth might only provide date of birth • data Sexto the year level. Note: It is recommended that the CRF should be modified for sites in these • Ethnicity counties to prevent the clinician from entering the data that would violate the • Race privacy rule (i. e. , gray out the month and day fields on paper or make them inaccessible for entry in an EDC system). 30

Domain Review: Disposition • Trial Epoch • Will the subject continue? • Subject Status • Next trial epoch or new trial subject will be entering • Date of Completion or Discontinuation • Time of Completion or Discontinuation • Was treatment unblinded by the site 31

Domain Review: Disposition. • Trial Epoch • Subject Status • Date of Completion or Discontinuation • Time of Completion or Discontinuation • Was treatment unblinded by the site Subject Status data • Will the subject continue? collection field should be presented on CRF asepoch a check linked • the Next trial orbox new trial to an item from will the approved controlled subject be entering terminology list (DSDECOD). 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. 32

Domain Review: Drug Accountability • Date Study Treatment Dispensed • Study Treatment Dispensed or Returned • Date Study Treatment Returned • Study Treatment Category • Study Treatment Subcategory • Results of Study Treatment Dispensed or Returned • Units of Study Treatment Dispensed or Returned 33

Domain Review: ECG • Scenario 1: Central reading • Scenario 2: Local reading • Scenario 3: Significance Central reading with Clinical Assessment and/or Overall Interpretation 34

Domain Review: ECG (Central Reading) • Indicate if ECG was performed • ECG Reference ID • Method of ECG • Position of the Subject • Date of ECG • Planned Time Point • Time of ECG 35

Domain Review: ECG (Local Reading) • Indicate if ECG was performed • Method of ECG • Position of the Subject • Date of ECG • Planned Time Point • Time of ECG • Test Name • Test Result • Units • Clinical Significance 36

Domain Review: ECG Central processing but CRF includes site assessment of clinical significance and/or overall interpretation • Indicate if ECG was performed • Time of ECG • ECG Reference ID • Test Name • Method of ECG • Test Result • Position of the Subject • Units • Date of ECG • Clinical Significance • Planned Time Point 37

Domain Review: Exposure • • • Start Date / Start Time End Date / End Time Dose Amount Dose Unit Study Treatment Identification Number Study Treatment Name Dose Adjusted? Reason for Dose Adjustment Frequency Route Formulation • • • Duration of Optional Interruption (including units) Body Location Total Volume Administered Unit Flow Rate Unit Planned Time Point Did subject complete full course of study med Planned Dose Units 38

Domain Review: Inclusion/Exclusion • Met All Eligibility Criteria? • Criterion Identifier * • Criterion • Inclusion or Exclusion? * This variable is only populated in SDTM for those criteria that are not met, and it will only be recorded on the CRF for those criteria that are not met. 39

Domain Review: Lab Test Results • Scenario 1: Central processing • Scenario 2: Local processing • Scenario 3: Central processing with Clinical Significance Assessment for abnormal values 40

Domain Review: LB – Central • Lab Status • Date of Collection • Time of Collection • Panel Name • Planned Time Point • Protocol-defined testing conditions met • Accession Number 41

Domain Review: LB – Local Processing • Lab Status • Units • Date of Collection • Reference Range Lower Limit Numeric Value • Reference Range Upper Limit Numeric Value • Reference Range for Character Results in Standard Units • Abnormal Flag • Clinical Significance • Lab Name • Accession Number • Time of Collection • Panel Name • Planned Time Point • Protocol-defined testing conditions met • Sample Status • Test Name • Test Result 42

Domain Review: LB – Central Processing & CRF with Site Assessment • • • Lab Status Date of Collection Time of Collection Panel Name Planned Time Point Protocol-defined testing conditions met Sample Status Test Name Test Result Clinical Significance Accession Number 43

Domain Review: Medical History • Has the subject experienced any past and / or concomitant diseases or past surgeries? • Pre-printed row number • Ongoing? • Disease controlled? • Pre-printed prompt for a specific condition/surgery (e. g. , Does the subject have high blood pressure? ) • Onset Date • End Date • Completion Date (e. g. , 1, 2, 3) • Type of Medical History being collected • Category of Medical History being collected • Reported Term 44

Domain Review: Physical Examination • Traditional: Use PE form at baseline and post-baseline visits. Record abnormalities for each listed body system. • Intermediate: Use PE form at baseline but not post-baseline visits. Record any post-baseline abnormalities or conditions that worsened post baseline on the AE page. • Best Practice: Use PE CRF only to record whether PE was performed, and if so, the date of the examination. Record any baseline abnormalities on Medical History CRF and any post-baseline abnormalities or conditions that worsened post baseline on the AE page. 45

Domain Review: Physical Examination Traditional Approach • Was the Physical Examination Performed? • Date of Examination • Time of Examination • Sponsor-Defined Identifier • Body System Examined • Examination Result • Abnormal Findings • Clinical Significance • Evaluator 46

Domain Review: Physical Examination Best Practice Approach • Was the Physical Examination Performed? • Date of Examination • Time of Examination • Sponsor-Defined Identifier • Body System Examined • Examination Result • Abnormal Findings • Clinical Significance • Evaluator 47

Domain Review: Protocol Deviations Generally form is discouraged • Were there any protocol deviations? • Protocol Deviation Term (text) and or Protocol Deviation Coded Term • Start Date • Start Time • End Date • End Time • Sponsor-Defined Identifier 48

Domain Review: Subject Characteristics • Subject Characteristic Question • Subject Characteristic Answer/Result • Examples of Subject Characteristics Questions – – Gestational Age at Birth Childbearing Potential Education Sub-study Participation 49

Domain Review: Substance Use • Type of substance used? • Substance use? • Category of substance used • Amount • Unit • Frequency • Start Date • End Date • Duration • Unit for Duration 50

Domain Review: Vital Signs • Date of Measurements • Time of Vital Sign Measurements • Sponsor-Defined Identifier • Planned Time Point • Vital Sign Test Name • Vitals Status • Vital Sign Test Result or Finding • Original Units • Clinical Significance • Location of Vital Signs Measurement • Position of Subject 51

Recommendations for CDASH Domains • Comments: Avoid the creation of a General Comments CRF to collect unsolicited comments. Solicited comments linked to specific data collection fields is the recommended approach. • Inclusion/Exclusion Criteria: Use the IE form to collect only the criterion or criteria NOT MET. • Physical Examination: Record only whether or not an exam was done on the PE form. Clinical sites are asked to record baseline abnormalities on a Medical History, Targeted Medical History or Baseline Conditions CRF. Post baseline abnormalities or baseline conditions that worsened during the clinical study are to be recorded on the Adverse Event CRF. • Protocol Deviations: Avoid creating a Protocol Deviations CRF if this information can be derived from other domains or system functionalities 52

Answers to FAQs on Best Practices • “Yes/No” questions should be preferred over “Check all that apply” questions • Standard order for “Yes/No” response • unambiguous date format DD-MMM-YYYY • 24 -hour clock using the HH: MM: SS format • Manually-calculated fields should not typically be recorded • Data that are collected on CRFs should usually be databased • “Yes/No” exam completed is preferred over “Check if not done” • Data should not be pre-populated in the CRF • CDASH recommends not providing actual coding dictionaries to the site for adverse events, concomitant medications or medical history reported terms, as this may bias responses. 53

Best Practice Recommendations • • Necessary data only Control Adequate review Site workflow Employ standards Clarity Translations CRF completion guidelines 54

55

Challenges • There are many ways to implement CDASH domains • There are still some unresolved issues • There are pieces missing • It requires giving up favorite practice • Change is hard, especially across departments • Requires learning about parts of clinical studies that are “not our job” 56

Practical Implementation in an EDC System • CDASH domain specs need to be transferred to EDC e. CRF specs • CDASH is not necessarily conducive to a database design – For example: • VS domain has one variable for “test Result” – this needs to cover all tests, e. g. height, weight, etc – where different database variables are needed • Necessitates creation of (non-CDASH) database variables which can be mapped to SDTM • Some CDASH domains can be collected once or many times/study – This means more than one e. CRF standard may be needed for each CDASH domain 57

CDASH and SDTM Terminology • Answers to CDASH questions need to comply with SDTM terminology – Need to define which code lists will be applied to which questions – Some SDTM terminology code lists are huge, e. g. “units” which covers all potential units for all potential tests – An efficient data entry system requires a concise list of potential terms per variable – Necessitates some customisation of the SDTM terminology list to divide into question specific lists – In turn, this means a stringent cross check of further SDTM terminology developments is required to ensure updates are implemented 58

Questions? 59