CDASH Serious Adverse Event Supplement
Version 1
Prepared by the
CDASH – E2B Project Team
CDASH Serious Adverse Event Supplement v1
Notes to Readers
•
•
This document corresponds to the SDTM v1.3 and SDTMIG v3.1.3 but incorporates new domains
developed after v3.1.3 was released.
This document also corresponds to the CDASH Standards v1.1
Revision History
Date
2013-11-22
2013-04-18
Version
1.0
1.0 draft
Summary of Changes
Final
Draft for Public Review
See Appendix G for Representations and Warranties, Limitations of Liability, and Disclaimers
Page 2
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
CONTENTS
1
OVERVIEW OF DOCUMENT ......................................................................................... 5
1.1
INTRODUCTION ...................................................................................................................................................5
1.2
SCOPE/PURPOSE ..................................................................................................................................................5
1.3
ORGANIZATION OF THIS DOCUMENT ...................................................................................................................8
1.4
DATA PRIVACY LAWS ..........................................................................................................................................9
1.5
CDISC CONTROLLED TERMINOLOGY .................................................................................................................9
1.6
ALIGNMENT WITH OTHER STANDARDS ...............................................................................................................9
1.6.1
The Study Data Tabulation Model .............................................................................................................9
1.6.2
CDASH v1.1 ..............................................................................................................................................9
1.6.3
E2B Plus ..................................................................................................................................................10
1.7
EXPLANATION OF TABLE HEADERS...................................................................................................................10
2
SERIOUS ADVERSE EVENT TABLES – SAE............................................................. 12
2.1
SAE REPORT ADMINISTRATIVE AND IDENTIFIER VARIABLES (E2B A) .............................................................12
2.2
PATIENT CHARACTERISTICS (E2B B.1) .............................................................................................................13
2.2.1
Subject Characteristics – (CDASH SC) ...................................................................................................14
2.2.2
Demographics – (CDASH DM) ...............................................................................................................15
2.2.3
Medical History – (CDASH MH) ............................................................................................................16
2.2.4
Vital Signs – (CDASH VS) ......................................................................................................................17
2.2.5
Reproductive System Findings - (SDTMIG RP - DRAFT V3.1.4)..........................................................18
2.2.6
Past Drug History – (CDASH CM) .........................................................................................................18
2.2.7
Death Details – (SDTMIG DD - DRAFT V3.1.4) ...................................................................................20
2.2.8
Parent-Child/Fetus Report and its Relationship to CDISC Associated Persons Domains .......................21
2.3
SAE EVENT/REACTION (E2B B.2) ....................................................................................................................21
2.4
INVESTIGATIONS AND RESULTS (E2B B.3) ........................................................................................................27
2.4.1
Information from Existing CRFs .............................................................................................................27
2.4.2
Laboratory Findings – (CDASH LB) .......................................................................................................29
2.5
DRUG INFORMATION (E2B B.4) ........................................................................................................................31
2.5.1
Information from Existing CRFs .............................................................................................................31
2.5.2
Drug Information – (CDASH EX), (CDASH CM) and Other Variables Associated with Suspect Drug 31
2.6
NARRATIVE .......................................................................................................................................................38
3
REGULATORY REFERENCES ..................................................................................... 39
3.1
INTRODUCTION .................................................................................................................................................39
3.1.1
Notices .....................................................................................................................................................39
3.1.2
Scope........................................................................................................................................................39
3.1.3
Key ...........................................................................................................................................................39
3.1.4
Sources .....................................................................................................................................................40
APPENDICES ............................................................................................................................. 44
APPENDIX A: GLOSSARY, ACRONYMS, AND DEFINITIONS ............................................................................................44
APPENDIX B: PROJECT HISTORY/BACKGROUND ...........................................................................................................47
APPENDIX C: DATA ELEMENTS FROM ICH E2B R2 ......................................................................................................48
APPENDIX D: EXAMPLES OF STUDY SCENARIOS WHERE PARENT-CHILD DATA COULD BE SUBMITTED ........................50
APPENDIX E: NARRATIVE .............................................................................................................................................51
APPENDIX F: AUTHORS ................................................................................................................................................53
APPENDIX G: REPRESENTATIONS AND WARRANTIES, LIMITATIONS OF LIABILITY, AND DISCLAIMERS .........................54
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 3
November 25, 2013
CDASH Serious Adverse Event Supplement v1
LIST OF FIGURES
Figure 1: Types of Adverse Events................................................................................................................................6
Figure 2: Levels of Event Reporting and Responsibilities ............................................................................................6
Figure 3: SAE Flow Diagram ........................................................................................................................................7
Figure 4: E2B Structure for SAE Content .....................................................................................................................8
Page 4
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
1 Overview of Document
1.1 Introduction
Clinical Data Acquisition Standards Harmonization (CDASH) is the standard applied to clinical data at point of
capture (http://www.cdisc.org/cdash). CDASH contains an Adverse Event domain intended for capture of adverse
event information (the AE CRF) in the Clinical Data Management System (CDMS).
The CDASH Serious Adverse Event (CDASH SAE) Supplement to CDASH version 1.1 expands the current
Adverse Event (AE) domain to include data elements for the capture of serious adverse event information in an SAE
Form and, when indicated, will also allow the sponsor to generate an E2B message for electronic reporting of an
Individual Case Safety Report (ICSR) to Health Authorities. The content of an ICSR is specified by the International
Conference on Harmonization (ICH) in the Guideline on Clinical Safety Data Management: Data Elements for
Transmission of Individual Case Safety Reports (E2B R2). Although E2B R3 is now published, it is not
implemented in the ICH regions at the time of publication of this supplement. Therefore the CDASH SAE
Supplement is based on E2B R2. In the next version of the CDASH SAE Supplement, E2B R3 changes will be
incorporated. See Appendix B for additional information for the Project History/Background.
The purpose of the CDASH SAE Supplement is to facilitate the collection of information that is comprehensive and
relevant to the understanding of the SAE that will allow for an assessment for causality. This SAE supplement
ensures that the safety reports sent from the site to the sponsor will support all required fields needed to generate an
ICH E2B-compliant SAE report, which is a regulatory requirement in many countries, without re-entry of data
already collected in other areas of the EDC System or missing data necessary to the E2B data fields. The tables
provided in this document (also known as metadata tables) in section 3 illustrate the mapping of the CDASH data
variable names to the E2B data elements. This document, on its own, should not be seen as a guide to ICH E2B R2
and does not specify the exact E2B data format.
This first version of the CDASH SAE Supplement is focused on the ICH E2B (R2) specification and focuses on
adverse reaction (AR) reporting for drugs only. Other therapies, devices, biologics, and vaccines will be addressed
in future versions of this supplement.
1.2 Scope/Purpose
Clinical investigative sites typically collect data on all AEs during a clinical trial, but only a smaller subset will meet
the criteria of an SAE. Of those SAEs received by the sponsor, a still smaller subset will meet the regulatory
requirements for expedited reporting to the regulatory authorities. These usually are the SAEs that are both
unexpected and suspected, also known as Serious Unexpected Suspected Adverse Reactions (SUSARs).
See Figure 1.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 5
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Figure 1: Types of Adverse Events
AE
SAE
SUSAR
Safety data, unlike most other data collected for clinical trials, can directly impact the well-being of subjects. Thus,
certain designated safety data must be reported expeditiously in real time by the site to the sponsor, monitoring and
regulatory personnel in accordance with protocol and regulatory timeframes. For any given trial, the protocol will
specify the extent of safety data to be collected. An adverse event will be collected and termed an AE unless it meets
the regulatory or protocol-specified definition of a Serious Adverse Event (SAE) or an Adverse Event of Special
Interest (AESI). SAEs and AESIs are then subject to expedited reporting. In general, AEs are collected on a CRF,
while SAEs/AESIs are collected on a specialized long form (which can be called an SAE form).
Figure 2 below, visually depicts the scope of this CDASH SAE Supplement, which is focused on the SAE Form.
The SAE Form is the data collection instrument for sites to record the SAE and is designed such that the sponsor
will also have the necessary information to report SUSARS to Health Authorities. The existing CDASH AE domain
is expanded to include data elements to support a comprehensive SAE Form. The Drug Safety Department of the
sponsor can then use this information to create the E2B message for reporting an Individual Case Safety Report
(ICSR) to Health Authorities. The purpose of this project is to ensure that all safety data (whether it pertains to an
AE, SAE, or SUSAR) will employ the same data standard, and that this data standard is consistent with other
CDISC data standards, and is also consistent with E2B specifications.
Figure 2: Levels of Event Reporting and Responsibilities
Page 6
November 25, 2013
Safety Data
Category
Data Collection &
Reporting Tool
Submission and
Receipt
Responsibility
AE
CRF
(CDASH)
Site
SAE
SAE Form
(CDASH SAE
Addendum)
Site to Sponsor
SUSAR
E2B
Message/ICSR
(E2B R2)
Sponsor to
Authority
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Independent of company-specific automated processes with data management and safety data collection, in
general, when an adverse event has occurred, the information is captured on a Case Report Form (the AE CRF).
When the AE is deemed to have met any of the SAE criteria or criteria for AESIs, the SAE form is then completed
to collect additional data not already collected. Data that were already collected for the study but are needed for a
safety report would now be available to populate the SAE form, minimizing duplicative data entry. All of the data
for SAEs are destined for a sponsor safety database, distinct from the study clinical database. Examples of data
already collected in existing CDASH domains (stored in the clinical research database) and useful for typical safety
case supporting information include demographics, medical history and concomitant medications. Such existing data
would be available to populate the sponsor safety database (which stores SAE information), and can be used to
generate safety reports as needed. See Figure 3.
Figure 3: SAE Flow Diagram
*Data not collected in the study CRFs but deemed relevant for safety reporting would need to be
collected as part of the SAE form. It is up to the implementers to determine which and how data is
collected.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 7
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Finally, the content of the SAE Form is based on the requirements set forth by ICH E2B R2. Companies can design
their own SAE Form using the CDASH standard and this supplement as guidance for the CDASH SAE variable
names. The intent is that at a minimum, the information provided by sites would be adequate for the sponsor to
submit an ICSR or E2B message to Health Authorities. The ICSR or E2B message structure includes the subsections shown in Figure 4.
Figure 4: E2B Structure for SAE Content
This E2B structure is used to organize the content of the SAE Form and Section 2 of the CDASH SAE Supplement.
The A and B Sections are divided into sub-header Sections A1-A3, and B1-B5, each of which has further sub-levels
to allow for the many specific E2B data elements. These specific E2B data elements are mapped to the CDASH
variables (see the metadata tables provided in Section 2). For illustrative purposes, Appendix C includes a partial
listing of the E2B data elements in A1-A3 and B1-B5. For a full listing of the E2B data elements, please refer to the
ICH E2B R2 document listed in the Reference section at the end of this supplement.
1.3 Organization of this Document
This document is meant to fulfill the needs of both the clinical data management and the drug safety communities.
To this end, the SAE data in Section 2 of this document is organized to follow the E2B R2 guidance structured order
rather than the CDASH or SDTMIG document structure.
This document has been organized into the following sections:
• Section 1, Introduction, provides an overall introduction to the scope and purpose of the CDASH E2B
project;
o Section 1.2, Scope/Purpose, provides the scope and purpose of the CDASH Serious Adverse
Event Supplement;
o Section 1.3, Organization of this Document, describes the organization of the CDASH Serious
Adverse Event Supplement.
o Section 1.4, Data Privacy Laws, provides information regarding the applicability of data privacy
laws.
o Section 1.5, CDISC Controlled Terminology, provides information regarding CDISC controlled
terminology used within the Serious Adverse Event Supplement;
o Section 1.6, Alignment with Other Standards, describes the relationship of the Serious Adverse
Event Supplement to the Study Data Tabulation Model (SDTM), to the CDASH Standard Version
1.1, and to the ICH E2B Specification.
o Section 1.7, Explanation of Table Headers, describes approaches that reflect common practice
implemented by a significant number of organizations/companies, defines the core designations
used throughout CDASH v1.1 and explains the table headers used in the domain tables.
Page 8
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
•
•
•
Section 2, Serious Adverse Event Tables, contains metadata tables and/or recommendations for the SAE
data.
Section 3, Regulatory References, provides a list of relevant regulatory guidelines and requirements that
should be consulted for instructions on the collection, organization and submission of AE and SAE
information to regulatory authorities.
Appendices provide additional background material and describe other supplemental material relevant to
the document
1.4 Data Privacy Laws
The demographic and subject identification data elements listed in this document are based on global guidelines for
the collection of safety data. However, some of these data elements might be considered personal data and therefore
should not be collected in cases where prohibited by local data privacy laws. Since these laws differ from country to
county and are subject to change, sponsors are strongly encouraged to review the applicable data privacy laws in the
country/countries in which they are planning to conduct clinical trials. We have marked these fields as
Recommended/Conditional (R/C) to allow for adherence to local law.
1.5 CDISC Controlled Terminology
Terminology applicable to CDASH data collection fields is either in production or under development by the
CDISC Terminology Team. Production terminology is published by the National Cancer Institute’s Enterprise
Vocabulary Services (NCI EVS) and can be accessed via the following link:
http://www.cancer.gov/cancertopics/terminologyresources/CDISC.
CDISC Controlled Terminology is updated quarterly. Because this document is a static publication, it refers readers
to the NCI EVS page for CDISC terminology (at the link given above). For the same reason, this document cannot
claim to use controlled terminology in the examples provided; users should not refer to these as the ultimate
authority on what terms to use or to not use.
In cases where a CDASH field has associated controlled terminology, the codelist is referenced in the Controlled
Terminology column in the domain tables in this format: {codelist name}.
1.6 Alignment with Other Standards
1.6.1 The Study Data Tabulation Model
The full set of SAE data is generally not destined for the clinical database and thus not subject to inclusion in SDTM
submissions. Note also that there is an expectation that safety data are maintained in “real time” (subject to change
as more information becomes available).
For information on preparing collected data for submissions, refer to the Study Data Tabulation Model
Implementation Guide (SDTMIG).
1.6.2 CDASH v1.1
A working knowledge of the CDASH standard is critical when using this document. CDASH v1.1 identifies the
basic data collection fields needed from a clinical, scientific and regulatory perspective to enable more efficient and
consistent data collection at the investigative sites. The SDTMIG and CDASH are related. The SDTM and the
SDTMIG provide a standard for the submission of data. CDASH is earlier in the data flow and defines a basic set of
highly recommended and recommended/conditional data collection fields that are expected to be present on the
majority of CRFs. The CDASH data collection fields (or variables) facilitate mapping to the SDTM domains. When
the data are identical between the two standards, the SDTMIG variable names are presented in the CDASH domain
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 9
November 25, 2013
CDASH Serious Adverse Event Supplement v1
tables. In cases where the data are not identical or do not exist in the SDTMIG, CDASH has suggested new variable
names, where applicable.
The CDASH v1.1 Standard defines many of the basic safety data collection fields found in E2B. This CDASH SAE
Supplement contains additional variables to complement existing variables in CDASH. We have intentionally not
reproduced the entire CDASH standard but have included existing CDASH variables that map to safety reporting
data elements, where appropriate. These CDASH variables are shaded in the metadata tables. Additional data fields
may need to be added to address study-specific and therapeutic-area requirements, and applicable regulatory and
business practices. Since a number of the CDASH v1.1 variables are optional, an assessment should be made for
each variable regarding inclusion on the CRF or inclusion exclusively in an E2B safety report.
1.6.3 E2B Plus
E2B Plus, or extended E2B, refers to custom XML fields (tags) that capture supplementary data above and beyond
the ICH E2B specification.
The number and type of E2B Plus tags used varies from sponsor to sponsor and depends on many factors (e.g., study
phase, therapeutic area and business need). However, there are some common E2B Plus tags such as the subject's
ethnicity and the subject's hospitalization date.
E2B Plus leverages the wealth of data that is normally available during a clinical trial for a more effective safety
review. For this extra data to be processed electronically by a safety system, that system itself must be able to
support E2B Plus.
The CDASH SAE Supplement focuses on the ICH E2B (R2) specification and hence includes no reference to E2B
Plus. Sponsors who will use the forthcoming safety CDASH Forms should modify the forms where
appropriate to capture the desired extra data to be processed as E2B Plus tags.
1.7 Explanation of Table Headers
1
2
3
Question Prompt E2B
Text
Variable
Name
1.
2.
3.
4.
5.
4
5
E2B
Variable
Data
Name
Element
6
7
8
9
BRIDG Definition Controlled
SAE Form
Terminology Completion
Instructions
10
11
Implementation Core
Instructions
Question Text: Contains the full question text for the data collection field. Question text may be used as the
label on the CRF or may be used in help text for the field.
Prompt: Contains the short prompt or label for the data collection field.
E2B Variable Name: This column provides the E2B variable names (e.g., parentmedicalcontinue).
E2B Data Element: This column contains the reference number to the applicable section of the ICH M2 EWG
Electronic Transmission of Individual Case Safety Reports Message Specification (ICH ICSR DTD Version
2.1) Final Version 2.3 Document Revision February 1, 2001.
Variable Name: This column provides the SDTM, CDASH and CDASH SAE variable names (e.g., AESPID,
AEONGO, SAERPTRNM). See the table below for more details.
Page 10
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Standard
SDTM
CDASH
CDASH
SAE
Description
Variables that are collected in the CRF as they are
reported in the SDTM. These variable names are
limited to an 8-character length in the SDTM.
Fields typically collected on CRFs that exist in the
CDASH standard. These variable names are “SDTMlike variables”, limited to 8-characters in length and
can help facilitate the derivation of SDTM IG
variables needed for submission.
Fields included on a specialized SAE form to
supplement data already collected on CRF forms.
These are only for SAE reporting, are not necessarily
included in an SDTM submission and are therefore
not limited to the 8-character length limitation.
Identification
Identified by the lack
of shading or borders
Example
AESPID
Identified by grey
shading.
AEONGO
Identified by a
surrounding text box
(border) not shaded. SAERPTRNM
6.
BRIDG: This column contains the initial BRIDG Release 3.2 mappings. This information is included to
provide an initial idea of how the CDASH variable maps to BRIDG. Some of the new variables will need to go
through the formal BRIDG harmonization process. See the BRIDG Mapping Spreadsheet – CDASH tab or the
BRIDG model at www.bridgmodel.org for the complete mapping path.
7. Definition: This column defines the data to be collected for the variable. Definitions have been obtained and
harmonized from CDASH, SDTM and E2B.
8. Controlled Terminology: In cases where a CDASH field has associated controlled terminology, the codelist is
referenced in this format: {CODELIST NAME}.
9. SAE Form Completion Instructions (for clinical site): Contains information for the clinical site on how to
enter collected information on the CRF.
10. Implementation Instructions: Contains further details, such as rationale and implementation instructions, for
the CRF data collection fields. This information is meant to guide implementers (i.e. Case Report Form
Designers, Data Managers, Drug Safety, etc.).
11. Core (designations): Contains the CDASH Core designations for basic data collection fields. In order to
facilitate classification of the different types of data collection fields, the following categories were used:
•
•
•
Highly Recommended (HR): A data collection field that should be on the CRF (e.g., a regulatory
requirement).
Recommended/Conditional (R/C): A data collection field that should be on a CRF based on certain
conditions (e.g., complete date of birth is preferred, but may not be allowed in some regions; AE time
should only be captured if there is another data point with which to compare it). In the absence of this data
point other data points would be less meaningful.
Optional (O): A data collection field that is available for use.
It is assumed that sponsors will determine which data collection fields will be collected based on therapeutic areaspecific data requirements, protocol and local legal regulatory considerations. Some data that have been previously
collected may or may not be the same data as needed in the E2B message; it is up to the sponsor to confirm that
these data are accurate and appropriate for use in an E2B message. For example, the country where the Adverse
Event occurred may/may not be the same as country of the investigational site recorded in CDASH. Additionally,
information already collected on CRFs may not be accurate at the time that the AE occurred (e.g., the date of last
menstrual period, medical history, concomitant medications).
We have intentionally not reproduced the entire CDASH standard but have included existing CDASH variables that
map to safety reporting data elements, where appropriate. These CDASH variables are shaded in the metadata
tables.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 11
November 25, 2013
CDASH Serious Adverse Event Supplement v1
2 Serious Adverse Event Tables – SAE
The Adverse Event domain in CDASH is intended to capture data for all adverse events whether serious, not serious, or of special interest. The expanded Serious
Adverse Event metadata tables combine previously collected data with additional details needed for a full understanding and assessment of the event and for
processing in drug safety departments of sponsors.
All of the SAE metadata tables in Section 2 are structured for use in conjunction with the basic adverse event data collection fields described in the Adverse
Event domain in CDASH v1.1 when an event has reached the status of requiring expedited reporting to the sponsor/regulatory authority. The mappings to an
E2B message within this table are only relevant when the adverse event reaches the threshold defined for reporting to regulatory authorities.
It is important to note that certain entries in this domain do not need to be or might not be completed by sites as indicated in the SAE Form Completion and/or
Implementation Instructions. However, they are included as a reminder of the sponsor’s responsibility for information to be provided to regulatory authorities.
2.1 SAE Report Administrative and Identifier Variables (E2B A)
The variables included in the table below have been developed specifically for the collection of data for the identification, processing and reporting of an SAE.
This table contains fields for data collection at the site, such as information on the location of the site, the location of the occurrence of the AE, study identifier,
SAE identifier, and reporter identifiers (the reporter is the primary source of the information). Note certain data fields are included that contain information that
are to be provided by the sponsor and not the investigative sites.
Question Text
Prompt
Country of the
primary source
Country where
the event
occurred
E2B Variable E2B Data
Variable Names
Name
Element
primarysourcec
A.1.1
SRCCNTY
ountry
1
Where are you located?
2
Where did the primary
event for the safety case
occur?
3
Do you wish to mark this Nullification
safety case as nullified? status
casenullificatio
A.1.13
n
NULYN
4
Why are you nullifying
the safety case?
Reason for
nullification
nullificationreas
A.1.13.1
on
NULREAS
5
What is the report date?
Report date
What is the first name of
the reporter?
What is the last name of
the reporter?
What is the sponsor study
Reporter first
name
Reporter last
name
Sponsor study
6
7
8
Page 12
November 25, 2013
occurcountry
receivedate
receiptdate
reportergivena
me
reporterfamily
name
sponsorstudynu
A.1.2
OCCCNTY
BRIDG
Definition
Organization.post Identification of the country of
alAddress
the primary source
Controlled
Terminology
{COUNTRY}
Organization.post Country where the event
{COUNTRY}
alAddress
occurred, if different from above
SafetyReportVersi
on.nullificationInd Report nullification
icator*
SafetyReportVersi
on.nullificationRe Reason for nullification
asonCode*
PerformedActivity
Date of this transmission
.dateRange*
{NY}
Not applicable
A.1.6b
A.1.7b
TRANSDAT
A.2.1.1b
SAERPTRGNM
Person.name
Reporter’s given name.
Not applicable
A.2.1.1d
SAERPTRFSNM
Person.name
Reporter’s surname name.
Not applicable
A.2.3.2
STUDYID
DocumentIdentifi Study number
Not applicable
Not applicable
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question Text
number?
What is the individual
9
SAE ID number?
What is the SAE report
10
version?
Prompt
number
SAEID
Report version
E2B Variable
Name
mb
E2B Data
Element
Not
Not applicable
applicable
Not
Not applicable
applicable
Variable Names
SAEID
SAERVER
Question
SAE Form Completion Instructions
May not be completed by site.
1 (cont)
If completed by site, enter the country where you are located.
2 (cont) Enter the country where the event occurred.
3 (cont) Select if you are nullifying the safety case.
4 (cont) Provide reason for nullification.
BRIDG
Definition
er. identifier*
DocumentIdentifi
Not applicable
er.identifier*
DocumentVersion
Version of the SAE report
.numberText
Controlled
Terminology
Not applicable
Not applicable
Implementation Instructions
Generally a derived value linked to site address.
This maps to the 3-digit country code from ISO 3166
This maps to the 3-digit country code from ISO 3166
Do not record if not nullified.
Record as 1=Yes if nullification.
Do not request this info if case not nullified.
Ensure full dates are always provided.
If the value is captured in the CDASH format, it should be reformatted into
the E2B message format (CCYYMMDD).
5 (cont) Not completed by site.
6 (cont) Enter the reporter’s first name.
7 (cont) Enter the reporter’s last name.
This section should be completed only if the sender is the study sponsor or has
8 (cont)
been informed of the study number by the sponsor.
If not system-generated, record unique identifier for serious adverse event for
9 (cont) this subject.
Core
HR
R/C
R/C
R/C
O
The CDASH variable maps to two different E2B variables, the sponsor's
safety department will determine the correct variable depending if the report
is initial or follow-up.
This field is needed on the SAE form that is submitted to drug safety.
This field is needed on the SAE form that is submitted to drug safety.
Unique identifier for a study.
This is typically pre-printed/pre-populated.
This field holds the local SAE number.
In an electronic system numbers are auto-generated. For paper safety forms
these are managed by a different process (may be pre-printed)
If this is a new SAE, the SAE report version is termed Initial or New. If there is
Value should be selected from list stating whether report is initial/new or
10 (cont) additional information to be provided, the SAE report version is termed Followfollow-up
Up.
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
HR
HR
HR
O
O
2.2 Patient Characteristics (E2B B.1)
In keeping with CDASH nomenclature, trial participants are referred to throughout this document as subjects (including patients and healthy volunteers). In E2B
nomenclature, variable names using the term patient have already been defined by ICH and are reproduced here. Thus, in this document, patient and subject are
used interchangeably to refer to clinical trial participants.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 13
November 25, 2013
CDASH Serious Adverse Event Supplement v1
2.2.1 Subject Characteristics – (CDASH SC)
Question Text
What are the
subject’s initials?
What is the General
Practitioner
2 medical record
number of the
subject?
What is the
3 subject’s specialist
record number?
What is the hospital
4 record number of
the subject?
1
Prompt
E2B Variable Name
Subject initials patientinitial
E2B Section
B.1
Variable Names
SAESUBJINI
BRIDG
PerformedObservation
Subject Initials
Result.value*
Not applicable
GP medical
patientgpmedicalrecor
B.1.1.1a
record number dnumb
SAEGPRECID
PerformedObservation GP medical record
Result.value*
number of subject
Not applicable
Subject’s
patientspecialistrecor
B.1.1.1b
specialist
dnumb
record number
SAEMSRECID
PerformedObservation Subject's Specialist
record number
Result.value*
Not applicable
Hospital
patienthospitalrecordn
B.1.1.1c
record number umb
SAEHORECID
PerformedObservation Hospital record
Result.value*
number of subject
Not applicable
SUBJID
Subject Identification
number is an
Identifier assigned to
each trial subject to
StudySubjectIdentifier protect the subject’s
Not applicable
identity, and used
.identifier
instead of the subject’s
name when the
Investigator reports
trial data.
What is the
5 subject’s identifier? Subject
patientinvestigationnu
B.1.1.1d
mb
Question SAE Form Completion Instructions
Implementation Instructions
May be collected where permitted under privacy rules
1 (cont) Record the subject’s initials.
Record numbers can include the health professional record(s) number(s), hospital record(s)
Record the GP medical number of the
number(s), or patient/subject identification number in a study. The source of the number should be
2 (cont)
subject
specified to ensure the possibility of retrieval when possible and desirable.
Record the Subject’s Specialist record
Not applicable
3 (cont)
number.
Record the hospital record number of
Not applicable
4 (cont)
the subject
Paper: This is typically recorded in the header of each CRF page.
EDC: The subject identifiers may be provided to the site using a pre-populated list in the system.
5 (cont) Record the subject’s identifier
SUBJID = Subject identifier, which must be unique within the study. Often the ID of the subject as
recorded on a CRF.
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
Page 14
November 25, 2013
Controlled
Terminology
Definition
Core
O
O
O
O
HR
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
2.2.2 Demographics – (CDASH DM)
Question Text
What is the subject’s
date of birth?
Prompt
E2B Section
patientbirthdate
B.1.2.1b
What is the subject age
Subject onset
patientonsetage
2 at the onset of the
age
serious adverse event?
B.1.2.2b
1
Birth date
E2B Variable Name
What is the subject age
Subject onset
patientonsetageunit
3 unit at the onset of the
age unit
serious adverse event?
What is the sex of the
Sex
patientsex
4
subject?
Question
B.1.2.2b
B.1.5
Prompt
SAE Form Completion Instructions
Record the date of birth to the level of
precision known (e.g., day/month/year, year,
Subject’s
month/year, etc.) in this format (DD-MON1 (cont)
date of birth
YYYY).
Subject
onset age
Subject
3 (cont) onset age
unit
2 (cont)
Variable Names
BRIDG
Definition
{BRTHDAT | BRTHYR
Subject: Date of
[BRTHMO] [BRTHDY]} BiologicEntity.birthDate*
Birth
[BRTHTIM]
Subject age at time
Derived from date of
of onset of
SAEAGE
interest minus
reaction/event
BiologicEntity.birthdate
(numeric)
Derived from date of
Unit for subject age
SAEAGEU
interest minus
at time of onset of
BiologicEntity.birthdate reaction/event
BiologicEntity.administra
SEX
Subject Sex
tiveGenderCode*
Controlled
Terminology
Not applicable
Not Applicable
Not applicable
{SEX}
Implementation Instructions
Core
A subject’s date of birth (with or without the time of birth). The complete Date of Birth is made from
the temporal components of Birth Year, Birth Month, Birth Day and Birth Time.
HR
This field does not map directly to an SDTM variable.
For formatting purposes, field value: CCYYMMDD
Enter the subject’s age at onset of the serious
adverse event.
This field is needed to complete the SAE form that is submitted to drug safety.
This field is not intended to be part of the regulatory file submission.
R/C
Enter the subject’s age unit at onset of the
serious adverse event.
This field is needed to complete the SAE form that is submitted to drug safety.
This field is not intended to be part of the regulatory file submission.
R/C
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.
4 (cont) Subject sex Record the appropriate sex
Phenotypic assessment is the self-reported sex of the individual and/or is the clinician’s assignment
based on a physical examination. This is not to be confused with a genotypic determination of a
subjects' chromosomally determined gender, but a less scientifically controlled method of visual
determination that HL7 has defined as “administrative sex.”
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
HR
Page 15
November 25, 2013
CDASH Serious Adverse Event Supplement v1
2.2.3 Medical History – (CDASH MH)
Question Text
What is the verbatim
term for the medical
1
history condition
/event?
What was the date the
2 medical history event
or condition started?
Prompt
E2B Variable
Name
E2B
Section
Variable Names
BRIDG
Definition
Medical
History
Term
patientepisode
B.1.7.1a.2 MHTERM
name
Subject relevant medical history and
PerformedMedicalCon
concurrent conditions: Disease / surgical
ditionResult.value*
procedure / etc.
Start Date
patientmedica
B.1.7.1c
lstartdate
PerformedMedicalHist Subject relevant medical history and
oryResult.occurrence* concurrent conditions: Start date
MHSTDAT
Subject relevant medical history and
concurrent conditions:
Medical history/concurrent conditions
Continuing? (field value: 1=Yes 2=No
3=Unknown)
Controlled
Terminology
Not Applicable
Not Applicable
Is the medical history
Ongoing
disease
3
/condition or event still
ongoing?
patientmedica
B.1.7.1d
lcontinue
MHONGO
Implementation
specific
What was the date the
4 medical history event End Date
or condition ended?
patientmedica
B.1.7.1f
lenddate
MHENDAT
PerformedMedicalHist
Subject relevant medical history and
oryResult.occurrenceD
concurrent conditions: End date
ateRange*
patientmedica
B.1.7.1g
lcomment
COVAL1…COVAL5
RDOMAIN="MH"
Not Applicable
PerformedObservation Subject relevant medical history and
IDVAR="MHSEQ"
Result.comment
concurrent conditions: comment (free text)
SAE domain - med history
Comments
Are there any other
relevant details or
5
information about the
medical history?
Question
Prompt
Medical
History
Comment
{NY}
Not Applicable
SAE Form Completion Instructions
Implementation Instructions
Record all relevant past and/or concomitant medical conditions
and past surgeries, as defined in the protocol. Record only one
Medical History condition or surgery per line. When recording a condition and
Verbatim or pre-printed CRF term for the medical condition or event.
1 (cont)
Event Term
surgery related to that condition, use one line for the condition and
one line for the surgery. Ensure that any of the conditions listed on
the Medical History page do not meet any of the exclusion criteria.
The sponsor may choose to capture a complete date or any variation thereof
Record the start date using this format (DD-MON-YYYY).
2 (cont) Start Date
(e.g., month and year or year, etc.).
This field will be completed to indicate that the condition has not resolved at
the point of data collection. It is expected that every reported condition should
have either an End Date or the Ongoing field marked “yes” (or checked), but
not both.
Ongoing
The purpose of collecting this field is to help with data cleaning and
Select the most appropriate response.
3 (cont)
monitoring, since this field provides further confirmation that the End Date
was deliberately left blank.
As described in Section 3.4.1, Best Practices, this is a special use case of
“Yes/No” where the question is usually presented as a single possible
response of “Yes” in conjunction with an end date. In this case, if the box is
Page 16
November 25, 2013
Core
HR
O
O
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question
Prompt
SAE Form Completion Instructions
Implementation Instructions
Core
checked, the field will contain “Yes” and if it is blank and there is an end date
present, it can be mapped to “No”.’ If MHONGO = 'Y'; then set MHENRTPT
to 'ONGOING' and MHENTPT should be defined by the sponsor with
consistent value such as Informed Consent.
The date of data collection in conjunction with a collected time point anchor
Date and the MHONGO CDASH fields would determine how the SDTMIG
variables would be populated. Reference Section 2.1.3 for more information.
This field does not map directly to an SDTM variable.
The sponsor may choose to capture a complete date or any variation thereof
Record the end date using this format (DD-MON-YYYY).
O
4 (cont) End Date
(month & year or year, etc.).
Medical History
SAE domain - The text of the medical history comments. Text over 200
Record any additional details to the medical history.
O
5 (cont)
Comment
characters can be added to additional columns COVAL1-COVALn.
*See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
2.2.4 Vital Signs – (CDASH VS)
Question Text
Prompt
E2B Variable Name
E2B Section
1
What is the subject’s
Subject weight patientweight
weight?
B.1.3
2
What is the subject’s
Subject height patientheight
height?
B.1.4
Variable Names
VSORRES [VSORRESU]
when
VSTEST="Weight"
VSORRES [VSORRESU]
when
VSTEST="Height"
BRIDG
Controlled
Terminology
Definition
PerformedObservation
Subject Weight in kg
Result.value*
Not Applicable
at the time of the SAE
PerformedObservation
Subject Height in cm
Result.value*
Not Applicable
at the time of the SAE
Question
Prompt
SAE Form Completion Instructions
Implementation Instructions
Core
1 (cont) Subject weight Enter the subject’s weight in kg at the time of the SAE. It is recommended that the units be pre-printed on the CRF when possible. HR
2 (cont) Subject height Enter the subject’s height in cm at the time of the SAE. It is recommended that the units be pre-printed on the CRF when possible. HR
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 17
November 25, 2013
CDASH Serious Adverse Event Supplement v1
2.2.5 Reproductive System Findings - (SDTMIG RP - DRAFT V3.1.4)
Note that the Reproductive System Findings domain is currently under development by the CDISC Submission Data Standards Development Team and therefore
not included in CDASH v1.1. Once these constructs are approved, this CDASH SAE Supplement will be revised accordingly. As dictated by the study and the
protocol, the SAE Form can be designed to include additional data fields to provide relevant obstetric and gynecologic information, or such relevant information
may be pulled from a reproductive system CRF, if available.
Question Text
1
Date of last
Menstrual Period?
Prompt
E2B Variable Name
Last Menstrual patientlast
Period
menstrualdate
E2B Section
Variable Names
Definition
PerformedMedicalCon
Subject’s last
ditionalResult.occuranc
menstrual date.
eDateRange*
SAELMDAT
B.1.6.b
BRIDG
Controlled
Terminology
Not Applicable
Question
Prompt
SAE Form Completion Instructions
Implementation Instructions
Core
Last Menstrual
Enter the date of first day of the subject’s last menstrual period prior to The date of first day of the subject’s last menstrual period prior to the
R/C
1 (cont)
Period
the adverse event.
adverse event.
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
2.2.6 Past Drug History – (CDASH CM)
This section provides a means to capture information pertaining to drugs previously taken. It is not intended for information about current drug exposure to
suspect drug or concomitant medications (See Section 2.5.2). Medical judgment should be exercised regarding relevance and inclusion of this section.
Question Text
1
2
3
4
5
6
What was the term for the
medication/ therapy taken?
or
What was the term for the
medication taken?
What was the start date and
time of the medication
/therapy?
What was the start time of
the medication /therapy?
What was the end date of
the medication/therapy?
What was the end time of
the medication/therapy?
Prompt
Medication
or
Therapy
patientdrugnam
B.1.8
e
Variable Names
BRIDG
Definition
Verbatim drug name or therapy
(include only therapies with data
collection characteristics similar
medications).
CMTRT
MaterialName.name*
Start Date and patientdrugstart
B.1.8c
Start Time
date
CMSTDAT
PerformedSubstanceAdm Date and time when the medication
inistration.dateRange*
was first taken.
patientdrugstart
B.1.8c
date
patientdrugend
B.1.8e
date
patientdrugend
B.1.8e
date
CMSTTIM
PerformedSubstanceAdm
inistration.dateRange*
PerformedSubstanceAdm
inistration.dateRange*
PerformedSubstanceAdm
inistration.dateRange*
Start Time
End Date
End Time
For what indication was the
Indication
medication/therapy taken?
Page 18
November 25, 2013
E2B Variable
E2B
Name
Section
CMENDAT
CMENTIM
patientdrugindi
B.1.8f.2 CMINDC
cation
Time when the medication was first
taken.
Date that the subject stopped taking
the medication or therapy.
Time that the subject stopped taking
the medication or therapy.
The reason for administration of a
PerformedSubstanceAdm
concomitant (non-study) medication.
inistration.reasonCode*
(e.g., Nausea, Hypertension)
Controlled
Terminology
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Variable
E2B
Name
Section
Variable Names
BRIDG
Controlled
Terminology
Definition
This is not the pharmacological/
therapeutic classification of an agent
(e.g., antibiotic, analgesic, etc.), but
the reason for its administration to the
subject.
Question
Prompt
Medication
1 (cont) or
Therapy
SAE Form Completion Instructions
Record only one medication per line.
Provide the full trade or proprietary name of the drug or therapy;
otherwise the generic name may be recorded.
Record the date and time the medication or therapy was first taken
using this format (DD-MON-YYYY).
If the subject has been taking the medication for a considerable
Start Date and amount of time prior to the start of the study, it is acceptable to
2 (cont)
Start Time
have an incomplete date. Medications taken during the study are
expected to have a complete start date.
Prior medications that are exclusionary should have both a start
and end date
Implementation Instructions
Core
In most cases, the verbatim drug names or therapy will be coded to a standard
dictionary such as WHO Drug Dictionary after the data have been collected on HR
the CRF.
The preferred method is to collect a complete start date. Partial dates (e.g.,
providing year only) for medications started a considerable amount of time
prior to the start of study are acceptable.
HR
Recommend collecting the time a medication was started when a protocol or
data collection scenarios supports it. Typically, a start time is not collected
Record time the medication or therapy was first taken if available.
R/C
3 (cont) Start Time
unless the subject is under the direct care of the site at the time a medication or
therapy is administered.
The assumption is that sponsors should either have a complete end date or will
Record the date the subject stopped taking the medication or
indicate that the medication or therapy was ongoing at the time of collection or
therapy using this format (DD-MON-YYYY).
at the end of the study.
R/C
4 (cont) End Date
If the subject has not stopped taking the medication leave this
Recommend collecting the time a medication or therapy was ended when a
field blank.
protocol or data collection scenarios supports it.
Record the time the subject stopped taking the medication or
Recommend collecting the time a medication or therapy was ended when a
therapy using this format (DD-MON-YYYY).
protocol or data collection scenarios supports it.
R/C
5 (cont) End Time
If the subject has not stopped taking the medication leave this
Typically, an end time is not collected unless the subject is under the direct care
field blank.
of the site at the time a medication or therapy is stopped.
Record the reason the medication was taken based on clinical
investigator’s evaluation.
This information can be used as deemed appropriate for coding, analysis (i.e., in
If taken to treat a condition, and a diagnosis was made, the
the classification of medications), for reconciling the medications taken by a
R/C
indication should be the diagnosis.
6 (cont) Indication
subject with their provided medical history and/or AEs/SAEs as part of the data
If taken to treat a condition, and no diagnosis was made, the
clean-up and monitoring process, etc.
indication should be the signs and symptoms.
If taken as prophylaxis, report as “Prophylaxis for…”
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 19
November 25, 2013
CDASH Serious Adverse Event Supplement v1
2.2.7 Death Details – (SDTMIG DD - DRAFT V3.1.4)
This section corresponds with E2B R2 B1.9 and is completed by the site or point of data collection. The Death Details domain is currently under development by
the CDISC Submission Data Standards Development Team and therefore not included in CDASH v1.1. Once these constructs are approved, this CDASH SAE
Supplement will be revised accordingly.
Implementers are reminded that CDISC Controlled Terminology is updated quarterly. Because this document is a static publication, it refers readers to the NCI
EVS page for CDISC terminology. For the same reason, this document cannot claim to use controlled terminology in the examples provided; users should not
refer to these as the ultimate authority on what terms to use or to not use.
Rows 2-5 are proposed variables not included in CDASH or the SDTMIG.
Question Text
What is the date of the
subject’s death?
What was the reported
2
primary cause of death?
What was the reported
3
secondary cause of death?
1
Prompt
E2B Variable Name
E2B Data
Element
Subject death
patientdeathdate
date
Primary cause
patientdeathreport
of death
Secondary
patientdeathreport
cause of death
B.1.9.1b
DSSTDAT
B.1.9.2b
PRCDTH
B.1.9.2b
SECDTH
Autopsy
performed
B.1.9.3
AUPERF
4
Was an autopsy
performed?
5
Autopsy
What was the autopsy
determined
patientdetermineautopsy B.1.9.4b
determined cause of death?
cause of death
Question
Prompt
Variable Names
patientautopsyyesno
AUCDTH
BRIDG
BiologicEntity.d
eathDate*
PerformedClinic
alResult.value*
PerformedClinic
alResult.value*
Derived from
DefinedActivity.
name*
Definition
In the case of death: date of
patient death.
In case of death: Reported
cause(s) of death.
In case of death: Reported
cause(s) of death.
In case of death: Was autopsy
done?
PerformedClinic In case of death: AutopsyalResult.value* determined cause(s) of death.
Controlled
Terminology
Not Applicable
Not Applicable
Not Applicable
{NY}
Not Applicable
SAE Form Completion Instructions
Implementation Instructions
Record the date the subject died using this format (DD- Date of death for any subject who died, in ISO 8601 format. Should represent the
1 (cont) Subject death date
MON-YYYY). A complete date is expected.
date that is captured in the clinical study database.
Should be populated even when the death date is unknown.
Primary cause of
Record the reported primary cause of the subject’s
The initially reported cause of death might be different than the autopsy-determined
2 (cont)
death
death.
cause. For this reason these variables might contain the same or different values.
If more than one secondary cause of death is collected the sponsor might need to
Secondary cause of Record the reported secondary cause of the subject’s
repeat this field using different variable names for each repeat; however, this will be
3 (cont)
death
death.
system-dependent.
Indicate if an autopsy was performed on the subject. If Autopsy is a procedure from which there will usually be findings. Autopsy
4 (cont) Autopsy performed yes, include the appropriate details where indicated on information should be handled as per recommendations in the Procedures domain.
the CRF.
Autopsy determined
The initially reported cause of death might be different than the autopsy-determined
Record the cause of death determined by the autopsy.
5 (cont)
cause of death
cause. For this reason these variables might contain the same or different values.
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
Page 20
November 25, 2013
Core
HR
HR
O
HR
R/C
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
2.2.8 Parent-Child/Fetus Report and its Relationship to CDISC Associated Persons Domains
This section corresponds to E2B R2 B1.10 and should be used in the case of a parent-child/fetus report where the parent had no reaction/event. Refer to the E2B
R2 document for the relevant data elements.
Parent-child pairing information is needed if only the child/fetus has an adverse reaction/event (other than early spontaneous abortion/fetal demise). The
characteristics concerning the parent who was the source of exposure to the drug should be provided in this section. Note that in the circumstance where both the
parent and the child/fetus sustain adverse events, two reports are expected: one for the AE on the parent, and one for the AE on the child/fetus; these two separate
reports should be linked.
Parent-child pairing information is not needed if there has been no reaction/event affecting the child/fetus (unplanned exposure is not captured as adverse
event). Note that in the circumstance of fetal demise or early spontaneous abortion, only a parent report is applicable to detail the AE in the fetus.
See Appendix D for table providing study scenarios where parent-child data could be submitted.
Associated Persons domains are currently under development by the CDISC Submission Data Standards Development Team. The Associated Person models in
the SDTMIG will include methods for creating domains of data collected about people who are not subjects in the trial (such as the child of a subject). These data
will be placed in domains that parallel the existing SDTMIG domains and might include the domains of Demographics, Medical History, Adverse Events,
Concomitant Medications, Exposure and other domains of data. The mother's (or parent's) data for a parent-infant/child report are covered in the SDTMIG or
CDASH domains when the mother or parent is the subject of the trial. The combination subject domains and Associated Persons domains will provide the
appropriate variables to map to the E2B parent-infant/child report's variables; these mappings will be incorporated into future versions of the CDASH SAE
Supplement. In cases where the child is a study subject, linking of parent to child will be by means of the Related Subjects table in the SDTMIG.
2.3 SAE Event/Reaction (E2B B.2)
This section should provide details about the adverse event or reaction, such as the AE term, start and stop dates, SAE criteria, severity, relationship, etc. The
variable names are used for any AE, whether serious or not serious. The variable names could have the prefix AE for adverse events and SAE for adverse events
that meet SAE criteria. If the AE does not reach SAE criteria, the data may only be captured in the AE CRF, and there is no expedited reporting requirement to
regulatory authorities, and therefore, the variables do not map to E2B variables. Depending on the implementer, the AE and SAE variable names may be used
interchangeably (e.g. AESTDAT and SAESTDAT).
All of the metadata tables in Section 2.3 are structured for use in conjunction with the basic adverse event data collection fields described in the AE domain in
CDASH v1.1 when an event has reached the status of requiring expedited reporting to the sponsor/regulatory authority. The mappings to an E2B message within
this table are only relevant when the adverse event reaches the threshold defined for reporting to regulatory authorities.
Question Text
1
Were any adverse
events experienced?
E2B Variable E2B Data
Variable Name
Name
Element
Any AEs
Not
Not
AEYN
(serious or non- Applicable
Applicable
Prompt
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
BRIDG
Definition
PerformedObservationR General prompt question regarding
esult.value*
whether or not any AEs were
Controlled
Terminology
{NY}
Page 21
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Variable E2B Data
Name
Element
Variable Name
serious)?
2 AE Identifier
<line number>
Not
Not
or
Applicable
Applicable
<AE number>
primarysource
Adverse Event
B.2.i.0
reaction
AESPID
3
What is the adverse
event term?
4
Is the adverse event
serious?
Serious
serious
5a
Did the adverse event
result in death?
Death
seriousnessde
A.1.5.2
ath
AESDTH
5b
Is the adverse event life
seriousnesslife
Life threatening
A.1.5.2
Threatening?
threatening
AESLIFE
5c
5d
5e
5f
6
7
8
Did the adverse event
result in initial or
prolonged hospitalization for the subject?
Did the adverse event
result in Persistent or
significant disability or
incapacity?
Is the adverse event
associated with a
congenital anomaly or
birth defect?
Is the adverse event a
medically important
event not covered by
other “serious” criteria?
Does the subject have
<specific adverse
event>?
Example:
Does the subject have
high blood pressure?
What is the date the
adverse event started?
At what time did the
Page 22
November 25, 2013
A.1.5.1
AETERM
AESER
BRIDG
Definition
Controlled
Terminology
experienced during the study. This
provides verification that all other fields
on the CRF were deliberately left blank.
A sponsor-defined identifier that can be
Not Applicable
Implementation specific used for pre-printed numbers on the
CRF.
Verbatim (i.e., investigator-reported
AdverseEvent.value*
Not Applicable
term) description of the adverse event.
Derived from
Indicates whether or not the adverse
AdverseEventSeriousnes event is determined to be “serious”
{NY}
s.code
based on what is defined in the protocol.
Derived from
Indicates if a “serious” adverse event
{NY}
AdverseEventSeriousnes
resulted in death.
s.code
Derived from
Indicates if a “serious” adverse event
AdverseEventSeriousnes
{NY}
was life threatening.
s.code
Hospitalization
seriousnessho
A.1.5.2
spitalization
AESHOSP
Derived from
Indicates if a “serious” adverse event
AdverseEventSeriousnes resulted in an initial or prolonged
sCode.code
hospitalization.
{NY}
Significant
Disability
seriousnessdis
A.1.5.2
abling
AESDISAB
Derived from
Indicates if a “serious” adverse event
PerformedObservationR was associated with a persistent or
esult.value*
significant disability or incapacity.
{NY}
Congenital
Anomaly or
Birth Defect
seriousnessco
ngenitalanoma A.1.5.2
li
AESCONG
Derived from
Indicates if a “serious” adverse event
AdverseEventSeriousnes was associated with a congenital
s.code
anomaly or birth defect.
{NY}
Other
Medically
Important
Event
seriousnessoth
A.1.5.2
er
AESMIE
Derived from
Indicates if a “serious” adverse event is
AdverseEventSeriousnes associated with other serious or
{NY}
s.code
important medical events.
<Specific
adverse event>
primarysource
Example:
B.2.i.0
reaction
High blood
pressure
Start Date
Start Time
reactionstartda
B.2.i.4b
te
reactionstartda B.2.i.4b
AEOCCUR
AESTDAT
AESTTIM
AdverseEvent.value*
Used when the occurrence of a specific
adverse event is solicited to indicate
{NY}
whether or not (N/Y) the event
(AETERM) occurred.
AdverseEvent.occurrenc
Date when the adverse event started.
eDateRange*
AdverseEvent.occurrenc Time when the adverse event started.
Not Applicable
Not Applicable
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
adverse event start?
E2B Variable E2B Data
Name
Element
te
What is the date the
Serious adverse
reactionstartda
B.2.i.4b
9 adverse event/ reaction event/ reaction
te
became serious?
start date
What is the start time of
10 the serious adverse
event/reaction?
What date did the
11
adverse event end?
At what time did the
12
adverse event end?
What is the end date of
13 the serious adverse
event/reaction?
What is the end time of
14 the serious adverse
event/reaction?
Is the adverse event still
15
ongoing?
What was the severity
16
of the adverse event?
What is the toxicity
17 grade of the adverse
event?
What was the outcome
18
of this adverse event?
19
Is this event related to
study treatment?
Serious adverse
reactionstartda
event/reaction
B.2.i.4b
te
start time
reactionenddat
End Date
B.2.i.5b
e
reactionenddat
End Time
B.2.i.5b
e
Serious adverse
reactionenddat
event/reaction
B.2.i.5b
e
end date
Serious adverse
reactionenddat
event/reaction
B.2.i.5b
e
end date
Not
Not
Ongoing?
Applicable
Applicable
Not
Not
Severity
Applicable
Applicable
Toxicity Grade
Not
Applicable
Not
Applicable
Outcome
reactionoutco
B.2.i.8
me
Relationship to
drugreactionre
Study
B.4.k.18
latedness
Treatment
Which event is being
Adverse event
20 assessed for relatedness
assessed
with the drug?
Causality
Who made this
assessment
21
assessment?
source
Causality
How was this
assessment
22
assessment done?
method
Could the event have
Causality
23
been related to/caused assessment
Variable Name
BRIDG
Controlled
Terminology
Definition
eDateRange*
SAESTDAT
Holds the date when the adverse event
AdverseEvent.occurrenc was determined to be serious. Can be on
Not Applicable
eDateRange*
or after the date the adverse event
occurred.
SAESTTIM
AdverseEvent.occurrenc Time the adverse event/reaction became
Not Applicable
eDateRange*
serious.
AEENDAT
AEENTIM
AdverseEvent.occurrenc
Date when the adverse event resolved. Not Applicable
eDateRange*
AdverseEvent.occurrenc
Time when the adverse event resolved. Not Applicable
eDateRange*
SAEENDAT
AdverseEvent.occurrenc Date the serious adverse event/reaction
Not Applicable
eDateRange*
ended.
SAEENTIM
AdverseEvent.occurrenc Time the serious adverse event/reaction
Not Applicable
eDateRange*
ended.
AEONGO
Implementation-specific
AESEV
AETOXGR
AEOUT
AEREL
Indicates AE is ongoing when no End
Date is provided.
AdverseEvent.severityC Description of the severity of the
ode
adverse event.
AdverseEvent.gradeCod Description of the toxicity grade of the
e
adverse event.
AdverseEventOutcomeR Description of the subject’s status
esult.value*
associated with an event.
Indication of whether the study
EvaluatedActivityRelatio treatment had a causal effect on the
nship.uncertaintyCode* adverse event, as determined by the
clinician/ investigator.
{NY}
{AESEV}
{TOXGR}
{OUT}
Not Applicable
drugreactionas
B.4.k.18.1b CSLTAE
ses
AdverseEvent.identifier*
AE to which the relatedness assessment
Not Applicable
belongs
drugassessme
B.4.k.18.2
ntsource
CSLTSCR
Assessor
Source of assessment
drugassessme
B.4.k.18.3
ntmethod
CSLTMETH
CausalAssessment.meth
Method of assessment
odCode*
drugresult
CSLTRES
Derived*
B.4.k.18.4
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Assessment of drug-reaction/
event causality
Not Applicable
Not Applicable
Not Applicable
Page 23
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Variable E2B Data
Name
Element
Variable Name
BRIDG
Definition
Controlled
Terminology
by the drug or study
participation?
Question
Prompt
SAE Form Completion Instructions
Indicate if the subject experienced any adverse events. If yes,
include the appropriate details where indicated on the CRF.
Any AEs
1 (cont) (serious or nonAt time of awareness, event may be AE or SAE (AE that meets
serious)?
SAE criteria)
Information for Sponsors
The intent/purpose of collecting this field is to help with data cleaning and
monitoring. It provides verification that all other fields on the CRF were
deliberately left blank.
This field does not map directly to an SDTM variable.
Core
O
<line number>
2 (cont) or
<AE number>
Example instruction: Record unique identifier for each adverse
event for this subject.
Number sequence for all following pages should not duplicate
existing numbers for the subject.
Sponsor-defined reference number. Perhaps pre-printed on the CRF as an
explicit line identifier or defined in the sponsor's operational database.
A sequencing number that can be used in a data query to communicate
O
clearly to the site the specific record in question or to reconcile concomitant
medications and/or medical history records with AEs.
If CMAENO is used, this is the identifier to which CMAENO refers.
3 (cont) Adverse Event
Record only one diagnosis, sign or symptom per line (e.g., nausea
and vomiting should not be recorded in the same entry, but as two
separate entries).
Using accepted medical terminology, enter the diagnosis (if
known); otherwise enter a sign or symptom. If a diagnosis
subsequently becomes available, then this diagnosis should be
entered on the AE form, replacing the original entries, where
appropriate.
Death should not be recorded as an event but should be recorded as
the outcome of the event. The condition that resulted in the death
should be recorded as the event unless cause of death (event
leading to death) is unknown at the time of report. The report
should not be delayed if unable to identify the event, in this case
the report should be submitted with the adverse event recorded as
“Death”. Once available the event term Death” should be replaced
with the appropriate event term.
Do not use abbreviations.
In most cases, the verbatim term (i.e., investigator-reported term) will be
coded to a standard medical dictionary such as MedDRA, WHO ART, after
the data have been collected on the CRF. The coded data will be stored in
field(s) not defined by CDASH.
Unless cause of death (event leading to death) is unknown at the time of
report. If unable to identify the event, report should still be submitted with
“death” as AE term, to be replaced with the appropriate event term once
available.
If event starts out as an AE, then meets SAE criteria, AE term may need to
be updated accordingly
This field is related to the individual serious adverse event type fields
Assess if an adverse event should be classified as serious based on
(reference 13a to 13f), which may or may not be collected on the CRF.
the “serious” criteria defined in the protocol.
Either AESER or all the AExxx fields (13a-13f) must be present on the CRF.
Death
Record whether the “serious” adverse event resulted in death.
If the details regarding a Serious AE should be collected in the clinical
Life threatening Record whether the “serious” adverse event is life threatening.
database, then it is recommended that a separate Yes/No variable be defined
Record whether the “serious” adverse event resulted in an initial or for each Serious AE type. In many cases sponsors will only collect the
Hospitalization
prolonged hospitalization.
AESER field because the individual serious adverse event types might be
Significant
Record whether the “serious” adverse event resulted in a persistent collected in a separate pharmacovigilance database and therefore do not need
to be collected in the clinical database.
Disability
or significant disability or incapacity.
Additional detail for the SAE Report could be collected and reported as
Congenital
Record whether the “serious” adverse event was associated with
HR
4 (cont) Serious
R/C
5a (cont)
5b (cont)
R/C
R/C
5c (cont)
5d (cont)
5e (cont)
Page 24
November 25, 2013
R/C
R/C
R/C
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question
5f (cont)
Prompt
Anomaly or
Birth Defect
SAE Form Completion Instructions
congenital anomaly or birth defect.
Information for Sponsors
separate sponsor-defined fields or captured in the Narrative.
Core
Record whether the “serious” adverse event is an important
Other Medically
medical event, which may be defined in the protocol or in the
Important Event
Investigator Brochure.
R/C
AEOCCUR should only be used for pre-specified adverse events as defined
by the protocol.
AEOCCUR should not be used for spontaneously reported adverse events.
This field does not map directly to an SDTM variable.
The E2B variable can be used for date and time; this is specified in E2B be
Record the start date of the AE using this format (DD-MONthe date format variable B.2.i.a (YY / YYMM / YYMMDD /
7 (cont) Start Date
YYYY).
YYMMDDHHMM)
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
If appropriate, record the time (as complete as possible) that the
this level of detail. An example is where the subject is under the direct care
8 (cont) Start Time
AE began.
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.
Use the standard CDASH date format. See CDASH v1.1 for details.
This field does not map directly to a standard SDTM variable.
Serious adverse
Record the date when the adverse event became serious.
The start date of the SAE is the date when the adverse event/reaction became
9 (cont) event/ reaction
Record only if different from the adverse event start date.
serious, whether or not it has the same value as the start date of the AE. We
start date
have treated SAESTDAT as a separate variable from AESTDAT.
Use the standard CDASH time format. See CDASH v1.1 for details.
Serious adverse
This field does not map directly (1:1) to a standard SDTM variable.
The start time of the SAE is the time when the adverse event/reaction
10 (cont) event/reaction Enter the time the adverse event/reaction became serious.
became serious, whether or not it has the same value as the start time of the
start time
AE. We have treated SAESTTIM as a separate variable from AESTTIM.
For AE’s that meet SAE criteria, the end date of the SAE is the date when
the serious adverse event/reaction reached a final outcome. We have treated
SAEENDAT as a separate variable from AEENDAT; however, depending
Record the date that the AE resolved using this format (DD-MONon the data policy of the implementer AEENDAT and SAEENDAT can be
YYYY).
11 (cont) End Date
identical.
If the AE is ongoing, leave the field blank.
The E2B variable can be used for date and time; this is specified in E2B be
the date format variable B.2.i.a (YY / YYMM / YYMMDD /
YYMMDDHHMM)
Collecting the time an AE resolved is only appropriate if it can be
realistically determined and if there is a scientific reason for needing to know
If appropriate, record the time (as complete as possible) that the
this level of detail. An example is where the subject is under the direct care
12 (cont) End Time
AE resolved.
of the site at the time the event resolved and the study design is such that it is
important to know the AE end time with respect to dosing.
Serious adverse
The definition of resolved may be Sponsor-specific.
This field does not map directly to a standard SDTM variable.
13 (cont) event/reaction Enter the date the serious adverse event/reaction ended.
end date
The end date of the SAE is the date when the serious adverse event/reaction
6 (cont)
<Specific
Please indicate if <specific adverse event> has occurred /is
adverse event> occurring by checking “Yes” or “No”.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
O
HR
R/C
HR
O
HR
R/C
R/C
Page 25
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question
Prompt
SAE Form Completion Instructions
Serious adverse
14 (cont) event/reaction Enter the time the serious adverse event/reaction ended.
end date
15 (cont) Ongoing?
16 (cont)
17 (cont)
18 (cont)
19 (cont)
20 (cont)
21 (cont)
Check the box if the adverse event has not resolved at the time of
last observation. Leave the End Date blank.
Information for Sponsors
Core
reached a final outcome. We have treated SAEENDAT as a separate variable
from AEENDAT; however, depending on the data policy of the implementer
AEENDAT and SAEENDAT can be identical.
The definition of resolved may be Sponsor-specific.
This field does not map directly to a standard SDTM variable.
The end time of the SAE is the time when the serious adverse event/reaction
O
reached a final outcome. We have treated SAEENTIM as a separate variable
from SAEENTIM; however, depending on the data policy of the
implementer AEENTIM and SAEENTIM can be identical.
See Section 2.1.3 Mapping Relative Times from Collection to Submissions
in CDASH V 1.1 for more information.
This field will be completed to indicate that the AE has not resolved at the
point of data collection, when no End Date is collected. In some cases the
ongoing status may be determined from AE Outcome
O
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.
As described in Section 3.4.1, Best Practices in CDASH V 1.1, this is a
special use case of “Yes/No”. Please refer to Section 3.4.1 in CDASH V 1.1
for additional information.
The reporting physician/healthcare professional will assess the
severity of the event using the sponsor-defined categories. This
Either AESEV or AETOXGR must appear on the CRF. Some studies may
assessment is subjective and the reporting physician/ healthcare
Severity
mandate the collection of both.
professional should use medical judgment to compare the reported
Refer to ICH E3 guidelines for CSR Section 12.2.4.
Adverse Event to similar type events observed in clinical practice.
Severity is not equivalent to seriousness.
Either AESEV or AETOXGR must appear on the CRF. Some studies may
Severity CTCAE Grade
mandate the collection of both.
Toxicity Grade The reporting physician/healthcare professional will assess the
Refer to ICH E3 guidelines for CSR Section 12.2.4.
CTCAE grade is commonly used in oncology studies although it can also be
severity of the adverse event using the toxicity grades.
used elsewhere.
CDISC controlled terminology should be used to indicate the outcome of the
Record the appropriate outcome of the event in relation to the
Outcome
event as it relates to the subject’s status. The Outcome controlled
subject’s status.
terminology includes ICH E2B values.
Indicate if the cause of the adverse event is related to the study
Relationship to
Sponsored-defined terminology will be used to indicate the relationship
treatment and cannot be reasonably explained by other factors
Study
between the AE and the study treatment (e.g. ICH E2B examples: Not
(e.g., subject’s clinical state, concomitant therapy, and/or other
Treatment
Related, Unlikely Related, Possibly Related, Related).
interventions).
Adverse event
Not completed by site.
It is recommended that this field is auto-populated.
assessed
Causality
Source of assessment (e.g., initial reporter, investigator, regulatory agency,
assessment
Not completed by site.
company).
source
Page 26
November 25, 2013
R/C
R/C
HR
HR
O
O
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question
Prompt
Causality
22 (cont) assessment
method
Causality
23 (cont)
assessment
SAE Form Completion Instructions
Information for Sponsors
Core
Not completed by site.
Method of assessment (e.g., global introspection, algorithm, Bayesian
calculation).
O
Not completed by site.
Indicate whether the event could have been related to the drug or treatment,
intervention, or study participation (e.g., procedure).
HR
2.4 Investigations and Results (E2B B.3)
This section should capture the tests and procedures performed to diagnose or confirm the reaction/event, including those tests done to investigate (exclude) a
non-drug cause, (e.g., serologic tests for infectious hepatitis in suspected drug-induced hepatitis). Both positive and negative results should be reported. Tests and
procedures might be performed as a result of an SAE. These tests and their corresponding results might be part of the scheduled clinical data capture, but could
also be recorded on an Unscheduled Visit CRF. When these tests and their results are not captured on an Unscheduled Visit CRF and mappable to an SAE report,
consideration should be made for explicitly capturing these data fields on an SAE form that collects data for safety reporting.
Structured information is always preferable but if not possible, the information can also be transmitted as free text.
2.4.1 Information from Existing CRFs
There are a number of results of tests and procedures fields that are reported on an E2B message. The table below provides the relationship between the
structured CDASH fields and the corresponding structured E2B messages for the purposes of mapping. The “--” represents the two-character prefix of a CDASH
domain and can be replaced with any Findings domain where there is relevant data. Examples could include EG (ECG), VS (Vital Signs), LB (Laboratory Test
Results), PE (Physical Exam - option B), etc.
Results of tests and procedures relevant to the investigation of the patient:
CDASH Field
E2B Data Element
E2B Title
B.3
Results of tests and procedures relevant to the investigation of the patient
Not Applicable
B.3.1a
Structured information (repeat as necessary)
Not Applicable
--DAT
B.3.1b
Date/Time
--TEST
B.3.1c
Test Name
--ORRES or –DESC B.3.1d
Result
--ORRESU
B.3.1e
Unit
--ORNRHI
B.3.1.1
Normal high range
--ORNRLO
B.3.1.2
Normal low range
B.3.1.3
More information available (Y/N)
Not Applicable
Free text field for results of tests and procedures relevant to the SAE of the patient that cannot be captured
B.3.2
Not Applicable
in the structured variables above
**Note-the “--” represents the two-character prefix of a CDASH domain
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 27
November 25, 2013
CDASH Serious Adverse Event Supplement v1
The mappings above have been applied to the LB domain in the next section, as a representative approach to mapping the CDASH fields to the E2B data
elements. Other Findings (non-lab) could also be relevant to the event, and CRF Designers should use the appropriate findings fields for their forms from the
CDASH standard. If, in response to the event, tests are performed that are not collected in standard CDASH domains the appropriate E2B data elements should
be collected on an SAE form, for purposes of safety reporting. Below are examples of non-lab findings that have existing CDASH standards, such as Physical
Exam and ECG, and the mapping of the CDASH variable names to the E2B Data Elements.
CDASH Variable Name E2B Data Element E2B Title
PEDAT*
PETEST
PEORRES
Page 28
November 25, 2013
B.3.1b
B.3.1c
B.3.1d
Date/Time
Test Name
Result
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
CDASH Variable Name E2B Data Element E2B Title
EGDAT
B.3.1b
Date/Time
EGTEST
B.3.1c
Test Name
EGORRES
B.3.1d
Result
2.4.2 Laboratory Findings – (CDASH LB)
This section should capture the tests and procedures performed to diagnose or confirm the reaction/event, including those tests done to investigate (exclude) a
non-drug cause, (e.g., serologic tests for infectious hepatitis in suspected drug-induced hepatitis). Both positive and negative results should be reported (B.3.1).
While structured information is preferable, provisions have been made to transmit the information as free text in B.3.2.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 29
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Variable
E2B
Variable Names
Name
Section
1
What was the lab
Collection
testdate
specimen collection date? Date
B.3.1b LBDAT
2
What was the lab
Collection
testdate
specimen collection time? Time
B.3.1b LBTIM
3 What is the test name?
4
5
6
7
8
9
What was the result of the
test?
What were the units for
the result?
What was the lower limit
of the reference range for
this test?
What was the high limit
of the reference range for
this test?
Are there any other
relevant details or
information about the lab
results?
Are there any other
relevant details or
information about the lab
results?
Question
1 (cont)
2 (cont)
3 (cont)
4 (cont)
5 (cont)
6 (cont)
Prompt
<Test
Name>
testname
B.3.1c LBTEST
Result
testresult
B.3.1d LBORRES
Units
testunit
B.3.1e LBORRESU
Low
Normal
lowtestrange
B.3.1.1 LBORNRLO
High
Normal
hightestrange
B.3.1.2 LBORNRHI
More
information moreinformation B.3.1.3 COVALYN
available
Comments
resultstestproced
B.3.2
ures
COVAL
SAE Form Completion Instructions
Record the date when specimen
Collection Date collection occurred using this format
(DD-MON-YYYY).
Record time of collection (as complete as
Collection Time
possible).
<Test Name>
Record the type or name of the lab test.
Result
Record test results.
Record the units of the lab test, if not
Units
pre-printed on the CRF or captured in an
external “lab normal” file.
Record the lower limit of the reference
Low Normal
range of the lab test.
Page 30
November 25, 2013
BRIDG
Definition
PerformedObservation |
PerformedSpecimenCollecti Date of specimen collection
on.dateRange*
PerformedObservation |
PerformedSpecimenCollecti Time of specimen collection
on.dateRange*
Verbatim name of the test or examination
DefinedObservation.nameCo used to obtain the measurement or finding.
Any test normally performed by a clinical
de*
laboratory is considered a lab test.
PerformedObservation
Result of the measurement or finding as
Result.value*
originally received or collected.
PerformedObservation
Original units in which the data were
Result.value*
collected.
The lowest continuous numeric value of a
given lab result expected in the population
ReferenceResult.value*
of interest.
The highest continuous numeric value of a
given lab result expected in the population
ReferenceResult.value*
of interest
PerformedObservationResult The availability of more information
.comment
related to lab data
Controlled
Terminology
Not
Applicable
Not
Applicable
{LBTEST}
Not
Applicable
{UNIT}
Not
Applicable
Not
Applicable
{NY}
Results of tests and procedures relevant to
Not
PerformedObservationResult
the investigation (unstructured
Applicable
.comment
information - free text
Implementation Instructions
Core
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 R/C
is not required.
R/C
Especially important when multiple assessments are done on one day.
Required to identify the test.
Key data collected.
HR
HR
Should be included if applicable and not available elsewhere. For some lab tests the units may not be
R/C
applicable (e.g., urine color).
LBORNRLO and LBORNRHI should be populated only for continuous results; LBSTNRC should be
R/C
populated only for non-continuous results. These data may be obtained from the lab or the electronic
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question
Prompt
7 (cont) High Normal
SAE Form Completion Instructions
Record the upper limit of the reference
range of the lab test.
Implementation Instructions
Core
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 and selecting the proper variable name.
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.
R/C
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 and selecting the proper variable name.
More information Indicate if additional information/
Additional lab details might be available as an attachment.
available
attachments are provided
Record information related to tests and This is a free text field for any comments relevant to tests or procedures.
procedures that cannot be captured in the B.3.2 is used only if results and units cannot be split and reported in B.3.1d and B.3.1e. More than
9 (cont) Comments
fields above.
one test can be included in B.3.2
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
8 (cont)
O
O
2.5 Drug Information (E2B B.4)
2.5.1 Information from Existing CRFs
Implementers should utilize the fields identified in the CDASH standard. The fields listed below include the CDASH field and additional fields that can be used
if needed. See Section 1.2 for a more detailed explanation. This section relates to drug data that might have been captured in the Exposure (EX) domain or the
Concomitant Medication (CM) domain in existing CDASH forms. If the suspect drug is a concomitant medication then the applicable fields from the CM domain
are completed. If the suspect drug is study treatment then the applicable fields from the EX domain is completed. Both domain variables have been included for
purposes of completeness recognizing that the identified drugs would probably only come from one of these identified sources.
2.5.2 Drug Information – (CDASH EX), (CDASH CM) and Other Variables Associated with Suspect
Drug
This section covers both suspect drugs and concomitant medication. If the event is related to study treatment(s), the associated variables for the EX domain are
populated. If the event is related to concomitant treatment(s), the associated variables in the CM domain are populated. In addition, the section can be used to
identify drugs thought to have an interaction. If the event results from the interaction between study treatment(s) and concomitant therapy(ies), then the
associated variables for both CM and EX domains are populated.
Drugs used to treat the reaction/event should not be included here.
Question Text
Prompt
What was the
Treatment
1
study treatment? Name
E2B Variable
Name
E2B
Section
medicinalproduct B.4.k.2
Variable Names
EXTRT
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
BRIDG
MaterialName.name*
Definition
Name of the study treatment or
intervention given per single
administration or during the “constant
dosing interval” for the observation.
Controlled
Terminology
Not Applicable
Page 31
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question Text
2
3
4
5
6
7
What was the
term for the
medication/
therapy taken?
or
What was the
term for the
medication
taken?
What was the lot
number of the
study treatment
used?
What was the
dose per
administration?
What was the
individual dose
of the
medication/
therapy?
What were the
units for the
dose?
What was the
unit of the
medication/
therapy?
Prompt
Page 32
November 25, 2013
BRIDG
Definition
Controlled
Terminology
CMTRT
MaterialName.name*
Verbatim drug name or therapy (include
only therapies with data collection
Not Applicable
characteristics similar medications).
Lot Number
drugbatchnumb
EXLOT
Drug.lotNumberText
Lot Number of the EXTRT product.
Not Applicable
Dose
drugstructuredosa
EXDSTXT
B.4.k.5.1
genumb
EXDOSE
PerformedSubstance
Administration.active
IngredientDoseDescription*
Dose per administration.
Not Applicable
Dose
CMDSTXT
drugstructuredosa
B.4.k.5.1
CMDOSE
genumb
PerformedSubstance
Administration.active
IngredientDoseDescription*
The dose of medication taken per
administration.
Not Applicable
Unit
drugstructuredosa
B.4.k.5.2 EXDOSU
geunit
PerformedSubstanceAdminist
Units for EXDOSE.
ration.activeIngredientDose*
Dose Unit
drugstructuredosa
B.4.k.5.2 CMDOSU
geunit
PerformedSubstanceAdminist The unit associated with the medication
{UNIT}
ration.activeIngredientDose* taken
Frequency
What was the
frequency of the
Frequency
9b
medication
/therapy?
9c
What was the
dose per
Variable Names
medicinalproduct B.4.k.2
9a
10
E2B
Section
Medication
or
Therapy
8a
What was the
frequency of
8b
study treatment
dosing?
8c
E2B Variable
Name
Dose
drugseparatedosa
genumb
drugintervldosage
unitnumb
drugintervaldosag
edefinition
drugseparatedosa
genumb
drugintervldosage
unitnumb
drugintervaldosag
edefinition
drugdosagetext
B.4.k.3
B.4.k.5.3
Number of separate dosages
B.4.k.5.4 EXDOSFRQ
PerformedSubstanceAdminist
Number of units in the interval
ration.doseFrequencyCode*
B.4.k.5.5
Number of separate dosages
CMDOSFRQ
PerformedSubstance
Administration.dose
FrequencyCode*
B.4.k.5.5
B.4.k.6
{FREQ}
Definition of the interval
B.4.k.5.3
B.4.k.5.4
{UNIT}
Number of units in the interval
{FREQ}
Definition of the interval
EXDSTXT
PerformedSubstance
Administration.active
Free text field to describe drug dosage.
Not Applicable
This item should be used in cases where
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Variable
Name
E2B
Section
Variable Names
administration?
11
12
13
14
15
16
17
18
19
20
What was the
individual dose
of the
medication/
therapy?
What was the
formulation of
the study
treatment?
What was the
dose form of the
medication/
therapy?
What was the
route of
administration
for the study
treatment?
What was the
route of
administration of
the medication
/therapy?
What is the
drug’s
indication?
What was the
treatment start
date?
What was the
treatment start
time?
What was the
start date of the
medication/
therapy?
What was the
start time of the
medication/
therapy?
BRIDG
IngredientDoseDescription*
Definition
Controlled
Terminology
provision of structured dosage
information is not possible.
Dose
drugdosagetext
B.4.k.6
CMDSTXT
Free text field to describe drug dosage.
PerformedSubstance
This item should be used in cases where
Not Applicable
Administration.active
provision of structured dosage
IngredientDose Description*
information is not possible.
Formulation
drugdosageform
B.4.k.7
EXDOSFRM
Drug.formCode*
Dose form for EXTRT
{FRM}
Dose Form
drugdosageform
B.4.k.7
CMDOSFRM
Material.formCode*
Name of the pharmaceutical dosage
form (e.g., TABLET CAPSULE,
SYRUP) of delivery for the drug.
{FRM}
Route
drugadministratio
B.4.k.8
nroute
EXROUTE
PerformedSubstance
Administration.routeOf
AdministrationCode*
Route of administration for EXTRT
{ROUTE}
Route
drugadministratio
B.4.k.8
nroute
CMROUTE
PerformedSubstance
Administration.routeOf
AdministrationCode*
Identifies the route of administration of
{ROUTE}
the drug.
Indication
drugindication
B.4.k.11b EXINDC
PerformedSubstanceAdminist
Indication for use of the study treatment Not Applicable
ration.reasonCode*
Start Date
drugstartdate
B.4.k.12b EXSTDAT
PerformedSubstanceAdminist
Start date of study treatment.
ration.dateRange*
Not Applicable
Start Time
drugstartdate
B.4.k.12b EXSTTIM
PerformedSubstanceAdminist
Start time of study treatment.
ration.dateRange*
Not Applicable
Start Date
drugstartdate
B.4.k.12b CMSTDAT
PerformedSubstanceAdminist Date when the medication was first
ration.dateRange*
taken.
Not Applicable
Start Time
drugstartdate
B.4.k.12b CMSTTIM
PerformedSubstanceAdminist Time when the medication was first
ration.dateRange*
taken.
Not Applicable
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 33
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Variable
Name
E2B
Section
Variable Names
BRIDG
Derived from difference
between
PerformedSubstanceAdminist
ration and
AdverseEvent.occurrenceDat
eRange*
Derived from difference
between
PerformedSubstanceAdminist
ration and
AdverseEvent.occurrenceDat
eRange*
Definition
Time interval between beginning of
drug administration and start of
reaction/event
Controlled
Terminology
21 Not Applicable
Not
Applicable
drugstartperiod
B.4.k.13.1 CDASH value is
derived
a
22 Not Applicable
Not
Applicable
druglastperiod
B.4.k.13.2 CDASH value is
derived
a
End Date
drugenddate
B.4.k.14b EXENDAT
PerformedSubstanceAdminist
End date of study treatment.
ration.dateRange*
Not Applicable
End Time
drugenddate
B.4.k.14b EXENTIM
PerformedSubstanceAdminist
End time of study treatment.
ration.dateRange*
Not Applicable
End Date
drugenddate
B.4.k.14b CMENDAT
PerformedSubstanceAdminist Date that the subject stopped taking the
Not Applicable
ration.dateRange*
medication or therapy.
End Time
drugenddate
B.4.k.14b CMENTIM
PerformedSubstanceAdminist Time that the subject stopped taking the
Not Applicable
ration.dateRange*
medication or therapy.
What was the
23 treatment end
date?
What was the
24 treatment end
time?
What was the end
date of the
25
medication/
therapy?
What was the end
time of the
26
medication/
therapy?
What action was
27 taken with study
treatment?
Action Taken
with Study
actiondrug
Treatment
B.4.k.16
AEACN
Was there an
adverse event on
28
drug readministration?
Event
recurrence on drugrecurreadmin
B.4.k.17.1 RECURYN
istration
drug readministration
Which adverse
event recurred on
29
drug readministration?
Adverse event
that recurred
drugrecuraction
on drug readministration
Page 34
November 25, 2013
B.4.k.17.2
RECURACN
b
Not Applicable
Time interval between last dose of drug
Not Applicable
and start of reaction/event
Changes made to the study treatment in
DefinedActivity.name Code* response to the adverse event.
{ACN}
Derived from
PerformedSubstanceAdminist
ration.dateRange,
AdverseEvent.occurrenceDat
eRange and the result of the
CausalAssessment being
determined to be the drug
administration
Derived from
PerformedSubstanceAdminist
ration.dateRange,
AdverseEvent.occurrenceDat
eRange and the result of the
Did the reaction recur on readministration?
{NY}
If yes, which reaction(s)/ event(s)
recurred?
Not Applicable
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Variable
Name
E2B
Section
Variable Names
BRIDG
Definition
Controlled
Terminology
CausalAssessment being
determined to be the drug
administration
Is there any other
Additional
relevant
drug
30
information on
information
the drug?
Question
1 (cont)
2 (cont)
3 (cont)
4 (cont)
5 (cont)
6 (cont)
7 (cont)
Prompt
drugadditional
B.4.k.19
DRGADD
SAE Form Completion Instructions
PerformedObservationResult. Free text field for additional information
Not Applicable
comment
on drug.
Implementation Instructions
Name of study treatment that was administered to the subject.
Treatment Name Record the name of study treatment.
This is collected for open label studies and derived for blinded studies.
This variable must be populated in the SDTM whether it is collected or derived.
In most cases, the verbatim drug names 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 verbatim drug name or therapy, the recommendation is to ask the sites
Medication
Provide the full trade or proprietary name of the
to provide the full trade or proprietary name since it is more exact than the generic. The full
or
drug or therapy; otherwise the generic name may
trade name provides the base generic and the appropriate salt for that particular drug. In
Therapy
be recorded.
addition, for coding purposes it helps with ATC selection.
For example, the medication Tylenol with codeine #1 has a different ATC code from
Tylenol with codeine #3.
The Lot Number identifies the manufacturing batch of the study treatment.
Record the lot number that appears on the
Lot Number
In open label studies, the reference number on the study treatment container may represent
container holding the study treatment.
an actual Lot Number and should be submitted using EXLOT.
Dose or amount taken for single administration of study treatment or per constant dosing
interval recorded.
Record the dose or amount of study treatment that Dose must be collected if it cannot be derived via other methods (e.g., derived from diary
was administered to/taken by the subject in the
data, drug accountability data, protocol etc.).
Dose
period recorded; from the start date/time to the end Care should be taken when mapping EXDSTXT to the appropriate SDTMIG variable
date/time inclusive.
EXDOSE or EXDOSTXT. The data collected in this dose text-format field should be
separated or mapped to either SDTMIG EXDOSE if numeric or EXDOSTXT if text.
This field does not map directly to an SDTM variable.
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 dose
Record the dose of medication taken per
entries as numbers, text or ranges.
Dose
This field does not map directly to an SDTM variable.
administration (e.g., 200).
The data collected in this dose text-format field should be separated or mapped to either
SDTMIG CMDOSE if numeric or CMDOSTXT if text.
Dose unit must be collected if it cannot be derived via other methods (e.g., derived from
Record the unit of dose or amount taken per period
Unit
protocol, randomization data). The unit should be pre-printed on the CRF or a field
recorded (e.g., ng, mg, mg/kg).
provided on the CRF to capture it.
Record the dose unit of the dose of medication
When sponsors collect data for amount of dose taken (i.e., Dose, Total Daily Dose), Unit
Dose Unit
taken (e.g., mg.).
must be collected as well.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Core
R/C
HR
O
R/C
O
R/C
O
Page 35
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question
8 (cont)
9 (cont)
Prompt
Frequency
Frequency
10 (cont) Dose
11 (cont) Dose
12 (cont) Formulation
13 (cont) Dose Form
14 (cont) Route
15 (cont) Route
16 (cont) Indication
17 (cont) Start Date
Page 36
November 25, 2013
SAE Form Completion Instructions
Implementation Instructions
CDASH defines dose frequency as a single variable specifying the number of doses per
specified interval. The E2B breaks up components of this definition into three separate
Record the frequency the study treatment was
variables (number of dosages, number of intervals, and specified interval value).
administered for a defined period of time (e.g.,
<X number of separate dosages
BID, QID, TID).
Y number of interval
Z specified interval>
CDASH defines dose frequency as a single variable specifying the number of doses per
specified interval. The E2B breaks up components of this definition into three separate
Record how often the medication or therapy was
variables (number of dosages, number of intervals, and specified interval value).
<X number of separate dosages
taken. (e.g., BID, PRN).
Y number of interval
Z specified interval>
Dose or amount taken for single administration of study treatment or per constant dosing
interval recorded.
Record the dose or amount of study treatment that Dose must be collected if it cannot be derived via other methods (e.g., derived from diary
was administered to/taken by the subject in the
data, drug accountability data, protocol etc.).
period recorded; from the start date/time to the end Care should be taken when mapping EXDSTXT to the appropriate SDTMIG variable
date/time inclusive.
EXDOSE or EXDOSTXT. The data collected in this dose text-format field should be
separated or mapped to either SDTMIG EXDOSE if numeric or EXDOSTXT if text.
This field does not map directly to an SDTM variable.
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 dose
entries as numbers, text or ranges.
Record the dose of medication taken per
This field does not map directly to an SDTM variable.
administration (e.g., 200).
The data collected in this dose text-format field should be separated or mapped to either
SDTMIG CMDOSE if numeric or CMDOSTXT if text.
Record the formulation (e.g., SOLUTION,
TABLET, LOTION) or enter the appropriate code EXDOSFRM must be collected if it cannot be derived or if there are multiple options.
from the codelist.
Record the pharmaceutical dosage form (e.g.,
Some drugs have multiple forms and this field may be needed to code the drug to an ATC
TABLET CAPSULE, SYRUP) of delivery for the level. However, in general, this level of detail should not be necessary except for
medication taken.
medications of interest.
Record the route of administration (e.g., IV,
EXROUTE it may be pre-printed on the CRF or derived from the protocol.
ORAL, TRANSDERMAL) or enter the appropriate
code from the codelist.
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
Provide the route of administration for the drug.
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.
Provide the drug’s indication.
May or may not be auto-populated. MedDRA terms should be provided.
Record the start date of the study treatment
Date when constant dosing interval of the study treatment started or single administration
administration using this format (DD-MONoccurred.
YYYY).
Core
R/C
O
R/C
O
R/C
O
R/C
R/C
HR
HR
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question
Prompt
18 (cont) Start Time
19 (cont) Start Date
20 (cont) Start Time
21 (cont) Not Applicable
22 (cont) Not Applicable
23 (cont) End Date
24 (cont) End Time
25 (cont) End Date
26 (cont) End Time
27 (cont)
Action Taken
with Study
SAE Form Completion Instructions
Record the start time of the study treatment
administration
Record the date the medication or therapy was first
taken using this format (DD-MON-YYYY).
If the subject has been taking the medication for a
considerable amount of time prior to the start of the
study, it is acceptable to have an incomplete date.
Medications taken during the study are expected to
have a complete start date.
Prior medications that are exclusionary should
have both a start and end date.
Implementation Instructions
Core
Time when constant dosing interval of the study treatment started or single administration
occurred.
The preferred method is to collect a complete Start Date. Partial dates (e.g., providing year
HR
only) for medications started a considerable amount of time prior to the start of study are
acceptable.
Recommend collecting the time a medication was started when a protocol or data collection
Record the time the medication or therapy was first
scenarios supports it. Typically, a start time is not collected unless the subject is under the
taken.
direct care of the site at the time a medication or therapy is administered.
Derived value based on the start date of drug and the onset date of the adverse event.
Intervals are used in circumstances where both the dates are known but the interval is very
Not completed by the site.
short (e.g., minutes, such as in anaphylaxis), and when only partial dates are known but
more information concerning the interval is known. Dates if available should always be
transmitted in the appropriate items, rather than intervals.
Derived value based on the last date of drug and the onset date of the adverse event.
Intervals are used in circumstances where both the dates are known but the interval is very
Not completed by the site.
short (e.g., minutes, such as in anaphylaxis), and when only partial dates are known but
more information concerning the interval is known. Dates if available should always be
transmitted in the appropriate items, rather than intervals.
Record the end date or last date of administration If start date and end date are not expected to be on the same date, the end date is required. If
of study treatment using this format (DD-MONthe study design indicates that the start and end date are on the same day, the end date is not
YYYY).
required since it can be assigned to be equal to the start date.
Recommend collecting the time a medication or therapy was ended when a protocol or data
Record the end time or last time of administration collection scenarios supports it.
Typically, an end time is not collected unless the subject is under the direct care of the site
of study treatment.
at the time a medication or therapy is stopped.
Record the date the subject stopped taking the
medication or therapy using this format (DDThe assumption is that sponsors should either have a complete end date or will indicate that
the medication or therapy was ongoing at the time of collection or at the end of the study.
MON-YYYY).
If the subject has not stopped taking the medication
leave this field blank.
Record the time the subject stopped taking the
Recommend collecting the time a medication or therapy was ended when a protocol or data
medication or therapy. If the subject has not
collection scenarios supports it.
stopped taking the medication leave this field
Typically, an end time is not collected unless the subject is under the direct care of the site
blank.
at the time a medication or therapy is stopped.
Record changes made to the study treatment
CDISC controlled terminology should be used to indicate the action taken with the study
resulting from the adverse event.
treatment in response to the AE.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
HR
R/C
O
O
HR
R/C
R/C
R/C
HR
Page 37
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Question
Prompt
SAE Form Completion Instructions
Treatment
Event recurrence
Indicate whether the adverse event recurred on
28 (cont) on drug redrug re-administration.
administration
Adverse event
that recurred on
Not completed by site.
29 (cont)
drug readministration
Implementation Instructions
Unknown indicates that a re-challenge was done but it is not known if the event recurred.
This segment should not be completed if it is unknown whether a re-challenge was done.
O
It is recommended that this field is auto-populated. MedDRA terms should be used.
O
This should be used to specify any additional information pertinent to the case that is not
covered by above sections. (e.g., beyond expiration date, batch and lot tested and found to
be within specifications). This item can also be used to provide additional information
concerning the indication for the drug.
* See the BRIDG Mapping Spreadsheet – CDASH tab or the BRIDG model at www.bridgmodel.org for the complete mapping path.
Additional drug
30 (cont)
information
Enter any other relevant information on the drug
e.g., beyond expiration date, batch and lot tested
and found to be within specifications
Core
O
2.6 Narrative
The objective of the narrative is to summarize all relevant clinical and related information, including subject characteristics, therapy details, medical history,
clinical course of the event(s), diagnosis, including the outcome, laboratory evidence, and any other information that supports or refutes an adverse drug reaction.
The narrative should serve as a comprehensive, stand-alone “medical story”. The information should be presented in a logical time sequence; ideally this should
be presented in the chronology of the subject/patient’s experience, rather than in the chronology in which the information was received.
Key information from supplementary records should be included in the report. Any relevant autopsy or post-mortem findings should also be summarized in the
narrative. Terms (e.g., AEs/SAEs, indication, and medical conditions) in the narrative should be accurately reflected in appropriate data fields.
The purpose of the medical review is to ensure correct interpretation of the medical information. The review should include, but is not limited to, the following
considerations:
• Is a diagnosis possible?
• Have the relevant diagnostic procedures been performed?
• Were alternative causes of the event/reaction(s) considered?
• What additional information is needed to allow for the final conclusion on whether or not the SAE is caused by the product? Include the rationale for the
final conclusion
The table below provides the high level structure for providing the Narrative and Assessment section of the SAE Form. For full content details of the Narrative,
please refer to Appendix E for:
• Content Elements of the Narrative
• Sample Narrative Template
Page 38
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Question Text
Prompt
E2B Data
Element
SAE Form Completion Instructions
Implementation Instructions
Summarize the details relevant to the case with enough
information to allow for a full understanding of the case, and
to perform a causality assessment.
The Reporter (investigator) presents their findings and
assessment in their SAE report to the sponsor.
The Sender (sponsor) does have corresponding sections for
their comments and assessment, which is captured in B.5.1,
B.5.3, and B.5.4
1
What are the details of the
SAE/reaction?
SAE Narrative
Maps to
B.5.1
Include these sections:
Describe the SAE
Describe the Work-up and Evaluation
Therapeutic measures taken to treat the SAE
Outcome of the SAE
Additional relevant information
2
What is the rationale for the
final assessment for
causality?
Rationale for Final
Investigator
Causality
Maps to
B.5.2
Provide the conclusion of the medical review
Clear concise statement as to whether or not the product
and the determination of causality. Include
caused the SAE, and the reason(s) why or why not.
the rationale for the conclusion.
3 Regulatory References
3.1 Introduction
Data capture is part of the regulated activities in clinical trials. The table below lists the regulations and guidance that were referenced in developing the CDASH
requirements for the SAE domain. Brief explanations and/or interpretations of the wording are also provided.
3.1.1 Notices
There are often several ways of interpreting guidance and regulations and, therefore, this information should not be taken as an official or FDA/ICH-approved
interpretation.
3.1.2 Scope
•
•
•
Includes information on the collection, analysis, and reporting of safety data, including the extended information required for expedited adverse event
reporting
Includes descriptions of the kinds of information present in the regulations, but does not list all the individual data fields
Excludes references to appropriate protocol designs for enabling safety assessments
3.1.3 Key
•
•
Source: Defines the regulatory body that issued the regulation or guideline
Regulation/Guideline: Provides the reference number and title of the regulation or guideline
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 39
November 25, 2013
CDASH Serious Adverse Event Supplement v1
•
Description/Wording: Gives an interpretation of the intent of the regulation/guideline as it applies to the collection, analysis, and reporting of safety
data, as well as specific wording from the document where useful. Generally, the reader should reference the original document for details. Wording in
italics contains some suggestions for the implications of the regulation on data capture practices. It is not exhaustive, and users should take these insights
and apply them broadly.
3.1.4 Sources
The regulatory references for the SAE domain, provided below, focus on the ICH guidelines as well as the relevant regulations and guidelines from the EMA, the
US FDA, and the Japan MHLW. Specific legislation on local country levels is not reflected here and might need to be taken into consideration, depending on the
countries and regions in which projects based on this CDASH guideline are planned to be conducted.
•
•
•
•
•
•
Source
CFR
CFR
CFR
EC
Code of Federal Regulations (CFR)
European Commission directives and regulations, including:
- Detailed guidance on the collection, verification, and presentation of adverse reaction reports arising from clinical trials on medicinal products for
human use, ENTR/CT3 April 2006
- Approximation of the laws, regulations and administrative provisions of the Member States relating to the implementation of good clinical practice
in the conduct of clinical trials on medicinal products for human use, Directive 2001/20/EC
- Community Code Relating to Medicinal Products for Human Use, Directive 2001/83/EC, as amended by Setting standards of quality and safety for
the collection, testing, processing, storage and distribution of human blood and blood components, Directive 2002/98/EC
- Eudralex, Rules governing medicinal products in the European Union (http://ec.europa.eu/health/documents/eudralex/index_en.htm)
- Arrangements for Reporting Suspected Unexpected Adverse Reactions which are Not Serious, Regulation No. 540/95
- Procedures for the Authorisation and Supervision of Medicinal Products for Human and Veterinary Use, Regulation No. 726/2004
ICH Harmonized Efficacy Guidelines finalized as of 30 March 2012 (http://www.ich.org)
FDA Guidance finalized as of 30 March 2012 (http://www.fda.gov/opacom/morechoices/industry/guidedc.htm)
FDA Manual of Policies and Procedures and Compliance Program Guidance Manual
(http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm)
NCI codelists
Regulation/Guideline
Description/Wording
21 CFR Part 312 Investigational New Drug
312.32: Safety reports following IND submissions: defines “serious” and the terms that are used in the definition.
Application
Describes what the reports should contain; defines “associated”, “expected” and “unexpected” adverse drug reactions.
21 CFR Part 314 Applications for FDA Approval to
314.80: Definition of SAE.
Market a New Drug
803.32: provides a list of variables to be collected and reported by user facilities for individual adverse event reports
related to medical devices
803.42: provides a list of adverse event-related variables that must be reported for individual safety reports by
21 CFR Part 803 Medical Device Reporting
importers of medical devices
803.52: provides a list of variables to be collected and reported by device manufacturers for individual adverse event
reports related to medical devices
ENTR/CT3 April 2006: Detailed guidance on the
Presents extensive information on expedited reporting of serious AEs. It is very similar to ICH E2A and E2B,
collection, verification and presentation of adverse although it provides somewhat more specificity in places. It doesn’t define requirements for any additional data, but
Page 40
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Source
EC
EC
EC
EC
EC
EC
FDA
Regulation/Guideline
reaction reports arising from clinical trials on
medicinal products for human use
Directive 2001/20/EC on the approximation of the
laws, regulations and administrative provisions of
the Member States relating to the implementation of
good clinical practice in the conduct of clinical trials
on medicinal products for human use
Directive 2001/83/EC on the Community Code
Relating to Medicinal Products for Human Use, as
amended by Directive 2002/98/EC setting standards
of quality and safety for the collection, testing,
processing, storage and distribution of human blood
and blood components
EudraLex Volume 9a: Guidelines on
Pharmacovigilance for Medicinal Products for
Human Use
EudraLex Volume 10 Clinical Trials Guidelines
Regulation No. 540/95: Arrangements for Reporting
Suspected Unexpected Adverse Reactions which are
Not Serious
Regulation No. 726/2004 Procedures for the
Authorisation and Supervision of Medicinal
Products for Human and Veterinary Use
Guidance for Industry: Premarketing Risk
Assessment
Description/Wording
rather clarifies roles and responsibilities, and timelines for reporting.
Establishes the provisions regarding the conduct of clinical trials on human subjects, including definitions for serious
adverse events, expectedness, and reportability requirements.
Establishes requirements of pharmacovigilance, risk management, and quality management systems, including
definition of serious adverse events and notification requirements around suspected serious adverse events.
Provides general guidance on the requirements, procedures, roles, and activities in pharmacovigilance. Guidelines are
based on ICH, but include further specification in line with EU legislation. Includes technical requirements for the
electronic exchange of pharmacovigilance data
Chapter II: Monitoring and Pharmacovigilance
Contains detailed guidance on the collection, verification, and presentation of adverse reaction reports during clinical
trials, including Suspected Unexpected Serious Adverse Reaction (SUSAR) reports
Describes the procedure for reporting suspected unexpected adverse reactions to medicinal products for human use,
where the adverse reaction is not serious, and regardless of where the event occurred (within or outside of the EC)
Describes improved procedures for the authorization, supervision, and pharmacovigilance of medicinal products for
human use. Reinforces pharmacovigilance monitoring procedures, including establishment of the EudraVigilance
database that collates pharmacovigilance data. Also provides the legal basis for the European Medicines Agency.
Provides guidance on approaches to evaluating a drug’s risk profile. While much of it focuses on pooled data and
guidelines for pooling data, there are implications for individual studies, particularly in terms of coding, and the
analysis of temporal relationships of drugs and AEs.
Section VI.A.1 Accuracy of Coding: provides recommendations around coding AEs, and ensuring appropriate
coding.
Section VI.B, Analyzing Temporal or Other Associations: discusses the importance of being able to determine the
timing of AEs both relative to treatment dates as well as to length of exposure to treatment. This emphasizes the need
to capture complete and accurate event dates.
Section VI.G, Long-term Follow-up: discusses the need to determine what an appropriate follow-up period is for AE
collection, and suggests that this should be discussed with regulatory authorities, potentially during end-of-Phase-2
meetings. This should drive the cut-off point for collecting AEs for a study, and how long the database needs to
remain open for adding AEs after the study is completed.
Section VI.H, Important Aspects of Data Presentation: this is a supplement to the ICH E3 guidelines, and it covers
additional analyses to be considered. Particularly, it states that for subjects who died during the study, the official
CRF should contain copies of hospital records, autopsy reports, biopsy results, and any other pertinent information.
This doesn’t necessarily mean this information must be specifically collected on sponsor-generated CRFs, but that
copies of this information should be stored with the rest of the subject data, and be appropriately indexed and
referenced.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 41
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Source
FDA
ICH
ICH
ICH
ICH
ICH
ICH
Regulation/Guideline
Guidance for Industry: Drug-Induced Liver Injury:
Premarketing Clinical Evaluation
(July 2009)
Description/Wording
Section IV: Clinical Evaluation of DILI
For subjects who meet Hy’s Law criteria (altered liver function), additional data must be collected. Section C lists the
CRF variables that must be collected.
Section II: Definitions and Terminology Associated With Clinical Safety Experience
Provides definitions for terms commonly used in safety data reporting, such as adverse event, serious adverse event
and expectedness.
By referencing the information to be submitted, it suggests a minimal set of variables to capture the key information.
Defines processes for expedited reporting, including what must be reported and how to determine reporting timeframe
E2A Clinical Safety Data Management: Definitions
Outlines assessing safety during blinded treatment, associated with placebo treatment, and post-study events
and Standards for Expedited Reporting
Does not go into any detail around individual data points required, although it contains some inferences about SAE
narrative content—The description of the information required for expedited reporting of serious adverse events
outlines further information that may be required to characterize deaths, including items such as allergy, drug or
alcohol abuse; family history; findings from special investigations. An autopsy or other post mortem findings must be
included when available. This may have implications for data to be collected in every study.
E2B(R2) Maintenance of the ICH Guideline on
This document lists data points that must be transmitted when sending expedited AE reports, including in some cases
Clinical Safety Data Management: Data Elements suggested codelists (e.g., action taken with respect to study drug). While these are often handled by the Regulatory
for Transmission of Individual Case Safety Reports departments in companies, there should be discussions with CDM to determine the relationship of this information to
http://www.ich.org/
the clinical database.
This implementation guide provides a standardized definition of all data elements to be transmitted for ICSRs.
Section 3.2: Provides code sets, terminologies, and vocabularies
E2B (R3) Electronic Transmission of Individual
Section 3.3: Provides specifications for the transmission of ICSRs. Includes information on the expected format of
Case Safety Reports (ICSRs)
data elements
This covers the requirements for periodic reporting of safety information after product launch. It doesn’t list variables
in the manner of E2B, but instead focuses on the frequency and timing of safety updates, how to structure the reports,
E2C Clinical Safety Data Management: Periodic
the information the reports should contain (e.g., subject exposure), and some considerations around the need to track
Safety Update Reports For Marketed Drugs
and report events internationally. It is more applicable to the processes around managing AE data than the data
structure and variables themselves.
Section 2: Definitions and Terminology Associated with Post-Approval Drug Safety Experience: provides definitions
for terms commonly used in safety data reporting in the post-approval phase, including adverse event, serious adverse
event, and expectedness.
Section 4: Standards for Expedited Reporting: defines processes for expedited reporting, including minimum criteria
E2D Post-Approval Safety Data Management:
for reporting and how to determine reporting timeframe.
Definitions and Standards for Expedited Reporting Section 5: Good Case Management Practices: does not go into any detail around individual data points required,
although it contains some inferences about SAE narrative content. An autopsy or other post mortem findings should
be included when allowed.
Attachment: Recommended Key Data Elements for Inclusion in Expedited Reports of Serious Adverse Drug
Reactions
Section 9: discusses rating AEs in terms of severity or relationship to drug. It also states that the report should define
how consistency in applying the ratings was achieved between sites. Be clear in defining the severity and relationship
categories, and include the definitions in CRF completion guidelines.
E3 Structure and Content of Clinical Study Reports
Section 12.2: provides description of the kinds of safety summaries that must be conducted for AEs. These include
summarization of AEs by body system, by intensity if used, by relationship to treatment if collected, and by treatment
emergence. Summaries should include lab findings and vital signs changes identified as AEs. Even if AEs are
Page 42
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Source
Regulation/Guideline
ICH
E6 (R1) Guideline for Good Clinical Practice
ICH
E9 Statistical Principles for Clinical Trials
NCI
CTEP Guidelines, Adverse Event Reporting
Requirements
Description/Wording
categorized by relationship and/or treatment emergence, all AEs should be included in the summaries. Although E3
does not require that relationship to study drug be captured, the EU Directive on AEs (April 2006) does require it.
There must be a way to determine treatment emergence (both for increases in severity and in frequency). Labs and
vital signs must be mergeable with AEs data, or somehow accessible.
Section 12.2.3: describes the general analysis approach for AEs, including examination of relationship to dosage level
if that seems appropriate.
Section 12.2.4: provides a list of variables that must be included in AE listings (i.e., that need to be collected). These
include typical AE variables, as well as study drug treatment data and concomitant treatment data and assessment of
seriousness.
While the FDA does not require listings of AE data if AE data have been provided electronically, ICH guidelines do
still request these.
Section 12.3: Discusses the display of Deaths & other Serious Adverse Events (SAEs); they should be split out and
discussed separately in the report but essentially the same data are required for display. Deaths occurring both during
the study as well as during the post treatment follow-up period are to be included. The guideline includes a
description of what the subject narrative must discuss, including a list of data points. In the list of appendices, the
guidelines indicate that CRFs for subjects who died must be submitted. This implies that death data must be either
collected for all studies on CRFs or on the serious AE collection instruments. Additionally, it requires that
“significant” AEs be split out, i.e., AEs that were not serious, but required some significant concomitant therapy or
intervention. This implies that AEs requiring significant concomitant treatment (either pharmacological or nonpharmacological) be specifically identifiable.
1.2, Glossary, Adverse Event: defines “Adverse Event”
4.11, Investigator, Safety Reporting: investigator responsibilities for reporting safety issues to sponsors, specifically
deaths, other SAEs, Lab AEs and AEs of special interest in a particular protocol.
5.16, Safety Information: sponsor responsibilities for ongoing review of safety information; notification of
investigators.
5.17 Adverse Drug Reaction Reporting: spells out the sponsor’s regulatory responsibility to report all serious and
unexpected AEs to IRBs, investigators and regulatory authorities in accordance with ICH E2A.
Sponsor responsibilities of periodic safety updates to regulatory authorities.
Most of the rest of GCPs have more to do with actions around data, rather than the data themselves.
This guideline is fairly general in its observations, but provides some insight into regulatory expectations.
Section VI: Evaluation of Safety and Tolerability: contains considerable discussion about appropriate approaches to
the analysis and reporting of safety data, including summarizing by severity, start and duration of AE, as well as
potential subpopulation analyses (e.g., sex, age). Also provides definition for Treatment Emergence.
Section VII: Reporting: provides a supplement to the info contained in E3.
A document produced by the National Cancer Institute’s Cancer Therapy Evaluation Program. It provides definitions
for terms used in reporting AEs, lists the information that should be included when reporting different kinds of AEs
resulting from different kinds of treatments for cancer (e.g., marketed, pre-registration). These requirements are
somewhat different from those for other types of diseases, due in part to the severity of the disease and the toxicity of
the treatments. Among other information, it includes the definitions for AE Grades that are used in oncology in place
of severity assessments.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 43
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Appendices
Appendix A: Glossary, Acronyms, and Definitions
The following abbreviations and terms may be used in this document. Additional definitions can be found in the
CDISC Glossary available at http://www.cdisc.org/cdisc-glossary.
Abbreviation /
Acronym / Term
AE
AESI
AR
BRIDG
Case
CDASH
CDISC
CDM
CDMS
Collected
Controlled
Terminology
CRF
CTCAE
Dataset
Derived
Domain
Drug Safety
Organization
eCRF
E2B Message
EDC
EMEA
FDA
GCP
Page 44
November 25, 2013
Definition
Any untoward medical occurrence in a patient or clinical trial subject administered a
medicinal product and which does not necessarily have a causal relationship with this
treatment. (Directive 2001/20/EC, Detailed Guidance ENTR/CT 3, ICH-E2A)
Adverse Events of Special Interest
Adverse Reaction: all untoward and unintended responses to an investigational medicinal
product related to any dose administered; (Directive 2001/20/EC, Detailed Guidance
ENTR/CT 3, ICH-E2A)
Biomedical Research Integrated Domain Group
An observation requiring investigation, and includes problems that might or might not
involve individual or groups of investigative subjects. [HL7 Patient Safety]
Clinical Data Acquisition Standards Harmonization Project. The name for the project that
delivers basic data collection fields (this document)
Clinical Data Interchange Standards Consortium, a Collaborative Group Member
Clinical Data Management
Clinical Data Management System
Within this document collected refers to information that is recorded and/or transmitted to
the sponsor. This includes data entered by the site on CRFs/eCRFs as well as vendor data
such as core lab data. This term is a synonym for “captured”.
A finite set of values that represent the only allowed values for a data item. These values
may be codes, text, or numeric. A codelist is one type of controlled terminology.
Case report form (sometime case record form) A printed, optical, or electronic document
designed to record all required information to be reported to the sponsor for each trial
subject.
Common Terminology Criteria for Adverse Events
A collection of structured data in a single file
Within this document derived refers to information that is not directly entered into the
specific data field by the investigator site or by a core lab. This category includes auto
encoded data, calculated data and similar electronically generated data, but not
prepopulated fields.
A collection of observations with a topic-specific commonality about a subject
The group of persons at an institution who oversee the collection, detection, assessment,
monitoring, and reporting to appropriate authorities of adverse effects with pharmaceutical
products
Electronic case report form
Electronically transmittable individual case safety report. (ICSR)
Electronic data capture
The European Medicines Agency. A decentralized body of the European Union, main
responsibility is the protection and promotion of public and animal health, through the
evaluation and supervision of medicines for human and veterinary use.
Food and Drug Administration Part of the US Department of Health and Human Services
Agency. The regulatory authority for all pharmaceuticals (including biologics and
vaccines) and medical devices in the US.
Good Clinical Practice
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Abbreviation /
Acronym / Term
HL7
ICH
ICH E2A
ICH E2B
ICH E2C
ICH E3
ICH E4
ICH E5
ICH E6 (R1)
ICH E9
ICH E11
ICH E14
ICSR
IND
IRB
ISO 8601
MedDRA
NCI
NCI: EVS
NICHD
NIH
NLM
Preprinted
(pre-printed)
Prepopulated
(pre-populated)
PRN
SAE
SDTM
SDTMIG
Definition
Health Level 7
International Conference on Harmonization of Technical Requirements for Registration of
Pharmaceuticals for Human Use
ICH guidelines on Clinical Safety Data Management: Definitions and Standards for
Expedited Reporting
ICH guidelines on Clinical Safety Data Management: Data Elements For Transmission Of
Individual Case Safety Reports
ICH guidelines on Clinical Safety Data Management: Periodic Safety Update Reports For
Marketed Drugs
ICH guidelines on Structure and Content of Clinical Study Reports
ICH guidelines on Dose-response Information to Support Drug Registration
ICH guidelines on Ethnic Factors in the Acceptability of Foreign Clinical Data
ICH guideline for Good Clinical Practice
ICH guidelines on Statistical Principles for Clinical Trials
ICH guidelines on Clinical Investigation of Medicinal Products in the Pediatric Population
ICH guidelines on the Clinical Evaluation Of QT/QTc Interval
'Individual Case Safety Report' The complete information provided by a reporter at a
certain point in time to describe an event or incident of interest. The report can include
information about a case involving one subject or a group of subjects. (prEN27953 Human
Pharmaceutical Reporting)
Investigational New Drug. IND application required by the US FDA before clinical trials of
a new drug or new biological agent may be initiated.
Institutional Review Board. Under FDA regulations, an IRB is an appropriately constituted
group that has been formally designated to review and monitor biomedical research
involving human subjects
International Organization for Standardization document of character representation of
dates, date/times, intervals, and durations of time
Medical Dictionary for Regulatory Activities (new global standard medical terminology
designed to supersede other terminologies (such as COSTART and ICD9) used in the
medical product development process
U.S. National Cancer Institute (NIH)
U.S. National Cancer Institute (NIH) Enterprise Vocabulary Services
National Institute of Child Health and Human Development, a Collaborative Group
Member
U.S. National Institutes of Health
U.S. National Library of Medicine
Items that are part of the original printing on a paper CRF. For example the unit required
for a response, such as “years” for an age question. These data may or may not be stored in
the database.
Items that are part of the eCRF (or data collection device) that are not enterable/modifiable
(see also preprinted). These data are stored in the study database.
As Needed (Latin: pro re nata)
Serious Adverse Event or serious adverse reaction’: any untoward medical occurrence or
effect that at any dose results in death, is life-threatening, requires hospitalization or
prolongation of existing hospitalization, results in persistent or significant disability or
incapacity, or is a congenital anomaly or birth defect; (Directive 2001/20/EC, Detailed
Guidance ENTR/CT 3, ICH-E2A)
Study Data Tabulation Model
SDTM Implementation Guide
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 45
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Abbreviation /
Acronym / Term
SUSAR
Suspect Drug
Study Treatment
WHO
WHO ART
WHO Drug
Page 46
November 25, 2013
Definition
Serious Unexpected Serious Adverse Reaction: an adverse reaction, the nature or severity
of which is not consistent with the applicable product information (e.g. investigator's
brochure for an unauthorized investigational product or summary of product characteristics
for an authorized product). (Directive 2001/20/EC, Detailed Guidance ENTR/CT 3, ICHE2A)
The intervention that is attributed as to being the cause of the Serious Adverse Event
The drug, device, therapy, or process under investigation in a clinical trial which has an
effect on outcome of interest in a study: e.g., health-related quality of life, efficacy, safety,
pharmacoeconomics. Synonyms: intervention, therapeutic intervention, medical product.
World Health Organization
World Health Organization Adverse Reaction Terminology (WHO-ART) has been
developed over more than 30 years to serve as a basis for rational coding of adverse
reaction terms.
World Health Organization Drug Dictionary
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Appendix B: Project History/Background
The healthcare industry and specifically those engaged in developing new products, faces stringent regulatory
requirements when undertaking clinical research. The safety of the subject is paramount. Consequently, the accurate
and prompt reporting of serious adverse events (SAEs) is an essential activity in any clinical trial. Clinical trial sites
have direct contact with subjects and provide the information about each SAE to the sponsor and its medical
monitors. In the pre-market environment, once an SAE has been determined to be reportable, the sponsor’s Drug
Safety department may have the responsibility to ensure compliance with a Health Authority’s regulatory reporting
requirements. In the post-market setting, the ongoing safety profile of a drug is largely the responsibility of the
sponsor’s Drug Safety department, including reporting, pharmacovigilance, and periodic safety updates. Thus, the
responsibilities of the sponsor’s Drug Safety department include, but are not limited to, the following:
1.
2.
3.
4.
direct communications with the site for information relevant to the SAE/case
sponsor-level assessment of the case, in addition to the assessment provided by the site investigator
safety reporting for SAEs that meet reporting criteria, i.e., SUSARs (Suspected, Unexpected, Serious
Adverse Events)
overall responsibility for the safety profile of investigational and marketed products
The number of adverse events reported for a globally marketed product will be significantly greater than those
reported for a product in development. However, the amount of data for each single report originating from products
in development is higher due to the requirement for expedited reporting and review by qualified personnel for
investigational products.
The CDASH SAE project was started in 2010 with the following goals:
• reduce duplication of data collection
• provide guidance to sites on the SAE data collection
• provide the needed (and standardized) metadata for Safety Groups to support them in meeting regulatory
reporting requirements
The outcome thus far from this initiative has been the creation of a new CDASH SAE domain and its attendant
variables.
During the preparation of the first version of this CDASH SAE Supplement, work continued on the next version of
the ICH Data Elements for Transmission of ICSRs, E2B R3. While the E2B R3 version is being finalized, this
document is based on the existing E2B R2. When E2B R3 is finalized, CDASH will provide an updated version of
this supplement.
The CDASH E2B project team aims to increase efficiencies in the industry regarding SAE reporting. Whilst EDC
usage is promoted by this initiative, its outcomes are equally applicable and helpful for those sponsors who still
capture study data on paper. Electronic data capture (EDC) is recognized as an efficient and time saving method for
capturing clinical data. EDC also offers a more efficient process for SAE information capture than the traditional
paper form; sponsors can use information already available in the Clinical Data Management System (CDMS) to
populate the same data elements on an SAE report form. Typically, such data are housed in a clinical study database.
All SAE data that are not extracted from the clinical study database are typically housed in a separate safety
database. The relationship between drug safety data and clinical trial data that commonly manifests in two distinct
data acquisition processes can be enhanced by minimizing duplicative data collection and easing the safety data
reconciliation processes.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 47
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Appendix C: Data Elements from ICH E2B R2
A: Administrative and Identification Information
A.1 Identification of the case safety report
A.1.1 Identification of the country of the primary source
A.1.2 Identification of the country where the reaction/event occurred
A.1.5 Seriousness
A.1.5.1 Serious: Yes/No
A.1.5.2 Seriousness criteria
A.2 Primary source(s) of information
A.3 Information on sender and receiver of case safety report
B: Information on the Case
B.1 Patient characteristics
B.1.1 Patient
B.1.2 Age information
B.1.2.1 Date of birth
B.1.2.2 Age at time of onset of reaction/event
B.1.5 Sex
B.1.6 Last menstrual period date
B.1.7 Relevant medical history and concurrent conditions
B.1.8 Relevant past drug history
B.1.9 In case of death:
B.1.9.1 Date of death
B.1.9.4 Autopsy determined cause(s) of death
B.1.10 For a parent-child/fetus report, information concerning the parent
B.2 Reaction(s)/Event(s)
B.2.i.0 Reaction/event as reported by the primary source
B.2.i.4 Date of start of reaction/event
B.2.i.5 Date of end of reaction/event
B.2.i.8 Outcome of reaction/event at time of last observation
B.3 Results of tests and procedures relevant to the investigation of the patient:
B.3.1a Structured information (repeat as necessary)
B.3.1b Date
B.3.1c Test
B.3.1d Result
B.3.2 Results of tests and procedures relevant to the investigation
B.4 Drug(s) Information
B.4.k.2 Drug identification
B.4.k.5 Structured dosage identification
B.4.k.8 Route of administration
B.4.k.11 Indication for use in the case
B.4.k.12 Date of start of drug
B.4.k.12 Date of last administration
B.4.k.16 Action(s) taken with drug
B.4.k.17 Effect of rechallenge (or re-exposure), for suspect drug(s) only
B.4.k.18 Relatedness of drug to reaction(s)/event(s) (repeat as necessary)
B.5 Narrative case summary and further information
B.5.1 Case narrative including clinical course, therapeutic measures, outcome and additional relevant
information
B.5.2 Reporter's comments
Page 48
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
B.5.3 Sender's diagnosis/syndrome and/or reclassification of reaction/event
B.5.4 Sender's comments
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 49
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Appendix D: Examples of Study Scenarios where ParentChild Data could be Submitted
Study Scenario
Eligibility criteria:
women of childbearing age
pregnancy exclusion
Eligibility criterion:
Pregnant women
Eligibility criterion:
Pregnant women
Eligibility criterion:
Male subjects with
female partners of
child-bearing age
Page 50
November 25, 2013
Expected impact on
Possible reports
Domains were these are recorded
subject
Unplanned pregnancy AE on subject (pregnant AE data on subject identifier
exposure to study drug;
woman)
AE data on fetus linked to subject
identifier (no fetal identifier).
must follow until delivery AE on fetus
Planned exposure to study Study objectives relate
drug
only to the pregnant
women
AE data on mother (subject identifier)
Pregnancy outcome specifically captured
on CRF for mother; no specific identifier
for fetus/infant.
AE data on fetus/infant linked to mother
Planned exposure to study Study objectives relate to AE data on mother (subject identifier).
drug
pregnant women and
AE data on infant/child (subject
offspring (follow-up
identifier).
could be only to birth, or Data on mother-infant/child are still
could be X time after
linked with separate Identifiers
birth)
Unplanned pregnancy AE on subject’s partner AE data on subject’s partner linked to
exposure to study drug;
(pregnant woman)
Subject Identifier.
must follow until delivery AE on fetus
AE data on fetus linked to subject
identifier (no fetal identifier).
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Appendix E: Narrative
Content Elements for the Narrative
Existing ICH documents E2A, E2D, E2B R2 and E2B R3 (in process) provide some guidance on the information
useful to describe the adverse event and the narrative. This appendix provides further detail and organization of the
narrative to complement the guidance provided by the ICH documents, in a structured manner.
Please include all information in the narrative description that is relevant for a complete understanding of the
event/reaction to allow for a causality assessment of the product. Information that is already included elsewhere, but
may not contribute to the clinical understanding and assessment of the SAE, do not need to be repeated in the
narrative.
All information relevant to the case may not be available at the time of the report. However, it is expected that the
site investigator/staff will perform due diligence to obtain such information that will contribute to the full
understanding and assessment of the case.
I. Adverse Event:
• Intro statement about subject i.e. age, sex, AE term, drug exposure
• Full focused, factual, and clear description of reaction(s), including body site and severity
• Description of the reported signs and symptoms
• Setting (e.g., hospital, out-patient clinic, home, nursing home)
• Specific diagnosis for the reaction
• Onset date (and time) of reaction
• Stop date (and time) or duration of reaction
• De-challenge and re-challenge information
II. Evaluation:
• Full description of the workup including history and physical exam
• All relevant laboratory data
• All relevant diagnostic tests and results
III. Intervention Regarding the Adverse Event:
• Treatment provided or required to mitigate medical consequences
• Did treatment have to be provided in a hospital setting?
• Hospitalization dates
• Response to treatment
IV. Outcome of the Adverse Event
i. Non-Fatal:
• Did the event resolve
• Did the subject recover
• Was there any sequelae
ii. Fatal:
• Stated cause of death
• Relevant autopsy or post-mortem findings, including coroner’s report
• If unknown, perform due diligence to obtain necessary information to ascertain cause of death
V. Other Information
• Provide all relevant information that can facilitate the assessment of the case such as medical history
including allergies, drug or alcohol abuse; family history, social history; findings from special
investigations
• Provide all concomitant medications. Include dosing details and indications
VI. Assessment
i. By the reporter (site):
• Confirm possible diagnoses
• For each diagnosis, determine the relatedness of the product to the reaction(s)/event(s)
ii. By the sender (sponsor):
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 51
November 25, 2013
CDASH Serious Adverse Event Supplement v1
• Provide comment or any other issues considered relevant
• Opportunity to combine signs and symptoms that were reported into a succinct diagnosis; include
reasoning
• Confirm or describe disagreement with reporter’s assessment
• If disagreement, provide alternatives to diagnoses and/or causality conclusion(s)
Narrative Template
This narrative template is shared as an example of a complete narrative description of an individual case safety
report (single case SAE report). This structure will allow for a complete understanding of the event/reaction and a
causality assessment of the product. Please complete the narrative with the information suggested, and add further
details if they are clinically relevant for the description of this SAE. Conversely, if there are sections that are not
applicable to the case, these do not need to be included.
All information relevant to the case may not be available at the time of the report. However, it is expected that the
site investigator/staff will perform due diligence to obtain such information that will contribute to the full
understanding and assessment of the case.
•
•
•
•
•
•
•
•
This is a [Age] year old [Race] [Male/Female] in [Study] who reported [Primary AE] on [Date of AE]. The
subject was enrolled into study on [Date Enrolled]. Study medication was started on [Date] at [Dose],
which is [Study Day _/Week _], taken for [Duration]. Include all changes in dose and frequency. The event
occurred during the [Screening/Treatment/Follow-up] Phase.
If fetus: provide [Gestational Age], (or mother’s LMP), at time of event. Also, [Gestational Age/Trimester]
at first drug exposure and duration of exposure. If birth, provide details of [Infant Status] at birth. If
hospital stay is complicated, provide details of hospital stay.
Provide details of the [SAE] in chronological order, along with other [Signs/Symptoms]. Start with date
(and time, if relevant) and description of signs and symptoms; provide details of [Physical Exam], along
with all relevant [Procedures] and [Lab Results].
Specify the diagnosis that was made based on symptoms and test results.
Specify the seriousness criteria that apply for the SAE and the dates when the seriousness criteria apply. If
hospitalization, provide [Dates Hospitalization], describe relevant [Hospital Course], and any additional
[Diagnostic Work-up], [Procedures/Tests and Results]. If life-threatening, specify the measures that were
taken for the immediately life-threatening situation. If death, report date of death and cause of death,
including autopsy or post-mortem findings when available. If medically significant, provide a rationale for
the medical significance.
Provide details of [Treatment] and [Treatment Rationale] on basis of [Findings/Test Result(s)]. Describe
[Treatment Response]. Include Dechallenge/Rechallenge information.
Provide [Outcome/Discharge Diagnosis], and any [Follow-up Information]. List [Discharge Meds]. If fatal
outcome, [Cause of Death] and provide all relevant information and include records, such as autopsy
report.
Provide pertinent [Past Medical Hx], [Family Hx], [Concomitant Meds], [Alcohol/Tobacco/Substance Use]
and any previous similar [AEs].Provide assessment of causality and rationale for the conclusion.
Page 52
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
Appendix F: Authors
Name
Alec Vardy
Amy Palmer
Barry Burnstead
Cathy Schleuning
Gary Walker
Katie Carothers
Lauren Shinaberry
Region
US
US
EU
US
US
US
EU
Ling Chin, MD, MPH
US
Melissa Binz
Mike Ward
Monica Mattson
Rhonda Facile
Roland Franke
Shannon Labout
Sean Neal
Sonia Araujo
Tracy Sanders
US
US
US
US
EU
US
US
EU
US
Affiliation
Onyx Pharmaceuticals
CDISC
Select CRO
UCB BioSciences, Inc.
Quintiles
CDISC
Business & Decision Life Sciences
GDU Clinical Trials Consulting, LLC
Formerly Office for Policy in Clinical
Research Operations (OPCRO)
Division of AIDS, NIAID, NIH,
DHHS
Novartis
Lilly
Celgene
CDISC
PRA International
SDC Clinical
Medidata Solutions
Medidata Solutions
Foresight Group
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Email Address
avardy@onyx.com
apalmer@cdisc.org
bburnstead@selectcro.com
Cathy.Schleuning@ucb.com
gary.walker@quintiles.com
kcarothers@cdisc.org
lauren.shinaberry@businessdecision.com
gcpclinicaltrials@gmail.com
melissa.binz@novartis.com
ward_michael_j@lilly.com
MMattson@celgene.com
rfacile@cdisc.org
FrankeRoland@PRAintl.com
slabout@sdcclinical.com
sneal@mdsol.com
saraujo@mdsol.com
TSanders@ForesightGroup.com
Page 53
November 25, 2013
CDASH Serious Adverse Event Supplement v1
Appendix G: Representations and Warranties, Limitations of
Liability, and Disclaimers
CDISC Patent Disclaimers
It is possible that implementation of and compliance with this standard may require use of subject matter covered by
patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any
claim or of any patent rights in connection therewith. CDISC, including the CDISC Board of Directors, shall not be
responsible for identifying patent claims for which a license may be required in order to implement this standard or
for conducting inquiries into the legal validity or scope of those patents or patent claims that are brought to its
attention.
Representations and Warranties
Each Participant in the development of this standard shall be deemed to represent, warrant, and covenant, at the time
of a Contribution by such Participant (or by its Representative), that to the best of its knowledge and ability: (a) it
holds or has the right to grant all relevant licenses to any of its Contributions in all jurisdictions or territories in
which it holds relevant intellectual property rights; (b) there are no limits to the Participant¹s ability to make the
grants, acknowledgments, and agreements herein; and (c) the Contribution does not subject any Contribution, Draft
Standard, Final Standard, or implementations thereof, in whole or in part, to licensing obligations with additional
restrictions or requirements inconsistent with those set forth in this Policy, or that would require any such
Contribution, Final Standard, or implementation, in whole or in part, to be either: (i) disclosed or distributed in
source code form; (ii) licensed for the purpose of making derivative works (other than as set forth in Section 4.2 of
the CDISC Intellectual Property Policy (³the Policy²)); or (iii) distributed at no charge, except as set forth in Sections
3, 5.1, and 4.2 of the Policy. If a Participant has knowledge that a Contribution made by any Participant or any other
party may subject any Contribution, Draft Standard, Final Standard, or implementation, in whole or in part, to one or
more of the licensing obligations listed in Section 9.3, such Participant shall give prompt notice of the same to the
CDISC President who shall promptly notify all Participants.
No Other Warranties/Disclaimers. ALL PARTICIPANTS ACKNOWLEDGE THAT, EXCEPT AS PROVIDED
UNDER SECTION 9.3 OF THE CDISC INTELLECTUAL PROPERTY POLICY, ALL DRAFT STANDARDS
AND FINAL STANDARDS, AND ALL CONTRIBUTIONS TO FINAL STANDARDS AND DRAFT
STANDARDS, ARE PROVIDED ³AS IS² WITH NO WARRANTIES WHATSOEVER, WHETHER EXPRESS,
IMPLIED, STATUTORY, OR OTHERWISE, AND THE PARTICIPANTS, REPRESENTATIVES, THE CDISC
PRESIDENT, THE CDISC BOARD OF DIRECTORS, AND CDISC EXPRESSLY DISCLAIM ANY
WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR OR
INTENDED PURPOSE, OR ANY OTHER WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL,
FINAL STANDARDS OR DRAFT STANDARDS, OR CONTRIBUTION.
Limitation of Liability
IN NO EVENT WILL CDISC OR ANY OF ITS CONSTITUENT PARTS (INCLUDING, BUT NOT LIMITED
TO, THE CDISC BOARD OF DIRECTORS, THE CDISC PRESIDENT, CDISC STAFF, AND CDISC
MEMBERS) BE LIABLE TO ANY OTHER PERSON OR ENTITY FOR ANY LOSS OF PROFITS, LOSS OF
USE, DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, OR SPECIAL DAMAGES, WHETHER
UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS
POLICY OR ANY RELATED AGREEMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE
OF THE POSSIBILITY OF SUCH DAMAGES.
Note: The CDISC Intellectual Property Policy can be found at:
http://www.cdisc.org/about/bylaws_pdfs/CDISCIPPolicy-FINAL.pdf
Page 54
November 25, 2013
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
CDASH Serious Adverse Event Supplement v1
CDISC, Inc.
401 West 15th Street, Suite 975, Austin, Texas 78701
http://www.cdisc.org
© Copyright 2013 by CDISC, Inc.
All rights reserved. No part of this publication may be reproduced without the prior written consent of CDISC.
CDISC welcomes user comments and reserves the right to revise this document without notice at any time. CDISC makes no representations or
warranties regarding this document. The names of actual companies and products mentioned herein are the trademarks of their respective owners.
CDISC® and the CDISC logo are trademarks or registered trademarks of CDISC, Inc. and may be used publicly only with the permission of
CDISC and require proper acknowledgement. Other listed names and brands are trademarks or registered trademarks of their respective owners.
© 2013 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
Final
Page 55
November 25, 2013