elke sennewald berlin, 28 september 2010

60
Elke Sennewald Berlin, 28 September 2010 CDASH Tutorial

Upload: keren

Post on 25-Feb-2016

53 views

Category:

Documents


0 download

DESCRIPTION

CDASH Tutorial. Elke Sennewald Berlin, 28 September 2010. Learning Objectives. Learn more about CDASH V1.0 Identify the domains addressed Understand the content of domains Get insight into design decisions Understand CDASH team recommendations. General Remarks. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Elke Sennewald Berlin,  28 September 2010

Elke SennewaldBerlin, 28 September 2010

CDASH Tutorial

Page 2: Elke Sennewald Berlin,  28 September 2010

2

Learning Objectives

• Learn more about CDASH V1.0• Identify the domains addressed• Understand the content of domains• Get insight into design decisions• Understand CDASH team recommendations

Page 3: Elke Sennewald Berlin,  28 September 2010

3

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.

Page 4: Elke Sennewald Berlin,  28 September 2010

4

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.

Page 5: Elke Sennewald Berlin,  28 September 2010

5

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) - Inclusion and Exclusion Criteria (IE)

- Comments (CO) - Laboratory Test Results (LB)- Prior and Conc. Med. (CM) - Medical History (MH)- Demographics (DM) - Physical Examination (PE)- Disposition (DS) - Protocol Deviations (DV)- Drug Accountability (DA) - Subject Characteristics (SC)- ECG Test Results (EG) - Substance Use (SU)- Exposure (EX) - Vital Signs (VS)

Page 6: Elke Sennewald Berlin,  28 September 2010

6

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

Page 7: Elke Sennewald Berlin,  28 September 2010

7

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.

Page 8: Elke Sennewald Berlin,  28 September 2010

8

1 2 3 4 5 6

Data Collection Field

Variable Name(CDASH variable

name shaded)

Definition Case Report Form

Completion Instructions

Additional Information for

Sponsors

CDASH Core

CDASH Delivers ContentNOT CRF Layout

Basic data to be collected..

SDTM-IG based variable name

(CDASH)(Variable name

shaded)

Describes the purpose of the data collection

field

CRF Completion Instructions

for Sites

How to implement the CRF

data collection variable

CDASH Core

Designations

Page 9: Elke Sennewald Berlin,  28 September 2010

9

Example

Question or data being collected

Page 10: Elke Sennewald Berlin,  28 September 2010

10

Example

EDC or database variable name

Unshaded = SDTM name

Shaded = CDASH specific

Page 11: Elke Sennewald Berlin,  28 September 2010

11

Example

Purpose of the field

May or may not mirror the text in the SDTMIG

CRF text examples are presented in italics

Page 12: Elke Sennewald Berlin,  28 September 2010

12

Example

Reference to the code list:{code list name}

Page 13: Elke Sennewald Berlin,  28 September 2010

13

Example

Suggested instructions to give to the sites for completing the CRF

These will vary depending upon the protocol

Page 14: Elke Sennewald Berlin,  28 September 2010

14

ExampleMore information that explains the field, helps with implementation or clarifies intent

Not only for sponsors but for anyone who is using the standard

Page 15: Elke Sennewald Berlin,  28 September 2010

15

Example

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

Page 16: Elke Sennewald Berlin,  28 September 2010

16

Core Domains

• Common Identifier Variables• Common Timing Variables• 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)• Vital signs (VS)• Subject Characteristics (SC)• Substance Use (SU)

Page 17: Elke Sennewald Berlin,  28 September 2010

17

Domain Review: AE

• Where any AEs experienced?• Line #• Adverse Events Text • Start Date / Start Time • End Date / End Time• Ongoing• Severity

• Serious Event • Serious Event Type• Relationship to Study Treatment• Action Taken with Study

Treatment• Other Action Taken• Outcome• Adverse Event that Caused Study

Discontinuation

Page 18: Elke Sennewald Berlin,  28 September 2010

18

Domain Review: AE

• Where any AEs experienced?• Line #• Adverse Events Text • Start Date / Start Time • End Date / End Time• Ongoing• Disposition (DS) • Severity

• Serious Event • Serious Event Type• Relationship to Study Treatment• Action Taken with Study

Treatment• Other Action Taken• Outcome• Adverse Event that Caused Study

Discontinuation

The intent/purpose is to help withdata cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.Note: AEYN will not be included as part of the SDTMIG AE Domain for submission.

Page 19: Elke Sennewald Berlin,  28 September 2010

19

Domain Review: AE

• Where any AEs experienced?• Line #• Adverse Events Text • Start Date / Start Time • End Date / End Time• Ongoing• Disposition (DS) • Severity

• Serious Event • Serious Event Type• Relationship to Study Treatment• Action Taken with Study

Treatment• Other Action Taken• Outcome• Adverse Event that Caused Study

Discontinuation

Sponsor-defined reference number. Perhaps pre-printed on the CRF as an explicit line identifier or defined in the sponsor’soperational database (derived)

Page 20: Elke Sennewald Berlin,  28 September 2010

20

Domain Review: AE

