Transcript CDASH Tutorial - Digital Infuzion, Inc.

CDASH Tutorial
Elke Sennewald
Berlin, 19 February 2009
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
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 DateThe
/ 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
dateAction
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
If the details regarding a Serious
•AE Start
Start Time
need Date
to be /collected
in the
clinical
it is
• End database,
Date / Endthen
Time
recommended that a separate
•Yes/No
Ongoing
variable be defined for
each Serious AE type, e.g.:
•
Action Taken with Study Treatment
•
Other Action Taken
•
Outcome
•
Adverse Event that Caused Study
Discontinuation
•Congenital
Disposition
(DS)
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
beText
used
• Relationship to Study Treatment
to indicate the action taken
• the
Start
Date
/ Start Time
with
study
treatment
in
response
the AE.
• EndtoDate
/ 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 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.
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•theFrequency
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: Central reading with Clinical Significance
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
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
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 eCRF 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 eCRF 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