• Where any AEs experienced?• Line #• Adverse Events Text • Start Date / Start Time • End Date / End Time• Ongoing• Disposition (DS) • Severity

• Serious Event • Serious Event Type• Relationship to Study Treatment• Action Taken with Study

Treatment• Other Action Taken• Outcome• Adverse Event that Caused Study

Discontinuation

The date of data collection in conjunction with End Date and the Ongoing CDASH fields would determine how the SDTMIG variable AEENRF will be populated.

Page 21: Elke Sennewald Berlin,  28 September 2010

21

Domain Review: AE

• Where any AEs experienced?• Line #• Adverse Events Text • Start Date / Start Time • End Date / End Time• Ongoing• Disposition (DS) • Severity

• Serious Event • Serious Event Type• 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 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, e.g.:Congenital Anomaly or Birth DefectInitial or Prolonged Hospitalization Life Threatening Death

Page 22: Elke Sennewald Berlin,  28 September 2010

22

Domain Review: AE

• Where any AEs experienced?• Line #• Adverse Events Text • Start Date / Start Time • End Date / End Time• Ongoing• Disposition (DS) • Severity

• Serious Event • Serious Event Type• Relationship to Study Treatment• Action Taken with Study

Treatment• Other Action Taken• Outcome• Adverse Event that Caused Study

Discontinuation

CDISC controlled terminology should be used to indicate the action taken with the study treatment in response to the AE.Other Action: Free text field. Example: Treatment Unblinded, Primary Care Physician Notified.

Page 23: Elke Sennewald Berlin,  28 September 2010

23

Domain Review: Comment

Just say no

ICH E3 & E6: 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.

Page 24: Elke Sennewald Berlin,  28 September 2010

24

Domain Review: Prior & Conc. Med.

• Where any medications taken?• Line #• Medication Name• Active Ingredient(s) • Indication• AE Line #• MH Line #• Dose• Total Daily Dose

• Unit • Dose Form• Frequency• Route• Start Date / Start Time• Mark if taken prior to study• End Date• Mark if Ongoing

Page 25: Elke Sennewald Berlin,  28 September 2010

25

Domain Review: Prior & Conc. Med.

• Where any medications taken?• Line #• Medication Name• Active Ingredient(s) • Indication• AE Line #• MH Line #• Dose• Total Daily Dose

• Unit • Dose Form• Frequency• Route• Start Date / Start Time• Mark if taken prior to study• End Date• Mark if Ongoing

Intent is to establish a link between the adverse event / medical history condition and the medication taken for the adverse event.May result in unnecessary data cleaning work.

Note: will not be included in the SDTMIG CM domain in submissions.

Page 26: Elke Sennewald Berlin,  28 September 2010

26

Domain Review: Prior & Conc. Med.

• Where any medications taken?• Line #• Medication Name• Active Ingredient(s) • Indication• AE Line #• MH Line #• Dose• Total Daily Dose

• Unit • Dose Form• Frequency• Route• Start Date / Start Time• Mark if taken prior to study• End Date• Mark if Ongoing

Page 27: Elke Sennewald Berlin,  28 September 2010

27

Domain Review: Prior & Conc. Med.

• Where any medications taken?• Line #• Medication Name• Active Ingredient(s) • Indication• AE Line #• MH Line #• Dose• Total Daily Dose

• Unit • Dose Form• Frequency• Route• Start Date / Start Time• Mark if taken prior to study• End Date• Mark if Ongoing

Page 28: Elke Sennewald Berlin,  28 September 2010

28

Domain Review: Prior & Conc. Med.

• Where any medications taken?• Line #• Medication Name• Active Ingredient(s) • Indication• AE Line #• MH Line #• Dose• Total Daily Dose

• Unit • Dose Form• Frequency• Route• Start Date / Start Time• Mark if taken prior to study• End Date• Mark if Ongoing

Page 29: Elke Sennewald Berlin,  28 September 2010

29

Domain Review: Demographics

• Date of Birth (and time)– Year of Birth– Month of Birth– Day of Birth – Time of Birth

• Age • Age Units• Today’s date• Sex• Ethnicity• Race

Page 30: Elke Sennewald Berlin,  28 September 2010

30

Domain Review: Demographics

• Date of Birth (and time)– Year of Birth– Month of Birth– Day of Birth – Time of Birth

• Age • Age Units• Today’s date• Sex• Ethnicity• Race

Subjects in countries where privacy rules preclude the collection of personal data containing more detail than the year of birth might only provide date of birth data to the year level. Note: It is recommended that the CRF should be modified for sites in these counties to prevent the clinician from entering the data that would violate the privacy rule (i.e., gray out the month and day fields on paper or make them inaccessible for entry in an EDC system).

Page 31: Elke Sennewald Berlin,  28 September 2010

31

Domain Review: Disposition

• Trial Epoch• Subject Status• Date of Completion or

Discontinuation• Time of Completion or

Discontinuation• Was treatment unblinded

by the site

• Will the subject continue?• Next trial epoch or new trial

subject will be entering

Page 32: Elke Sennewald Berlin,  28 September 2010

32

Domain Review: Disposition

• Trial Epoch• Subject Status• Date of Completion or

Discontinuation• Time of Completion or

Discontinuation• Was treatment unblinded

by the site

• Will the subject continue?• Next trial epoch or new trial

subject will be entering

. 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). 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.

Page 33: Elke Sennewald Berlin,  28 September 2010

33

Domain Review: Drug Accountability

• Date Study Treatment Dispensed

• Study Treatment Dispensed or Returned

• Results of Study Treatment Dispensed or Returned

• Units of Study Treatment Dispensed or Returned

• Date Study Treatment Returned• Study Treatment Category• Study Treatment Subcategory

Page 34: Elke Sennewald Berlin,  28 September 2010

34

Domain Review: ECG

• Scenario 1: Central reading • Scenario 2: Local reading• Scenario 3: Central reading with Clinical Significance

Assessment and/or Overall Interpretation

Page 35: Elke Sennewald Berlin,  28 September 2010

35

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

Page 36: Elke Sennewald Berlin,  28 September 2010

36

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

Page 37: Elke Sennewald Berlin,  28 September 2010

37

Domain Review: ECGCentral processing but CRF includes site assessment of clinical significance and/or overall interpretation

• Indicate if ECG was performed• ECG Reference ID• Method of ECG• Position of the Subject• Date of ECG• Planned Time Point

• Time of ECG• Test Name• Test Result• Units• Clinical Significance

Page 38: Elke Sennewald Berlin,  28 September 2010

38

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• Total Volume Administered Unit• Flow Rate• Flow Rate Unit• Planned Time Point• Did subject complete full course of

study med• Planned Dose• Planned Dose Units

Page 39: Elke Sennewald Berlin,  28 September 2010

39

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.

Page 40: Elke Sennewald Berlin,  28 September 2010

40

Domain Review: Lab Test Results

• Scenario 1: Central processing • Scenario 2: Local processing • Scenario 3: Central processing with Clinical

Significance Assessment for abnormal values

Page 41: Elke Sennewald Berlin,  28 September 2010

41

Domain Review: LB – Central

• Lab Status• Date of Collection• Time of Collection• Panel Name• Planned Time Point• Protocol-defined testing conditions met• Accession Number

Page 42: Elke Sennewald Berlin,  28 September 2010

42

Domain Review: LB – Local Processing

• Lab Status• Date of Collection• Time of Collection• Panel Name• Planned Time Point• Protocol-defined testing

conditions met• Sample Status• Test Name• Test Result

• Units• 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

Page 43: Elke Sennewald Berlin,  28 September 2010

43

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

Page 44: Elke Sennewald Berlin,  28 September 2010

44

Domain Review: Medical History

• Has the subject experienced any past and / or concomitant diseases or past surgeries?

• Pre-printed row number (e.g., 1, 2, 3)

• Type of Medical History being collected

• Category of Medical History being collected

• Reported Term

• 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

Page 45: Elke Sennewald Berlin,  28 September 2010

45

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.

Page 46: Elke Sennewald Berlin,  28 September 2010

46

Domain Review: Physical ExaminationTraditional 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

Page 47: Elke Sennewald Berlin,  28 September 2010

47

Domain Review: Physical ExaminationBest 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

Page 48: Elke Sennewald Berlin,  28 September 2010

48

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

Page 49: Elke Sennewald Berlin,  28 September 2010

49

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

Page 50: Elke Sennewald Berlin,  28 September 2010

50

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

Page 51: Elke Sennewald Berlin,  28 September 2010

51

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

Page 52: Elke Sennewald Berlin,  28 September 2010

52

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

Page 53: Elke Sennewald Berlin,  28 September 2010

53

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.

Page 54: Elke Sennewald Berlin,  28 September 2010

54

Best Practice Recommendations

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

Page 55: Elke Sennewald Berlin,  28 September 2010

55

Page 56: Elke Sennewald Berlin,  28 September 2010

56

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”

Page 57: Elke Sennewald Berlin,  28 September 2010

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

Page 58: Elke Sennewald Berlin,  28 September 2010

58

CDASH-ODM Initiative: Started May 2008• Participating Companies

– InterMune, Formedix, Quintiles, Shire, Schwartz Pharma, Outcome, AstraZeneca, eLilly, Medidata, ERT, XClinical, IPL, Octagon Solutions, CDISC, Cerner, Greenway, PRA Intl., GSK, Forrest Laboratories, Genzyme - ODM/Core

• Initial Scope: CDASH DOMAINS– AE, Prior & Concomitant Meds, Demography, Common

Identifiers.• Initial Deliverables: March 2009

– Metadata tables – CRF representations – CRF with database annotations and CDASH alias– ODM files

Page 59: Elke Sennewald Berlin,  28 September 2010

59

A CDASH-ODM Form Contains:

<ODM><Study>

<Meta…</Meta…

</Study></ODM>

CDASH - ODM Form

CDASH ContentClinical Context

Study Data Tabulation Model

Submission

TerminologyCodelists

PresentationExtended ODM

Operational Data ModelDatabase Content

and Structure

Best Practice Modelling

Structure

Page 60: Elke Sennewald Berlin,  28 September 2010

60

Questions?