Tập hợp các biến tiêu chuẩn CDASH cho báo cáo ca bệnh

Orientation

This document outlines essential standards for collecting clinical trial data, serving as a guide for professionals involved in the planning, management, and analysis of clinical trials Key roles such as Clinical Investigators, Medical Monitors, Clinical Research Associates, Study Coordinators, Data Managers, Statistical Programmers, Biostatisticians, and Drug Safety personnel are all addressed, emphasizing their responsibilities in ensuring the integrity and accuracy of clinical trial data collection and management.

CDASH standards are essential components of the broader CDISC standards framework, designed to offer a complete solution for managing clinical data throughout the entire process, from data capture to submission.

Introduction

Terminology

The CDASH data collection variables utilize terminology that is currently in production or under development by the CDISC Terminology Team This production terminology is available through the National Cancer Institute’s Enterprise Vocabulary Services (NCI EVS), accessible at [NCI EVS](http://www.cancer.gov/cancertopics/terminologyresources/page6) In the CDASH final document, only the names of code lists from NCI’s EVS will be included for coded variables Additionally, terminology suggested by CDASH teams is submitted to the CDISC terminology team for validation through the CDISC consensus process.

Best Practice (General Recommendations and Observations Applicable to all Domains)

Implementation of CDASH Recommendations

The CDASH project aims to streamline data collection at investigative sites by identifying essential fields from clinical, scientific, and regulatory perspectives By minimizing the number of data fields, it reduces the likelihood of errors and the resources required for monitoring and management While the Study Data Tabulated Model (SDTM) outlines a comprehensive set of potential data, CDASH specifically highlights a core set of recommended variables expected in most case report forms (CRFs) This approach encourages sponsors to critically evaluate which additional fields may be necessary based on their study protocols and business practices Until therapeutic area-specific fields are standardized, these must be incorporated into CDASH recommendations to meet protocol-specific needs.

SDTM and CDASH are interconnected but serve different purposes, leading to occasional discrepancies between them, such as the inclusion of derived data in SDTM, which is not permitted in CDASH during data collection CDASH project teams identify basic data collection fields that are mapped to the SDTM, ensuring compliance with the SDTM Implementation Guide (IG) This mapping includes providing SDTM variable names for reviewers' convenience, and all "required" SDTM variables are addressed in CDASH recommendations However, the CDASH teams have opted not to replicate other sections of the SDTM standard, advising reviewers to consult the CDISC SDTM IG for additional information.

Core Designations for Basic Data Collection Variables

In order to facilitate classification of the different types of data collection variables, the following categories were used:

Highly Recommended = A data collection field that should be on the CRF (e.g., a regulatory requirement)

Recommended or conditional data collection fields on the Case Report Form (CRF) are essential for specific cases or to meet therapeutic area (TA) requirements These fields may also be documented in other sections of the CRF or sourced from additional data collection methods.

Optional = A data collection variable that is available for use if needed (may be recorded elsewhere in the CRF or from other data collection sources)

Highly recommended and conditional data collection variables are anticipated to be included in most Case Report Forms (CRFs) Sponsors are expected to identify additional data collection variables based on therapy area-specific requirements, study protocols, and other relevant factors.

It is essential for sponsors to establish standards that reflect the specific needs of clinical development stages and therapeutic areas, rather than creating them on a trial-by-trial basis within the organization.

Introduction to Best Practices

The instrument used to collect data in a clinical trial is arguably the most crucial document, second only to the trial protocol The integrity of the data hinges on the quality of this instrument; without accurate data points, meaningful analysis becomes unattainable Thus, it is essential to prioritize the design, development, and quality assurance of the data collection instrument to ensure reliable trial outcomes.

Recommended Methodologies for Creating Data Collection Instruments

1 NECESSARY DATA ONLY: CRFs should avoid collecting redundant data and focus on collecting only the data needed to answer the protocol questions and to provide adequate safety data

Collecting data that does not align with specific protocol requirements or is not intended for product submission is both expensive and time-consuming Therefore, it is essential to gather only the data necessary for analysis on the Case Report Form (CRF) Additionally, all collected data should undergo thorough review and cleaning to ensure accuracy and reliability.

• When available, the Statistical Analysis Plan needs to be reviewed to ensure that the parameters needed for analysis are collected and can be easily analyzed

2 CONTROL: Control the process of designing, printing, distributing CRFs, and accounting for unused CRFs

• The CRF development lifecycle should be a controlled process, using a formalized, documented process that incorporates design, review, approval and versioning steps

• The CRF development process should be controlled by SOPs covering, at a minimum, design, development, QA, approvals, version control and site training

Involving the team responsible for designing data collection instruments in the development of the study protocol is crucial This team should include experts in various fields, such as statistics, programming, data management, clinical operations, science, regulatory affairs, and pharmacovigilance, to ensure a comprehensive and effective Case Report Form (CRF) design.

Ideally, the CRF should be developed in conjunction with the Protocol and SAP

All research-related data on the CRF should be addressed in the protocol to specify how and when it will be collected

• Staff involved in CRF design should review the protocol to ensure that it is possible to collect the proposed data

• Statisticians should review the CRF against their planned analyses to make sure all required data will be collected in an appropriate form for those analyses

• Clinical Operations staff should review the CRF to make sure the questions are unambiguous and that it is possible to collect the data being requested

• Scientific experts should provide input on the efficacy and/or safety data collection fields, and educate the CDM staff on the type and methods of collecting those data

• Regulatory experts should review the CRF for compliance with all applicable regulations

• Data Entry is an important “user” of the CRF and their perspective should be included in the review

4 SITE WORKFLOW: The team developing the data collection instruments needs to consider the workflow at the site and the standard of care

• The CRF needs to be quick and easy for site personnel to complete

The Case Report Form (CRF) should be structured to align with the sequence of assessments conducted by site personnel, ensuring a smooth workflow It is essential for Clinical Operations staff to evaluate the CRF for its compatibility with the site's operational processes.

• Although Clinical Data Management should make the final decisions about CRF design, those decisions should be informed by study and user requirements

To ensure consistent data collection across various compounds and therapeutic areas, it is essential to implement industry standards whenever feasible, while also developing in-house standards as necessary.

• Using data collection standards across compounds and therapeutic areas saves time and money at every step of drug development

• reduces production time for CRF design, and reduces review and approval time

• reduces site re-training and queries, and improves compliance and data quality at first collection

• facilitates efficient monitoring, reducing queries

• improves the speed and quality of data entry, and reduces the training burden in-house

• enables easy reuse and integration of data across studies, and facilitates ‘data mining’ and the production of integrated summaries

• reduces the need for new clinical and statistical programming with each new study

• reduces global library maintenance in the database

• addresses FDA Critical Path Opportunities (#44 and 45)

6 CLARITY: CRF Questions and completion instructions should not “lead” the site

Questions should be clear and unambiguous This includes making sure that the options for answering the question are complete (e.g., “Other”,

“None”) Data needs to be collected in a way that does not introduce bias or errors into the study data

7 TRANSLATIONS: Translations of CRFs into other languages should be a parallel process following the same set of steps with separate reviews and approvals by the appropriate experts

Cultural and language issues should be addressed appropriately during the process of translating CRFs to ensure the CRF questions have consistent meaning in all language versions

CRF questions should be as self-explanatory as possible, thereby reducing the need for instructions

Prompts and short instructions may be placed on the CRF page More detailed instructions may be presented in a CRF Completion Guideline for paper

CRFs, or in a context-sensitive help file for eCRFs

Instructions should be clear and concise For studies needing detailed guidance on conditional actions, include a brief prompt on the CRF page that directs users to the specific location for comprehensive instructions.

Instructions should be standardized along with the

CRF as much as possible

These also promote standardization, in that all sites will use the same conventions for completing the fields

Incorporating concise instructions and prompts on the Case Report Form (CRF) enhances the likelihood of them being read and adhered to, ultimately minimizing queries and lowering data cleaning expenses.

Well-structured Completion Guidelines improve the clarity of the Case Report Form (CRF) by offering concise instructions and prompts directly on the form By relocating lengthy instructions to a separate booklet, facing page, or checklist, the overall page count of the CRF is reduced, leading to several advantages.

• Decreased Data Management costs (e.g., decreased Data Entry costs)

• Allows CRF to be formatted so that the reader can easily identify the fields to be completed

• The format of the page is less cluttered which makes it easier for site personnel and monitors to identify fields with missing responses

Review design against standards Standards 3

Create draft based on protocol/standards

Review with cross functional team 2

Need to add to standards?

High Level Overview of CRF Development Best Practices:

• 1 Develop along with the Protocol (and Statistical Analysis Plan if available)

• 2 Develop as a cross-functional team

•All data for analysis collected?

•Possible to collect this way at the site?

•Appropriate data to address safety?

• 3 Implement and/or develop standards

FAQs on Best Practices for Creating CRF Content and Structure

Ref Question CRF Type Best Practice Recommendation Rationale

1 Should “Yes/No” questions be preferred over

“Tick/Check all that apply” questions?

For assessments that require composite responses, it is advisable to use 'Yes/No' questions for each individual symptom rather than 'Tick/Check all that apply' questions This approach enhances clarity and precision in gathering symptom data.

In certain cases, such as assessments where most options receive a 'No' response, exceptions to this recommendation may apply For instance, when collecting data on ECG abnormalities, there may be around 45 potential abnormalities listed, but only a limited number will actually be relevant.

• Yes/No questions provide a definite answer The absence of a response is ambiguous as it can mean “no” or that the response is missing

• 'Tick/Check all that apply' questions are occasionally needed where the number of options is high

2 Should there be a standard order for YES/NO response boxes and other standardized lists?

• It is recommended that a consistent order of Yes/No responses be used • A standard order of Yes/No response boxes facilitates the use of the CRF

To minimize bias in research, it is essential to present Yes/No responses in a consistent order Additionally, questions must be meticulously crafted to avoid introducing bias or steering the investigator toward a predetermined answer.

3 What date format should be used for subject and site completed CRF data?

• CDASH is recommending an unambiguous date format

CDASH advises using the date format DD-MMM-YYYY for all date collection fields in paper CRFs and electronic studies where the date is manually entered, regardless of whether the date components are collected together or separately.

• For non-English study data, use a character-based month abbreviation that is recognized in that language

• For electronic data capture, the user may be able to select a date from a calendar, and this would also meet the recommendation for an unambiguous date

Utilizing the international date format (DD-MMM-YYYY) ensures clarity and avoids confusion, as it presents dates in a universally understood manner For instance, the date 06/08/02 can be interpreted differently depending on the format, potentially leading to misunderstandings; however, using the standardized format eliminates such ambiguity.

• Note: If subject-completed CRF pages are translated into a local language, the international date may make it easier to translate the documents

• Dates are collected in a user-friendly format and then converted to the ISO 8601 format for submission

4 What time format should be used for subject and site completed CRF data?

CDASH recommends the use of a 24 hour clock using the HH:MM:SS format for recording times 00:00:00 would indicate midnight with the next day’s date

• As many of the HH:MM:SS elements should be used as are needed for a particular field

• Subject completed times may be recorded using a 12 hour clock and an A.M or P.M designation The time would then be transformed to a 24 hour clock in the system

• Times are collected in a user-friendly format and then converted to the ISO 8601 format for submission

5 Should calculated data items be recorded on the CRF?

• Calculated fields should not typically be recorded within the CRF when the raw data on which the calculation is based are recorded in the CRF

In certain situations, it is essential to document the calculated field within the Case Report Form (CRF) when making decisions regarding treatment or study conduct based on those calculations.

• It may also be useful to provide the site a step-by-step worksheet to record this data

• Data items which can be calculated from other data captured within the CRF are more accurately reported if they are calculated programmatically in-house using validated algorithms

• Capturing both the source data items and the calculated field would be a duplication of data

When utilizing a calculated field for making treatment or study conduct decisions, it is essential to include the results of that calculation on the Case Report Form (CRF) to justify the decision taken.

6 Should all data collected on

Paper • Data that are collected on CRFs should usually be databased

When data is not essential for reporting or analysis but is beneficial for the investigator or monitor, it is advisable to collect this information on a worksheet These worksheets, such as entry criteria or dose titration worksheets, are generally maintained at the investigator's site and are not transferred to an in-house database.

• Some fields, such as “Were there any Adverse Events – Yes/No” may need to be databased, but will not be reported in submission data

• Some fields, such as Investigator’s Signature, can be verified by the data entry staff, but cannot actually be databased

While the data captured on worksheets serve as supporting documentation for essential information gathered in the Case Report Form (CRF), they are not required for inclusion in the clinical database and do not need to be documented on the CRF itself.

• All such worksheets should be considered source documents or monitoring tools, and should be maintained at the site with the study files

7 Should “Was assessment x performed?” questions be collected and/or databased?

Should “Yes/No” exam completed be preferred over

“Check if not done” questions?

• The database should contain an indication that an assessment was not performed The mechanism for this may be different from system to system, or from paper to EDC

• In some cases this might be a “Yes/No – assessment completed” question, or

“check if not done” box; in others it might be a blank flag or list of values to indicate why data are missing

• This will provide a definitive indicator to both clinical and statistical programmers that a data field has missing data and has not been overlooked

• This will prevent unnecessary data queries to clarify whether an assessment has been performed

8 Should free text be an option for a response to a specific question?

(Also refer to the Comments

CDASH advises against the collection of free text comments and general comments pages, recommending that such data should be restricted to instances where there is a specific safety or therapeutic requirement for reporting or analysis This includes situations involving Adverse Events, Concomitant Medications, or Medical History.

CDASH advises that questions should be specific and clear instead of open-ended To enhance data collection, it is recommended that the protocol development team conducts a comprehensive review of the Case Report Form (CRF) and utilizes pre-defined response lists rather than relying on free text or solicited comment fields.

• The collection and processing of free text requires significant resources, and is of limited use when analyzing and reporting clinical data

• Sites may enter data into free text fields that should be recorded elsewhere

Entering text from these fields into the database is a time-consuming process that demands significant data management resources to ensure the accuracy of safety information and consistency with existing records.

9 Should data be pre-populated in the CRF?

• The CRF should be used as a tool to collect unknown study data • In general, study data should be collected and recorded by the site, not pre-populated

• Fields in the database or on the CRF may be pre-populated if the data are known to be the same for all subjects (e.g.,

MH CRF collects data for specific body systems - body systems may be pre-populated), or if the data are assigned to the subject (e.g., subject ID, site ID)

10 Should location of measurement and position of subject (e.g., oral temperature, blood pressure from right arm, etc.) be collected for each assessment?

Location data should be gathered only when there are multiple options available, and its inclusion is essential for conducting a meaningful analysis, such as comparing blood pressure readings from the supine position and both the right and left arms.

• Location options are only used when the protocol specifies

11 Should location of measurement and position of subject (e.g., oral temperature, blood pressure from right arm, etc.) be collected for each assessment?

• CDASH recommends not providing actual coding dictionaries to the site for adverse events, concomitant medications or medical history reported terms, as this may bias responses

• CDASH recommends that guidance be provided to the sites to ensure clear reporting of adverse events, concomitant medications or medical history

• For medications, this may include defining, for example, whether generic or trade names are permissible

Accurate medical coding requires a detailed understanding of medical history and adverse events; for instance, simply reporting "Diabetes" is insufficient without specifying the type Sites are encouraged to utilize precise medical terminology on forms, such as using "hyperglycemia" instead of the more general term "high blood sugar."

Common Identifier Variables

The following variables apply across all of the data collection domains 4

Clinical Database Variable Name (CDASH variables shaded)

Definition Instruction to Clinical Site Implementation /

STUDYID Unique Identifier for a study within a submission

This is typically pre-printed in the header of each CRF page

In an EDC study, this would be hard- coded into the study design

For data received from electronic data providers (e.g., central lab) this information should be provided to the e- data provider and verified during test and production receipts of the e-data receipts

2 Site Identifier SITEID Unique identifier for the site Record your clinical site’s identifier as defined by the sponsor

This is typically pre-printed in the header of each CRF page for single site studies

For studies with multiple sites, this field is typically left blank so that the number can be assigned per site

In an EDC study, this should be pre- populated in the screens provided to the site

For data received from electronic data providers (e.g., central lab) this information should be provided to the e- data provider and verified during testing of the e-data receipts

3 Subject SUBJID Subject identifier Record the identifier for the subject This is typically recorded in the header of each CRF page

In an EDC study the subject identifiers may be provided to the site using a pre- populated list in the system

For data received from electronic data providers (e.g., central lab) this information should be provided to the e- data provider and verified during testing of the e-data receipts

The subject identifier recorded in the CRF may be combined with other identifiers to produce the SUBJID, or may map directly to the SUBJID

4 Investigator INVID Investigator identifier Record the sponsor defined identifier for your site investigator

Study level – Not needed if SITEID is equivalent to INVID

5 Visit Identification VISIT Visit Name Protocol defined description of clinical encounter

This may be pre-printed in the header of each CRF page

In an EDC study the VISIT may be pre- populated or associated with particular CRFs

The VISIT, which is an alpha-numeric data field, may be used to derive other visit level data to the SDTM datasets

CDASH Domain Tables

Introduction

The CDASH domain tables are organized alphabetically It is important to note that the CRF layout was not included in the CDASH project scope Instead, the data collection variables are presented in the typical order found on a basic case report form.

The term "Case Report Form" (CRF) in this document encompasses both paper and electronic formats, while "data collection fields" refers to the common fields found on the CRF.

“variables” refers to what is seen in a clinical database.

Explanation of Table Headers

1 CDASH CRF Label/Question - Provides descriptive text on the type of data to be collected on the CRF

2 Clinical Database Variable Name - Lists the SDTM conforming variable name defined in the SDTM IG

The column labeled with shaded CDASH variables offers recommended names for data collection fields, such as CMONG and CMTTM These variable names resemble SDTM variables and serve as a valuable resource for deriving the necessary SDTM variables for reporting purposes.

3 Definition – Describes the purpose of the data collection field The text may or may not mirror the text in the SDTM IG (under variable label or CDISC notes)

4 Instructions to Clinical Site - Contains information for the clinical site on how to enter collected information onto the CRF

5 Implementation/Rationale for Sponsors - Contains further information on how to implement the CRF data collection variables

Note: “Instructions for the Clinical Site” and “Implementation/Rationale for Sponsors” are provided only for those data collection variables that are considered “Highly Recommended” and “Recommended/

6 CDASH Core: Contains the CDASH core designations for Basic Data Collection Variables (See

Section 3.2 for definitions of core designations)

Adverse Event – AE (Events)

The recommendations provided pertain to non-solicited or pre-specified adverse events It is expected that Sponsors will incorporate additional data variables as necessary to fulfill protocol-specific and other data collection needs, including therapeutic area-specific elements and any other requirements dictated by the protocol, business practices, and operating procedures.

Definition Instructions to Clinical Site Implementation/

AEYN General prompt question to aid in monitoring and data cleaning

Indicate if the subject experienced any adverse event If yes, include the appropriate details were indicated

The intent/purpose of collecting this field is to help with data cleaning and monitoring

Note: AEYN will not be included as part of the SDTM AE Domain for submission

The AE Number, also known as AESPID, is a sponsor-defined reference number that serves as an optional identifier This number may be pre-printed on the Case Report Form (CRF) as a specific line identifier or can be derived from the sponsor's operational database.

(e.g., line number on an Adverse Event page)

For paper AE CRFs, it can be beneficial to use a sequence number in a data query to clearly communicate to the site the specific record in question

3 Adverse Event AETERM Verbatim (i.e., investigator reported term) description of the adverse event

When documenting adverse events, use established medical terminology to record the known diagnosis or, if unavailable, the relevant sign or symptom If a diagnosis is later confirmed, update the AE form by replacing the initial entries with the accurate diagnosis as necessary.

Death should be viewed not as an isolated event, but rather as the consequence of an underlying condition Therefore, it is essential to document the condition that led to the death as the primary event.

Record only one diagnosis, sign or symptom (e.g., nausea and vomiting should not be recorded in the same entry, but as 2 separate entries)

In most cases, the verbatim term (i.e., investigator reported term) will be coded to a standard dictionary such as MedDRA, WHO ART, after the data has been collected on the CRF

4 Serious Event AESER Indicates whether or not the adverse event is determined to be “serious” according to the protocol

Assess if an adverse event should be classified as serious according to serious criteria

This field is related to ‘Serious Event type’ field, which may or may not be reported on the CRF

AESCAN AESCONG AESDISAB AESDTH AESHOSP AESLIFE AESOD AESMIE

Captures the criteria required by protocol for determining why an event is “Serious”

Indicate the category of the adverse event that classified the event as "serious" Select all that apply

This field can be used with ‘Serious Event’ field to classify which serious criteria were used to determine that the event was serious

Select all that apply implies that a field exists for each corresponding SDTM variables

"Serious Event Type" variable may be optionally on CRF or in external collection document (SAE Form) Capture of this data would be conditional on the occurrence of a serious event

**A sponsor can choose to database this with a single variable AESERTP or as

AESCAN Captures the criteria required by protocol for determining why an event is “Serious”

Was the event associated with cancer? Optional

AESCONG Captures the criteria required by protocol for determining why an event is “Serious”

Was the event associated with congenital anomaly?

5c Serious Event Type – disability/incapacity

AESDISAB Captures the criteria required by protocol for determining why an event is “Serious”

Did the event result in persistent or significant disability/incapacity?

AESDTH Captures the criteria required by protocol for determining why an event is “Serious”

Did the event result in death? Optional

AESHOSP Captures the criteria required by protocol for determining why an event is “Serious”

Did the event require or prolong hospitalization?

AESLIFE Captures the criteria required by protocol for determining why an event is “Serious”

Was the event life threatening? Optional

AESOD Captures the criteria required by protocol for determining why an event is “Serious”

Did the event occur with an overdose? Optional

AESMIE Captures the criteria required by protocol for determining why an event is “Serious”

Do additional categories of seriousness apply?

See above, the sponsor may choose to database as a single variable AESERTP or as separate variables

6 Start Date AESTDTC Date when the adverse event started Record the date that the AE began using the international date format For more detail see the Best Practice section

For the SDTM dataset, the SDTM

Variable AESTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into AESTDTC using the ISO 8601 format

(Note: If collected, will be derived into

Time when the adverse event started If appropriate, record the time (as complete as possible) that the AE began For more detail see the Best Practice section

Collecting the start time of an AE is justified only when it can be accurately established and there is a scientific rationale for requiring such detailed information.

Typically, it is not recommended that a start time be collected unless the subject is under the direct care of the site at the time the event started

Variable AESTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into AESTDTC using the ISO 8601 format

The AEENDTC, or End/Stop Date, indicates when the adverse event (AE) has resolved It is essential to record this date in the international date format For additional guidance, please refer to the Best Practice section.

If the AE is ongoing, leave the field blank

Variable AEENDTC is derived by concatenating CDASH End/Stop Date and Time (if time is collected) into AEENDTC using the ISO 8601 format

Indicates AE is ongoing when no End/Stop date is provided

If the adverse event has not stopped at the time of data collection, check the ongoing/ continuing box and leave the end/stop date blank

This field verifies that the adverse event (AE) was still ongoing during data collection At the conclusion of the study, each reported AE must have either an End/Stop Date or be marked as Ongoing/Continuing, but not both simultaneously.

This is not a direct mapping to AEENRF

The date of data collection in conjunction with end/stop date and the ongoing/continuing check box would determine how AEENRF will be populated

Time when the adverse event resolved If appropriate, record the time (as complete as possible) that the AE resolved For more detail see the Best Practice section

Collecting the end or stop time of an adverse event (AE) is only justified when it can be accurately established and when there is a scientific rationale for requiring this specific level of detail.

Typically, it is not recommended that a End/Stop time be collected unless the subject is under the direct care of the site at the time the event resolved

Variable AEENDTC is derived by concatenating CDASH End/Stop Date and Time (if time is collected) into AEENDTC using the ISO 8601 format

Description of the severity of the adverse event

The reporting physician or healthcare professional evaluates the severity of an adverse drug or biologic event based on established categories, using their medical judgment to compare it with similar events observed in clinical practice It is important to note that severity is distinct from seriousness.

Severity CTCAE Grade: The reporting physician/healthcare professional will assess the severity of the adverse event using the toxicity grades

Provide the appropriate controlled terminology for AE Severity

Either AESEV or AETOXGR must appear on the CRF Some studies may mandate the collection of both

Note: Completion of CTCAE grade is a mandatory field for cancer studies In all other types of studies this is an optional field

12 Relationship AEREL Indication of whether the investigational product had a causal effect on the adverse event, as reported by the clinician/investigator

Determine whether the adverse event is linked to the investigational product and cannot be reasonably attributed to other factors, such as the subject's clinical condition, concurrent therapies, or additional interventions, or if the cause remains unknown.

Provide the appropriate controlled terminology for indication of the relationship between the AE and the investigational product

13 Relationship Type AERELTP Captures a category for an investigational product to which an adverse event is related

Record the relationship category for adverse events to the investigational product One or more relationship type may be indicated

For example, the Adverse Event might be related to both study treatment

(investigational product) and study device

Provide the appropriate controlled terminology for AE Relationship Type

Relationship Type might be captured and the relationship (AEREL) derived One or more relationship type may be captured

14 Action Taken AEACN Action(s) taken with the investigational product in response to the adverse event

Record the action(s) taken with the investigational product resulting from the adverse event

Provide the appropriate controlled terminology for action taken with the investigational product in response to the

15 Other Action Taken AEACNOTH Describes Other Action(s) taken in response to the adverse event (Does not include investigational products)

Action Other: Record all other action(s) taken

Provide the appropriate instructions for capture of this field (Note: The CDISC controlled terminology team is reviewing controlled terminology for Other Action Taken.)

16 Outcome AEOUT Description of the subject’s status associated with an event

Record the appropriate outcome Provide the appropriate controlled terminology for Outcome

In the context of study discontinuations due to Adverse Events (AEs), different companies employ varying methods to record this information Some organizations document it on the Adverse Event Case Report Form (AE CRF), typically using a yes/no format, while others include it in the Study Summary or the Study Discontinuation page.

Comments – CO (Special Purpose)

Solicited comments refer to the entries made in designated free-text fields on Case Report Forms (CRFs), which are intentionally included to allow sites to elaborate on or clarify specific variables For instance, the Adverse Events CRF may feature a Comments field that facilitates the documentation of additional free-text information.

The CDASH Comments sub-team found that only one company still collects free text using a General Comments CRF, while the majority have either discontinued or are in the process of discontinuing this practice.

Unsolicited comments, often found in margins, are remarks entered outside of designated fields, including marginal CRF comments from site staff or notes from subjects in patient diaries While these comments aim to prevent queries, they frequently result in data being misclassified and create extra workload during the review process.

4.4.3 Considerations Regarding Usage of a General Comments CRF

Recent feedback indicates that only one company within the CDASH Comments sub-team continues to utilize a General Comments CRF for collecting free text, while the majority have either discontinued or are in the process of discontinuing this practice.

The Comments sub-team has concluded that there will be no required data elements for a separate Comments Case Report Form (CRF) and recommends against the establishment of a General Comments CRF This decision does not affect solicited free-text comment fields that may be included in other established domains.

Accurate entry of clinical data in designated fields is crucial to avoid the risk of undisclosed safety events For instance, if a comment states that a subject's visit was delayed due to the flu, it is essential to record "flu" in the Adverse Event Case Report Form (CRF) rather than merely noting it as a comment.

The Comments sub-team urges CRF development teams to enhance data collection methods instead of depending on a General Comments CRF In the absence of a system for recording general comments unrelated to specific data points, teams must create data collection tools that effectively capture all necessary data in designated fields The sub-team recommends that CRF developers identify additional information needed within a specific CRF By formulating specific questions through clearly defined variables, teams can ensure more meaningful analysis, rather than inconsistently gathering information in general comments fields.

General comments are challenging to analyze due to inconsistent phrasing and frequent spelling errors, limiting their value for statistical evaluation and making them unsuitable for tabulation Moreover, there is a risk that these comments may contain inappropriate or sensitive information, such as personal names or unblinding details.

Unsolicited comments, such as "subject visit was delayed due to his holidays," are not considered clinical data and should be discouraged due to their labor-intensive nature Investigative sites and monitors must be trained to input these comments in the appropriate fields rather than using marginal notes on the Case Report Form (CRF) This practice is essential to minimize time and cost associated with data entry, review, and action.

According to the ICH E3 guidelines, unsolicited comments are not required to be included in the datasets submitted to regulatory authorities The consensus among the Comments sub-team is that only data captured in the designated CRF fields should be regarded as clinical study data for regulatory submissions, while all other comments are classified as unsolicited.

Individual sponsor companies must determine their own path in handling the situation should unsolicited comments appear on CRFs.

Concomitant Medications – CM (Interventions)

Both General Medications and Medications of Interest should utilize the same fundamental data collection variables, with the understanding that specific fields may be added for each Medication of Interest In this context, General Medications are prioritized over Medications of Interest Additionally, the term "Prior" indicates medications that were initiated before the participant joined the study.

General medications refer to any drugs that individuals voluntarily mention when inquired about their medication use in a non-specific manner, without prompting for particular names of medications.

Medications of Interest refer to specific drugs or drug classes outlined in the study protocol, including those that are excluded, those that necessitate a washout period before dosing, and rescue medications.

Medications of Interest have been excluded from this document because the data collection for these drugs varies significantly from one protocol to another, often requiring a higher level of detail that can change based on the specific characteristics of each medication.

• Identification of unanticipated drug-drug interaction signals

• To assess the use of medications that may mask or enhance efficacy

• To provide details regarding the possible cause or course of adverse events

Sponsors are expected to incorporate additional data variables beyond those outlined in the CDASH draft document to fulfill specific protocol requirements, including therapeutic area data elements and other necessary data as dictated by business practices and operational procedures.

CMYN General prompt question to aid in monitoring and data cleaning

Indicate if the subject took any medications

If yes, include the appropriate details where indicated

The intent/purpose of collecting this field is to help with data cleaning and monitoring

Note: CMYN will not be included as part of the SDTM CM Domain for submission

The Medication Number, also known as CMSPID, is a sponsor-defined reference number that is optional It may be pre-printed on the Case Report Form (CRF) as a specific line identifier or defined within the sponsor's operational database.

(e.g., line number on an concomitant medication page)

For paper Prior & Concomitant Medication CRFs, it can be beneficial to use a sequence number in a data query to clearly communicate to the site the specific record in question

CMTRT Verbatim drug name that is either pre- printed or collected on a CRF

Provide the full trade or proprietary name of the drug; otherwise the generic name may be recorded

In most cases, the verbatim drug names will be coded to a standard dictionary such as WHO DRUG after the data has been collected on the CRF

To ensure accurate drug identification, it is recommended that sites provide the complete trade name or proprietary name rather than just the generic name The full trade name specifies the base generic and the corresponding salt for the drug, which is essential for precise coding and assists in the selection of the Anatomical Therapeutic Chemical (ATC) classification.

For example the medication Tylenol with codeine #1 has a different ATC code from Tylenol with codeine #3

4 Active Ingredient CMINGRD Medication Ingredients Record all active ingredient(s) for the reported name of drug medication or therapy taken

This may be collected in addition to the reported name of Drug Medication or Therapy

Collecting this provides more detailed information when coding to a medication dictionary like WHO Drug Enhanced format C which now codes to the ingredient level for many trade named medication

For example, the medication Dolmen, depending on the country where it is manufactured, the active ingredients may be different

Spain: Acetylsalicylic Acid, Ascorbic acid, codeine phosphate

Italy and Czech Republic: contains Tenoxicam

Estonia and Latvia: contains Dexketoprofen trometamol

5 Indication CMINDC The reason for administration of a concomitant (non-study) medication

This is not the pharmacological/ therapeutic classification of an agent

(e.g., antibiotic, analgesic, etc.), but the reason for its administration to the subject

Record the reason the medication was taken

If taken to treat a condition, and a diagnosis was made, the diagnosis is what should be reported (the symptoms may be inferred or they may be recorded separately)

If taken to treat a condition, and no diagnosis was made, record the symptoms

If taken as prophylaxis, we recommend reporting as “Prophylaxis for…”

This additional information is collected on the CRF when the sponsor would want to capture the reason(s) why a subject took a medication

This information can then be used as deemed appropriate for coding, analysis

In the classification of medications, it is essential to reconcile the medications taken by a subject with their medical history and any adverse events (AEs) or serious adverse events (SAEs) This process is a critical component of data cleanup and monitoring, ensuring accurate and comprehensive documentation for effective patient care.

6 AE Number AESPID Identifier for the adverse event that is the indication for this medication

Establishing a connection between an adverse event and the medication taken can be challenging, as there are alternative methods to gather this type of information.

Using this variable to track a sequence number linked to an AE can lead to excessive data cleaning efforts, especially if the AE number is reassigned or deleted following a query response or correction from the clinical site.

Note: AESPID will not be included in the SDTM CM domain in submissions

In clinical trials, the total daily dose (CMDOSTOT) refers to the overall amount of a medication taken each day While individual doses are typically recorded in early-phase trials, such as Phase I, later-phase trials, including Phase IV and post-marketing studies, often focus solely on the total daily dose collected.

For general medication, it is advisable not to use "Total Daily Dose" except in later phase trials Instead, this value can be accurately calculated from other parameters, including Dosage Units, Dosage Amount, and Dosage Interval, to minimize confusion and simplify calculations for clinical sites.

8 Dose Form CMDOSFRM Name of the pharmaceutical dosage form (e.g., tablets, capsules, syrup) of delivery for the drug

None We recognize that some drugs have multiple forms and this field may be needed to code the drug to an ATC level

However, in general, this level of detail should not be necessary except for medications of interest

If a medication requiring a specific formulation for coding is recorded but the formulation is not included in the Case Report Form (CRF), the site may be asked to incorporate the formulation into the drug name for clarity.

Where possible it is recommended that Sponsor provide the appropriate controlled terminology for dose form

CMDOSFRQ How often the medication was taken

(e.g., BID, every other week, PRN)

None When collected, the recommendation is to collect dosing information in separate fields for specific and consistent data collection

See below for the rest of the dosing information components (Dose per administration, and dose unit.)

The dose of medication taken per administration

None Where this level of dosing information is required by a sponsor, this field may be included

Defining this data collection field as a dose text field allows for flexibility in capturing text entry (e.g., range of dosing 200-400)

CMDSTXT does not directly correspond to the SDTM variable CMDOSTXT The information gathered in this dose text-format field must be appropriately separated or mapped to either SDTM CMDOSE for numeric values or CMDOSTXT for textual data.

11 Dose Unit CMDOSU Within structured dosage information, the unit associated with the dose (e.g.,

"mg" in "2mg three times per day)

CMDOSRGM Within structured dosage information, the number of units for the interval (e.g., in oncology where drug is given 1 week on, and 3 weeks off)

CMROUTE Identifies the route of administration of the drug

Provide the route of administration for the drug

Collecting detailed information on a medication's route of administration in the Case Report Form (CRF) is crucial for sponsors, especially when a medication has multiple routes This data aids in accurate coding, allowing companies to select the correct preferred name and Anatomical Therapeutic Chemical (ATC) code for the medication.

CMSTDTC Date when the medication was first taken

(If collecting the date) Record the date the medication was first taken using the international date format For more detail see the Best Practice section

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 started during the study are expected to have a complete date

For Prior medications that are protocol defined as excluded medications, these medications need to be recorded as stopped prior study start (study start is a sponsor defined reference period.)

The preferred method is to collect a Start Date Partial dates (i.e., YY) for medications started prior to the study are acceptable

Variable CMSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into CMSTDTC using the ISO 8601 format

CMSTRF Relative time frame that the medication was first taken with respect to the sponsor-defined reference period

(If collecting the relative time frame)

Indicate if this medication was started before the study or during the study

If instead of Start Date, information such as BEFORE or DURING is collected, this information is derived in the CMSTRF variable

Time the medication was started If appropriate, record the time (as complete as possible) that the medication was started

For more detail see the Best Practice section

Collecting the time a medication was started is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail

Typically, it is not recommended that a start time be collected unless the subject is under the direct care of the site at the time a medication is taken

Variable CMSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into CMSTDTC using the ISO 8601 format

17 End/Stop Date CMENDTC Date that the subject stopped taking the medication

Record the date the subject stopped taking the medication using the international date format For more detail see the Best Practice section

If the subject has not stopped taking the medication leave this field blank

If the Ongoing/Continuing box is also collected, check the Ongoing/Continuing box and leave the End/Stop Date blank

The assumption is that sponsors should either have a complete stop date or will indicate that the medication was ongoing at the end of the study

Variable CMENDTC is derived by concatenating CDASH End/Stop Date and Time (if time is collected) into CMENDTC using the ISO 8601 format

Indicates medication is ongoing when no End/Stop Date is provided

If subject has not stopped taking the medication at the time of data collection, check the Ongoing/Continuing box and leave the End/Stop Date blank

This box should be checked to indicate that the medication has not stopped at the time of data collection

At study completion, it is expected that every reported medication should have either End/Stop Date or be checked as Ongoing/continuing, but not both

This is not a direct mapping to CMENRF

The date of data collection in conjunction with stop date and the ongoing/continuing check box would determine how CMENRF will be populated

Time when the subject stopped taking the medication

If appropriate, record the time (as complete as possible) that the medication was stopped For more detail see the Best Practice section

Demography – DM (Special Purpose)

The team observed that numerous collected variables correspond directly to SDTM variables for delivery, while also highlighting privacy concerns related to DM and SC data Additionally, some variables may have a many-to-one mapping, allowing for greater flexibility in categorizing data and addressing complex regulatory privacy issues.

4.6.1 Collection of Age vs Birth Date

The CDASH DM/SC team acknowledges that sponsors may collect either the age or birth date of subjects, with the understanding that knowing age on a specific date introduces a maximum uncertainty of 366 days if recalculated for a different date In contrast, a precise birth date allows for accurate age calculation on any date However, some privacy oversight boards and regulators may view a complete birth date as overly identifying To address this, we propose leveraging SDTM's capability to report dates with varying precision, allowing for separate collection of birth date components By collecting the year and month of birth while making the day conditional and the time optional, we can minimize uncertainty to a maximum of 31 days for age calculations, thus balancing data accuracy with privacy concerns.

The DM team determined that by breaking down the elements of the SDTM variable BRTHDTC (which includes year, month, day, and time of birth), we can create a solution that effectively balances the need for meaningful analytical source data with the necessity of adhering to privacy regulations.

The CDASH DM/SC team prefers to gather the date of birth, specifically the birth year and month, to calculate age instead of directly collecting age This method addresses privacy concerns associated with full birth date collection while allowing age to be an optional variable.

The DM team advises that a complete birth date should include the Year, Month, Day, and Time of birth When designing the Case Report Form (CRF), it's important to group these variables together, although they can be stored either together or separately for optimal management If the birth date components are stored separately, they can be combined into a reportable date, which may lack some precision but still provides valuable data for analysis This approach not only safeguards the privacy of trial participants by obscuring personal information but also complies with regulatory and privacy board requirements regarding data collection.

When the mandatory “birth year” and “birth month” components are collected but the conditional “birth day” is not collected the sponsor may report the date in ISO

8601 structure (compliant with SDTM) and the BRTHDTC variable would be created by populating the year and month components of ISO 8601, but omitting the day

When documenting an individual's birth year, ensure to accurately record it in a four-digit format (YYYY) or, if preferred, simply note the last two digits This information is essential for completing the required form correctly.

A collected variable used for recording the year component of the “Date of Birth”

(See Section 4.6.1 Collection of Age vs

2 Month of Birth BRTHMO Month of subject’s birth Record the subject’s month MMM (JAN-

A collected variable used for recording the month component of the “Date of Birth”

3 Day of Birth BRTHDY Day of subject’s birth Record the subject’s day of birth

A collected variable used for recording the day component of the “Date of Birth”

The collection of an individual's complete date of birth is essential, unless an Ethics Committee or local Data Protection Authorities (DPA) raise privacy concerns, in which case it may be advisable to exclude this information.

“Date of Birth” to assuage those concerns

4 Time of Birth BRTHTM Time of subject’s birth, Optionally, if appropriate, record the time of birth (as complete as possible)

This level of detail may be necessary for analysis for some pediatric, natal or neonatal studies

Sex refers to the collection of physical characteristics that differentiate males from females, highlighting the distinct biological traits that define each gender This distinction encompasses the various physical properties and qualities that are unique to male and female individuals.

Record the appropriate sex (e.g., female, male) as required on this form

As reported by subject or caretaker Highly

The numeric age of a subject must be recorded as a number and linked to a variable indicating the age unit for accurate interpretation Additionally, it is important to note when the age was collected, as it may need to be recalculated for analysis, such as determining the age at a reference start time (RFSTDTC for SDTM).

7 Age Units AGEU Age units Record the appropriate age unit (e.g., years, months, etc.) as required on the form

If Age is captured on the CRF, the site must also record age unit(s) to make the “Age” value meaningful

8 Date of Collection DMDTC Date of collection Record the date the demographics data was collection in the international date format

The date of collection may be derived from the date of visit and if so, a separate date field is not required

For the SDTM data set, the SDTM variable DMDTC is derived by concatenating CDASH Date and Time of collection (if time is collected) into DMDTC using the ISO 8601 format

Time of collection Record the time of collection (as complete as possible) For more detail see the Best Practice section

For the SDTM data set, the SDTM variable DMDTC is derived by concatenating CDASH Date and Time of collection (if time is collected) into DMDTC using the ISO 8601 format

Record detailed information only when essential for analysis The collection time can be inferred from the visit time, eliminating the need for a separate field for collection time.

Ethnicity refers to a social group that is defined by unique cultural traditions, shared history, and a collective identity passed down through generations Members of an ethnic group often exhibit distinctive lifestyles, common experiences, and may share genetic traits, all of which can influence their health and susceptibility to diseases.

Study participants should self-report race and ethnicity whenever feasible, with ethnicity being asked about before race

To improve data quality and consistency in race and ethnicity reporting, it is advisable to implement collapsible categories that align with the minimum five race designations and two ethnicity categories required by the FDA For more detailed classifications, utilizing the race and vocabulary tables from Health Level Seven’s Reference Information Model Structural Vocabulary Tables is recommended, as they are specifically designed for this collapsible format.

Other regulatory bodies may expect the reporting of ethnicity values (different than the US FDA) which more appropriately reflect the population of their areas (e.g., Japanese ancestry for

MHLA reporting to Japan) These may be collected as an extension to the suggested NCI-CDISC code list

11 Race of Subject RACE An arbitrary classification based on physical characteristics; a group of persons related by common descent or heredity

Study participants are encouraged to self-report their race and ethnicity whenever possible According to FDA guidance, if both race and ethnicity are collected, it is advisable to inquire about ethnicity prior to asking about race.

(The FDA guidance suggests “that individuals be permitted to designate a multiracial identity/” “Check all that apply” at the time of collection.)

The categories listed in the FDA Guidance are as follows:

-American Indian or Alaska Native -Asian

-Native Hawaiian or Other Pacific Islander -White

*For studies where data are collected outside the US, the recommended categories are the same except for Black instead of Black or African American

To improve data quality and consistency in race and ethnicity reporting, it is advisable to use collapsible characterizations that align with the five minimum race designations and two reportable ethnicity categories required by the FDA For more detailed classifications, utilizing the race and vocabulary tables from Health Level Seven’s Reference Information Model Structural Vocabulary Tables is recommended, as these tables are specifically designed for this collapsible format.

Disposition – DS (Events)

The team focused primarily on disposition events while also addressing protocol milestones, acknowledging that the DS domain facilitates the documentation and submission of completed protocol milestones, such as obtaining informed consent and randomization Although the team did not evaluate the specification of CRF questions or "mini CRF modules" for capturing this information, they recognize that incorporating such questions in relevant sections is feasible.

CRF, or Case Report Form, is essential for sponsors aiming to formally document the completion of protocol milestones, with the informed consent date typically recorded alongside demographic data on the same CRF page, and subsequently mapped for submission to the DS domain.

The team engaged in thorough discussions regarding the vocabulary for a controlled terminology list concerning 'Reason for Discontinuation,' utilizing the existing list published by the CDISC Terminology group as a foundation They will continue to refine their recommendations for future discussions.

Definition Instruction to Clinical Site Implementation/

1 Trial Epoch EPOCH Trial epoch (e.g., trial cycle, phase, end of study, etc.) for which subject disposition is being collected

In most cases, the trial epoch is pre-printed on the Case Report Form (CRF) as the page title However, for companies that use a standard CRF module featuring a "pick-list" of epochs, specific instructions are provided.

Check the for which disposition is being recorded

The trial epoch is usually indicated as the title on the Case Report Form (CRF) page, but some organizations utilize a standard CRF module that features a "pick-list" for selecting epochs.

Reported term for the Disposition Event of the subject at a selected trial epoch

Document the subject’s status at If the subject discontinued prematurely, record the primary reason for discontinuation

DSSTDTC The date that the subject completed the selected trial epoch, or the date that the subject discontinued from the selected trial epoch, using the international date format

Record the date that the subject completed the as defined in the protocol and/or

When completing the CRF, use the international date format If the subject did not complete the epoch or relevant phase, document the date they discontinued based on your best knowledge.

Define in the protocol and/or CRF Completion Instructions the criteria for completion of each trial epoch for which a disposition CRF will be provided

Only collect the date of completion or discontinuation on the disposition CRF module if the same information is not being collected on another CRF module

The date of the last dose, which signifies the conclusion of the Treatment Phase epoch and is recorded on the Drug Exposure form, should not be duplicated in the Disposition CRF module.

Variable DSSTDTC is derived by concatenating CDASH Date and Time of Completion or Discontinuation (if time is collected) into DSSTDTC using the ISO

The time that the subject completed the selected trial epoch, or the time that the subject discontinued from the selected trial epoch

Document the exact time the subject finished the designated trial epoch as outlined in the protocol and/or Case Report Form (CRF) Completion Instructions If the subject did not complete the trial epoch, note the time they discontinued, providing as accurate information as possible.

Define in the protocol and/or CRF Completion Instructions the criteria for completion of each trial epoch for which a disposition CRF will be provided

Collecting data on the time of completion or discontinuation is only advisable when it can be accurately determined and there is a scientific justification for this level of detail Generally, it is not recommended to gather such timing information unless the subject is under the direct care of the site during the event.

Only collect the time of completion or discontinuation on the disposition CRF module if the same information is not being collected on another CRF module

If the timing of the last dose is established to signify the conclusion of the Treatment Phase epoch and is recorded on the Drug Exposure form, it should not be included in the Disposition CRF module.

Variable DSSTDTC is derived by concatenating CDASH Date and Time of Completion or Discontinuation (if time is collected) into DSSTDTC using the ISO

5 Was treatment unblinded by the site?

DSUNBLND Identifies in a blinded trial whether or not the subject’s blind was broken by the site

Was the subject’s treatment assignment unblinded by the site?

DSCONT Plan for subject continuation to the next phase of the trial or another related trial at the time of completion of the CRF

To the best of your knowledge, record if the subject will be continuing to the next phase of this trial or another related trial?

Sponsor should specify what the next phase of the trial or the related trial is

7 Next trial epoch or new trial subject will be entering

DSNEXT Identifies the trial epoch or new trial in which the subject will participate

Record the trial epoch or trial identifier if the subject is continuing

Drug Accountability – DA (Findings)

The CDASH Drug Accountability proposal aims to establish the necessary variables for evaluating drug accountability in clinical trial participants These variables are essential for calculating the compliance of subjects with the investigational product.

This proposal outlines the Study Data Tabulation Model (SDTM) variables as detailed in the SDTM Implementation Guide 3.1.1 DATEST values may be pre-specified on the Case Report Form (CRF) when data is collected in a horizontal format According to SDTM guidelines, there should be one record per drug accountability finding for each subject The integration of SDTM variables enables the unique identification of findings.

The use of a Drug Accountability CRF/eCRF is optional, and it is advised against for single dose studies After discussing various drug accountability scenarios, the team determined that implementing this standard would provide limited value in the context of single dose research.

The proposal for Drug Accountability does not include recommendations for devices However, it is our understanding that the following information is typically collected:

• Serial, Lot or Batch Number

• Name of person receiving shipment

• Reason for return to sponsor

• Date of disposal (if permitted)

• If disposed, method of disposal

• Person returning or disposing of method

DADTC Date the Investigational Product was dispensed

Record the exact date the investigational product was dispensed, using the international date format For more detail see the Best Practice section

The date investigational product dispensed should be recorded for each dispensation for a study with multiple periods or multiple products dispensed

Variable DADTC is derived by putting the CDASH Date Investigational Product Dispensed into DADTC using the ISO

DAORRES Result of the Drug Accountability assessment as originally received or collected (e.g., actual amount)

DATEST Verbatim name, corresponding to the topic variable, of the test or examination used to obtain the drug accountability assessment (e.g., dispensed)

Record the actual amount of investigational product dispensed

In studies involving multiple periods or various dispensed products, it is crucial to evaluate drug accountability for each dispensation Utilizing a sequence number or group ID effectively connects related records, ensuring a clear link between dispensed products and those returned.

Note: DATEST must be used in concert with DAORRES and DAORRESU to describe these distinct pieces of data

DAORRESU Unit for DAORRES (e.g., tablets)

DATEST Verbatim name, corresponding to the topic variable, of the test or examination used to obtain the drug accountability assessment (e.g., dispensed)

Record the units in which the investigational product was dispensed

Unit of Product dispensed (e.g., tablets)

The unit will need to be pre-printed on the CRF or a field provided on the CRF to capture it

DADTC Date that the Investigational Product was dispensed

Record the exact date the investigational product was returned, using the international date format For more detail see the Best Practice section

For studies involving multiple periods or various dispensed products, it is essential to record the return date of the investigational product for each dispensation However, if only one drug is dispensed on a single occasion, collecting this data is not necessary.

Variable DADTC is derived by putting the CDASH Date Investigational Product Returned into DADTC using the ISO 8601 format

DAORRES Result of the Drug Accountability assessment as originally dispensed

Record the actual amount of investigational product returned

DATEST Verbatim name, corresponding to the topic variable, of the test or examination used to obtain the drug accountability assessment (e.g., returned.)

Drug accountability must be evaluated for each dispensation in studies involving multiple periods or various products Utilizing a sequence number or group ID is essential to connect related records and associate returned products with those dispensed.

DAORRESU Unit for DAORRES (e.g., tablets)

DATEST Verbatim name, corresponding to the topic variable, of the test or examination used to obtain the drug accountability assessment (e.g., returned)

Record the unit of investigational product returned

Unit of Investigational Product returned

DACAT Used to define a categorization level for a group of related records

Record the type of investigational product dispensed/returned (e.g., Study Medication,

DASCAT Used to define a further categorization level for a group of related records

Record the name of the investigational product dispensed/returned (e.g., Drug A,

ECG Test Results – EG (Findings)

The ECG Team decided against specifying particular ECG measurements, as such decisions should be guided by medical and scientific considerations tailored to the requirements of the protocols.

The tables below are provided for three different scenarios

Scenario 1: Central reading: In this scenario, results are captured directly by an electronic device and transmitted separately, or read by a central vendor – not recorded on the CRF

Scenario 2: Local reading: In this scenario, patient ECGs are performed and analyzed, and then the results are reported directly on the CRF

Scenario 3: Central reading (as in Scenario 1): But in addition, the CRF includes a site assessment of clinical significance

4.9.1 Scenario 1: Central reading: ECG results are captured directly by an electronic device and transmitted separately or read centrally – not recorded on the CRF

The ECG Status, or EGSTAT, indicates whether an electrocardiogram was performed This tool is designed for data management purposes, allowing verification of any missing results from electronic transfers to ensure that such omissions were intentional.

2 Reason Not Done EGREASND Describes why the ECG was not done

Record the reason that the ECG was not done

May be included if required by the protocol Examples of when this may be necessary are cardiac studies or thorough

3 Date of ECG EGDTC Date of ECG Record the date ECG occurred using the international date format For more detail see the Best Practice section

A complete date is expected for ECGs that occur during the study May be collected elsewhere, such as a study visit date

Key data collected Especially important when multiple assessments are collected on more than one day

Variable EGDTC is derived by concatenating CDASH Date and Time of ECG (if time is collected) into EGDTC

Time of ECG Record the time the ECG was done (as complete as possible) For more detail see the Best Practice section

Especially important when multiple assessments are done on one day

Variable EGDTC is derived by concatenating CDASH Date and Time of ECG (if time is collected) into EGDTC using the ISO 8601 format

5 Planned Time Point EGTPT Text description of planned time point when measurements should be taken for use when multiple sequential assessments are done

Record the time point labels for when the ECG test should be taken, if not pre-printed on the CRF

Planned Time point would be needed to differentiate for multiple sequential assessments

The ECG Reference ID (EGREFID) serves as an internal or external identifier, crucial for tracking the assigned identifier number This identifier can be utilized to verify the presence of the correct data record during electronic transfers, such as the UUID for external waveform files.

7 Protocol-defined testing conditions met

Condition for testing defined in the protocol

Record whether protocol defined conditions were met

Results may be affected by whether conditions for ECG were properly met

-Subject position during ECG (e.g., supine, standing, sitting)

-ECG Method (e.g., 12-Lead or 1-Lead)

If the protocol requires this type of information, then these questions may be included to confirm that the condition for testing as defined by the protocol were met

4.9.2 Scenario 2: Local reading: ECGs are performed and analyzed and results are reported directly on the CRF

1 ECG Status EGSTAT Status of whether or not ECG was done Indicate whether or not ECG was done This may be implemented for an entire

ECG, or on a test-by-test basis This is intended to be used as a data management tool to verify that missing results are intentionally missing

Variable EGDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into EGDTC using the ISO 8601 format

Variable EGDTC is derived by concatenating CDASH Date and Time of ECG (if time is collected) into EGDTC using the ISO 8601 format

Verbatim name of the test or examination used to obtain the measurement or finding

Record the wording of the ECG test, if not pre-printed on the CRF

Required to identify the result May be preprinted

7 Test Result EGORRES Result of the measurement or finding as originally received or collected

Record test results Key data collected Highly

8 Units EGORRESU Original units in which the data were collected

(If units are not pre-printed on the CRFs)

Record the original units in which this data were collected

Quantitative ECG results should be recorded in seconds or milliseconds, and it is advisable to pre-print these units on the Case Report Form (CRF) to ensure consistency, rather than relying on sites to input the units themselves.

(Note: If collected will be mapped to

Whether ECG results were clinically significant

Record whether ECG results were clinically significant

May be included if required by the protocol

Condition for testing defined in the protocol

Record whether protocol defined conditions were met

The role of the evaluator in EGEVAL is crucial, as it pertains specifically to subjective assessments provided by individuals or groups This evaluation process is not applicable to quantitative results, ensuring a clear distinction between subjective and objective measurements.

Record the role of the person evaluating the results

The ECG Reference ID (EGREFID) serves as an internal or external identifier, allowing for the recording of a specific identifier number This identifier is crucial for verifying the presence of the correct data record during electronic transfers, such as a UUID for an external waveform file.

4.9.3 Scenario 3: Central Reading (as in Scenario 1) But in addition, the CRF includes site assessment of clinical significance

1 ECG Status EGSTAT Status of whether or not ECG was done Indicate whether or not ECG was done This may be implemented for an entire

ECG, or on a test-by-test basis This is intended to be used as a data management tool to verify results provided

6 Test Name EGTEST Verbatim name of the test or examination used to obtain the measurement or finding

Record the description of the ECG result, if not pre-printed on the CRF

Required to identify the test May be preprinted

Quantitative ECG results should be recorded in seconds or milliseconds, and to ensure consistency, the units must be pre-printed on the Case Report Form (CRF) instead of relying on sites to input them manually.

(Note: If collected, will be mapped to

Whether ECG results were clinically significant

Record whether ECG results were clinically significant

Key data collected in this scenario Highly

9 Test Result EGORRES Result of the measurement or finding as originally received or collected

Record test results Optional if already provided from central

Quantitative ECG results must be recorded in specified units of seconds or milliseconds To ensure consistency and accuracy, these units should be pre-printed on the Case Report Form (CRF) instead of relying on sites to input them manually.

11 Vendor Name EGNAM Name of vendor providing ECG data Record the vendor name May be included on CRF if not standardized by clinical trial site

This information may be used for reconciliation purposes

Conditions for testing defined in the protocol

Record whether protocol defined testing conditions were met

13 ECG Reference ID EGREFID Internal or external ECG identifier Record the ECG Reference ID assigned May be included for linking back to external data file

Exposure – EX (Interventions)

This proposal includes the Study Data Tabulation Model variables that appear in the SDTM Implementation Guide 3.1.1 The SDTM implementation Guide defines the Exposure domain model as follows

The Exposure domain model captures the specifics of a subject's exposure to the study treatment as defined by the protocol This treatment can encompass various interventions, such as placebo, active comparators, or investigational products, which may or may not be provided to the subject Any treatments that fall outside the protocol specifications should be documented in the Concomitant Medications (CM) domain.

The dose variables in this proposal refer to the collection of the ‘actual dose’ rather than the ‘planned dose’

1 Start Date EXSTDTC Start date of treatment Record the exact date of the investigational product administration using the international date format For more detail see the Best Practice section

Variable EXSTDTC is derived by concatenating CDASH Start Date and Time of treatment (if time is collected) into EXSTDTC using the ISO 8601 format

Start time of treatment Record the time (as complete as possible) when administration of investigational product started For more detail see the Best Practice section

Time when investigational product period started

Variable EXSTDTC is derived by concatenating CDASH Start Date and Time of treatment (if time is collected) into EXSTDTC using the ISO 8601 format

The EXENDTC field indicates the end date of treatment, which should be recorded as the last date of administration of the investigational product in the international date format For additional guidance, refer to the Best Practice section.

Date when investigational product period stopped

When the start date and stop date of a trial are not anticipated to coincide, providing a stop date is essential Conversely, if the trial design specifies that both dates fall on the same day, the stop date is unnecessary, as it can simply be set to match the start date.

Variable EXENDTC is derived by concatenating CDASH Stop Date and Time of treatment (if time is collected) into EXENDTC using the ISO 8601 format

End time of treatment Record the time, (as complete as possible) when investigational product administration stopped (e.g., for infusions this is the time when the infusion ended)

‘constant dosing interval’ ended/stopped

Variable EXENDTC is derived by concatenating CDASH Stop Date and Time of treatment (if time is collected) into EXENDTC using the ISO 8601 format

5 Dose Amount EXDOSE Dose per Administration Record the dose or amount of investigational product that was administered to/taken by the subject in the period recorded

Dose or amount taken per ‘constant dosing interval’ recorded

Capture of dose is conditional because it may be possible to obtain dose by other methods (e.g., derived from randomization data)

6 Dose Unit EXDOSU Units for EXDOSE Record the unit of dose or amount taken per period recorded (e.g., ng, mg, or mg/kg)

Unit of dose or amount taken per

Capture of dose unit is conditional because it may be possible to obtain dose by other methods (e.g., derived from randomization data)

(Note: Either can store investigational product identification number)

EXLOT = Lot Number of the EXTRT product

EXSPID = Sponsor defined reference number Perhaps pre-printed on the CRF as an explicit line identifier or defined in the sponsor’s operational database

Record the reference number that appears on the container holding the investigational product (e.g., Lot Number)

Reference number that appears on the container holding the investigational product

Investigational Product Identification Number is a unique number, which provides mapping to Lot Number and possibly the randomization schema

EXTRT Name of the intervention treatment — usually the verbatim name of the investigational treatment given during the ‘constant dosing interval’ for the observation

Record the name of investigational product Name of investigational product that was administered to the subject

This must be collected if it cannot be derived

Variable must always be present in the underlying database

Confirmation of dose adjustment Select either “Yes” or “No” to indicate whether there was a change in dosing

Will provide a definitive response regarding dose changes

EXADJ Describes reason or explanation of why a dose is adjusted – used only when an adjustment is represented in

EXPOSURE May be used for variations from protocol-specified doses, or changes from expected doses

If there was a change in dosing, record the reason for change

Captures reason dose was changed / modified The reason may be chosen from a select list or entered as free text

11 Frequency EXDOSFRQ Usually expressed as the number of dosings given per a specific interval

Record the frequency the investigational product was administered for a defined period of time (e.g., BID, QID, TID)

Number of doses given per a specific interval

12 Route EXROUTE Route of administration for EXTRT Record the route of administration (e.g., IV, oral or transdermal) or enter the appropriate code from the code list

Route of investigational product administration

This will often be pre-printed on the CRF

If it is not pre-printed, a field will need to be provided on the CRF

13 Formulation EXDOSFRM Dose form for EXTRT Record the formulation (e.g., infusion, solution, tablet, lotion) or enter the appropriate code from the code list

This must be collected if it can not be derived

Variable must always be present in the underlying database

Duration of the treatment interruption Record the duration of treatment interruption Duration of treatment interruption

In some situations, the duration of the interruption may be calculated from the administration start and stop times recorded elsewhere in the CRF

DURINTPU Unit for the duration of treatment interruption

Record the unit (e.g., minutes, hours, days) for the duration of treatment interruption

The unit (e.g., minutes, hours, days) needs to be collected as a qualifier to the number for duration

15 Body Location EXLOC Specifies anatomical location of administration

Record the body location where the investigational product was administered

Location where the investigational product was administered

This may be pre-printed or collected

Exposure volume amount Record the total volume that was administered/given to the subject

Infusion volume that was given to the subject

The unit of measure for the exposure volume amount

Record the unit of total volume administered/ given to the subject (e.g., mL)

Unit of the infusion volume (e.g., mL) Optional

Rate of infusion Record the Rate of Infusion (e.g., 10 mL/min

Record “10”as the infusion rate)

Infusion rate can be used to derive dose Optional

The unit of measure for the flow rate Record the unit for the infusion rate (e.g., mL/min)

Unit of the infusion rate (e.g., mL/min) Optional

19 Planned Time Point EXTPT Planned time point name Record the planned time point of investigational product administration (e.g., mornings, evening)

Indicates the planned time point of investigational product administration

20 Did subject complete full course of study med?

Confirmation point for exposure Select either “Yes” or “No” to indicate whether subject has completed the full course of treatment

Depending on how the investigational product details are collected via the CRF/ eCRF, it may be possible to derive this data

Inclusion / Exclusion – IE (Findings)

The IE Team acknowledges that entry criteria may evolve throughout the duration of a study, particularly when employing adaptive trial design To efficiently manage these changes, it is recommended to implement a flexible approach that accommodates shifting criteria as the study advances CDASH suggests utilizing uniquely numbered entry criteria in submissions to streamline the management of protocol modifications and enhance the collection and submission of IE data.

4.11.2 Collecting IE Data and Mapping to the SDTM

The IE Team observed that certain CRF variables can correspond to SDTM variables in either a one-to-one or many-to-one manner, depending on the data collection methods used by different Sponsor companies The recommended IE CRF standard outlined in this document is designed to be adaptable, accommodating various data collection approaches while ensuring compatibility with a unified SDTM standard.

The IE Team utilized the latest CDISC SDTM Implementation Guide to establish data collection standards, ensuring that the assumptions related to the IE Domain were effectively integrated into the process.

The primary assumption of the SDTM IG regarding the IE domain model is that it is designed solely to submit criteria that indicate a subject's violation of eligibility.

The IE Team advises the use of an entry criteria worksheet for each subject during screening, which should serve as a source document for monitoring activities and be kept with the subject’s site files This worksheet must clearly identify each entry criterion with a unique identifier, allowing for easy documentation on the CRF when a subject does not meet a specific criterion.

The IE domain is designed solely to gather eligibility information for study inclusion and exclusion criteria, rather than addressing protocol deviations or violations that may occur during the study Any case report form (CRF) fields identified by the IE Team as relevant to protocol deviations or violations are referred to the Protocol Deviation (DV) Team for further evaluation.

The final assumption in developing this standard emphasizes the necessity of collecting sufficient data to address safety concerns and meet regulatory requirements, ensuring the accurate population or derivation of required SDTM submission variables All SDTM variables mandated for submission are either directly gathered through the Case Report Form (CRF) or can be derived from collected data, such as IEORRES and IESTRESC, utilizing the Required and Expected CDASH variables outlined in the accompanying table Detailed recommendations for data collection and derivation are provided in the Implementation/Rationale to Sponsors column of the table.

1 Met Eligibility IEYN Response for whether the subject met all the eligibility requirements for this study

Record "yes" if all eligibility criteria for the study are met; otherwise, record "no." If "no" is selected, please provide the identifying code for each unmet criterion.

Checkbox: Check here if the subject met all eligibility requirements for the study

This is intended to be used primarily as a monitoring and/or data management tool to verify that the investigator/site reported any entry criteria that were not met

May be a “yes/no” question, or may be a checkbox

May be used to derive data into IEORRES

Must be recorded on the CRF

2 Criterion Identifier 5 IETESTCD The identifier associated with the criterion that the subject did not meet

This must be a unique identifier that corresponds to a specific entry criterion 6

Record this only for the criterion / criteria that this subject did not meet 7

Paper: Record the criterion identifier from the list of inclusion/ exclusion criteria provided by the Sponsor

EDC: Select the criterion from the pick-list

This field is required to appear on the CRF, but may be null if all criteria are met

Multiple responses should be allowed on CRF

CDASH advises Sponsors to assess the appropriate number of lines required on the Case Report Form (CRF) based on their experience and the maximum allowable limits, typically suggesting that most studies will need only 2 or 3 lines.

Note: Consider modifying the criteria rather than allowing subjects in who do not meet the criteria

In SDTM, this variable is recorded only for unmet criteria and will appear on the CRF solely for those criteria The IE Team evaluated the use of criteria lists without unique identifiers, such as bulleted lists Following a review by the Collaborative Group and recommendations from FDA reviewers, the Team opted to eliminate the alternative approach from the Harmonized Version of this document, establishing a single standard for IE data collection The FDA reviewers advised organizations utilizing bulleted lists to transition to unique identifiers for entry criteria.

6 If inclusion and exclusion criteria lists are independently numbered (e.g., inclusion 001-100, exclusion 001-100), then this identifier must include a means of identifying the TYPE of

3 Criterion IETEST The wording of an inclusion or exclusion criterion

The EDC criterion requires verification of its wording, primarily for use in EDC applications This field will be filled in once the Criterion Identifier is populated, and it can be validated by the Principal Investigator (PI).

Paper: The monitoring process should include a cross-verification of entry criteria against the medical records for each subject

IECAT Specifies whether the criterion is inclusion or exclusion

Record whether the criterion that this subject did not meet was “Inclusion” or “Exclusion”.

IECAT must be populated in SDTM (only) for those criteria that are not met, but does not necessarily have to be collected on the CRF

This category can be gathered from the CRF, incorporated into the Criterion Identifier (such as I01, E01), or extracted from the Trial Inclusion (TI) criteria dataset Additionally, it may derive from other protocol definitions outside the clinical database when a specific criterion identifier is noted in the IETESTCD variable.

Laboratory Test Results – LB (Findings)

The tables below are provided for three different scenarios

Scenario 1: Central processing: In this scenario, patient samples are taken at site, sent out for processing and results are provided directly to the sponsor This scenario also applies when results are captured directly via an electronic device – not recorded on the CRF

Scenario 2: Local processing: In this scenario, patient samples are taken and analyzed, and then the results are reported directly on the CRF

Scenario 3: Central processing with Clinical Significance Assessment for abnormal values: In this scenario, patient samples are taken at site, sent out for processing and results are provided directly to the sponsor and also to the investigator for assessment of clinical significance for any abnormal values to be recorded on CRF This scenario also applies when results are captured directly via an electronic device – not recorded on the CRF

4.12.1 Scenario 1: Central processing: Where samples are taken at site, but sent out and results are provided separately or where results are captured directly by an electronic device and transmitted separately – not recorded on the CRF Lab Data Collection Variables (CRF data captured at the site for tracking/ header reconciliation The variables for test results are not defined here, as this data is not part of the CRF)

1 Date of Collection LBDTC Date of sample collection Record the date when sample collection occurred using the international date format

For more detail see the Best Practice section.

The date of collection may be derived from the date of visit and if so, a separate assessment date field is not required

Variable LBDTC is derived by concatenating CDASH Date and Time of collection (if time is collected) into LBDTC using the ISO 8601 format

Time of collection Record time of collection (as complete as possible)

The LBSTAT status indicates whether a laboratory test has been completed, applicable to either an entire panel or individual tests This feature serves as a data management tool, ensuring the accuracy and verification of provided results.

Type of draw / category / panel name

Used to define a category of related records

Record the lab test category, if not pre- printed on the CRF

To be included if "Not Done's" are collected for each panel (e.g.,

5 Planned Time Point LBTPT Relative time for use when multiple sequential assessments are done

Record the planned time point labels for the lab test, if not pre-printed on the CRF

Conditions for sampling defined in the protocol

The specific testing conditions required should be pre-printed on the CRF, such as

“Did patient meet fasting requirements?”

Results may be affected by whether conditions for sample were properly met

7 Accession Number LBREFID Internal or external specimen identifier Record the sample or accession number assigned

4.12.2 Scenario 2: Local processing: When results of sample analysis are reported directly on the CRF

The LBSTAT lab status indicates whether a laboratory test was conducted, applicable to either an entire panel or individual tests This tool is designed for effective data management, ensuring the accuracy of the results provided.

Record the lab test category, if not pre- printed on the CRF

Included as needed for clarity (e.g.,

5 Planned Time Point LBTPT Relative time for use when multiple sequential assessments are done

7 Sample Status LBSPCCND Free or standardized text describing the condition of the specimen

Record condition of sample (e.g., HEMOLYZED, ICTERIC,

Verbatim name of the test or examination used to obtain the measurement or finding Note any test normally performed by a clinical laboratory is considered a lab test

Record the wording of the lab test, if not pre-printed on the CRF

Required to identify the test It is recommended that the test names be pre- printed on the CRF

9 Test Result LBORRES Result of the measurement or finding as originally received or collected

Record test results Key data collected Highly

10 Units LBORRESU Original units in which the data were collected

Record the units of the lab test, if not pre- printed on the CRF or captured in an external ‘lab normal’ file

May be included if not standardized Highly

Normal range for continuous measurements in original units

Normal values for non-continuous measurements in original units

Record the normal range of the lab test LBORNRLO and LBORNRHI should be populated only for continuous results;

LBSTNRC should be populated only for non-continuous results This data may be obtained from the central lab or the electronic equipment

Not required when lab data is not recorded on CRF

12 Abnormal Flag LBNRIND Reference Range Indicator Indicates where value falls with respect to reference range defined by high and low ranges

Record whether sample was within range May be included if not derived Recommended/

Whether lab test results were clinically significant

Record whether lab results were clinically significant

14 Lab Name LBNAM Name of lab analyzing sample Record the laboratory name May be included on CRF if not standardized by clinical trial site

15 Accession Number LBREFID Internal or external specimen identifier

Record the sample or accession number assigned

May be included for linking back to samples (e.g., Specimen ID)

4.12.3 Scenario 3: Central processing but CRF includes site assessment of clinical significance In this scenario, data is sent for central processing Results are returned to the sites, and the sites complete a CRF page of clinical significance for any abnormal / unexpected values The actual testing results are transmitted electronically, as in scenario 1, but the CRF includes the data necessary to identify and rate the clinical significance of the abnormal results

The LBSTAT status indicates whether laboratory tests have been conducted, applicable either to an entire panel or on an individual test basis This tool serves as a data management resource to confirm the accuracy of the results provided.

Record the lab test category, if not pre-printed on the CRF

Optional if already provided from central lab (e.g., HEMATOLOGY, URINALYSIS,

5 Planned Time Point LBTPT Relative time for use when multiple sequential assessments are done,

7 Test Name LBTEST Verbatim name of the test or examination used to obtain the measurement or finding Note: any test normally performed by a clinical laboratory is considered a lab test

Record the wording of the lab test if not pre- printed on the CRF

Required to identify the test It is recommended that the test names be pre- printed on the CRF

8 Test Result LBORRES Result of the measurement or finding as originally received or collected

Record test results Optional if already provided from central lab

Whether lab test results were clinically significant

Record whether lab results were clinically significant

Key data collected in this scenario Highly

10 Lab Name LBNAM Name of lab analyzing sample Record the laboratory name May be included on CRF if not standardized by clinical trial site

11 Accession Number LBREFID Internal or external specimen identifier Record the sample or accession number assigned

May be included for linking back to samples (e.g., Specimen ID)

Medical History – MH (Events)

This effort focused solely on General Medical History, while also taking into account indication-specific histories, such as Oncology, in the definitions of variables like MHCAT The decision to concentrate on General Medical History stems from the need for greater detail in indication-specific histories However, it is feasible to document these specific histories on the forms if the protocol allows for it without necessitating additional information beyond the optional variables.

An examination of example Case Report Forms (CRFs) and regulatory requirements revealed that both relevant medical history and the disease being studied can be documented as General Medical History While the specific protocol may not necessitate a comprehensive list of all conditions, it is essential to concentrate on particular diseases or conditions that are of concern.

The article discusses the regulatory requirements for coding Medical History, highlighting that while the FDA does not mandate the use of MedDRA, it is recommended No specific coding recommendations are provided Instead, a strategy for organizing uncoded Medical History through conditional variables is suggested Sponsors must define categories for uncoded Medical History Events, utilizing the MHSCAT variable For those who do code Medical History, dictionary variables will be employed for the coded terms.

1 Reported Term MHTERM Verbatim or preprinted CRF term for the medical condition or event

Document all relevant past medical conditions and surgeries, listing each condition or surgery on a separate line When noting a condition that is associated with a surgery, provide one line for the condition and another for the corresponding surgery It's essential to ensure that the conditions recorded on the Medical History page do not fall under any exclusion criteria.

Note that if Sponsors need to capture more detailed surgery information (e.g.,

VNS implantation for Epilepsy trials), an additional CRF module should be used, modeled as an Interventions domain

2 Ongoing / Resolved MHONG Identifies the end of the event as being

Select the most appropriate response Note that MHONG is not defined in the

SDTM MH domain If collected, it should be used to derive to MHENRF

The visit date or completion date recorded in the CRF header, should be used as a reference point

3 Medical History Flag MHYN Lead prompt for the Medical History

(e.g., “Has the subject experienced any past and / or concomitant diseases or past surgeries?”)

If the individual has a history of previous or concurrent illnesses or has undergone any surgeries, please select "Yes" and provide the necessary details If there are no such conditions, simply select "No" and leave the section empty.

Note: MHYN is not defined in the SDTM

MH domain Some sponsors may find this data point useful from an administrative perspective It should not be included in the submission

MHSPID Optional sponsor-defined reference number (e.g., Preprinted line number)

Not applicable Some sponsors may pre-number the rows used to capture the data If these identifiers are submitted, MHSPID should be used

MHCAT Used to define a category of related records (e.g., CARDIAC or

The sponsor has the option to pre-print the type of medical history on the Case Report Form (CRF), which can be beneficial if specific medical histories, such as disease diagnoses, are recorded alongside general medical history However, it is important to note that the Medical History Capture and Tracking (MHCAT) can still be populated in the database regardless of whether the history type is pre-printed.

Note: MHCAT must be in the database if MHSCAT is used

MHSCAT A categorization of the condition or event pre-printed on the CRF or instructions

Note: the CRF instructions will depend upon the format of the CRF Some sponsors ask the sites to use a numeric code (e.g.,

Sponsors may use specific codes, such as "123," to identify categories like "cardiovascular," while others opt to pre-print these categories on the Case Report Form (CRF) and allow sites to fill in details regarding the ailment, disease, or surgery.

Utilize the sponsor-defined code list to categorize past and/or concurrent medical conditions or surgeries For instance, if an individual has a history of high blood pressure, assign code "123" for "cardiovascular."

Record the concomitant medical conditions or past surgeries under the appropriate category For example, “high blood pressure” should be recorded under

Pre-printed groupings are essential when the sponsor opts not to code medical history, as these categories must be defined by the sponsor to accommodate varying needs For instance, the code “123” mentioned in the instructions serves merely as an example.

Using MedDRA System Organ Classes (SOCs) as categories on the Case Report Form (CRF) is not advisable due to several factors Firstly, many sites may lack familiarity with these SOCs, which could lead to confusion Additionally, incorporating all 26 organ classes into the CRF would complicate the entry screen and completion instructions Furthermore, reviewers anticipate that this information will be recorded in the MHBODSYS system instead.

Finally, the sponsor may only wish to inquire about particular groupings or specific diseases; not actual body systems

Note that “123” would not be stored in MHSCAT In this example,

Numeric codes used on the CRF as an operational tactic to facilitate data entry must be removed prior to submission as they provide no meaning to the reviewer

Also Note that MHCAT must be in the database if MHSCAT is used

7 Pre-printed prompt for a specific condition/surgery

(e.g., Does the subject have high blood pressure?)

MHOCCUR A pre-printed prompt used to indicate whether or not a medical condition has occurred

Please indicate if “xyz” has occurred by ticking “Yes” or “No”

MHOCCUR is applicable only when the condition specified on the CRF prompts a clear Yes or No answer It should not be utilized if the conditions on the CRF necessitate a free-text response.

8 Onset Date MHSTDTC Start Date of Medical History Event Record the onset date using the international date format For more detail see the Best Practice section

The sponsor may choose to capture a complete date, or any variation thereof (month & year or year, etc.)

Variable MHSTDTC is derived by concatenating CDASH Onset Date and Time (if time is collected) into MHSTDTC using the ISO 8601 format

9 End Date MHENDTC End Date/Time of Medical History

Record the end/resolution date The sponsor may choose to capture a complete date, or any variation thereof (month & year or year, etc.)

Physical Examination – PE (Findings)

The physical examination data collection tables are designed for general assessments within overall safety data collection, but may not meet the specific needs of targeted body system evaluations in therapeutic areas The team categorized the Physical Examination (PE) forms into three usage types: first, using a PE form at both baseline and post-baseline visits; second, utilizing a PE form at baseline only, while recording any post-baseline abnormalities or worsening baseline conditions on the Adverse Event (AE) form; and third, using a PE form solely to confirm whether the examination was conducted, along with its date Additionally, sites are instructed to document baseline abnormalities on the medical history forms or targeted medical history forms, and to report any post-baseline issues on the AE form or other sponsor-defined forms.

Options a and b captured similar variables such as the exam date, body system/code, normal/abnormal status, and descriptions of abnormalities However, as the team deliberated, the advantages of option c began to surpass the conventional methods used in options a and b Key factors supporting the recommendation of option c as the best practice include its enhanced effectiveness and efficiency in addressing the identified variables.

The process streamlines data management by centralizing the capture of abnormal data, thereby eliminating the need for duplicate data collection and reconciliation It is essential to document any abnormalities identified during a physical examination on an Adverse Event (AE) form, medical history form, or a comparable document.

• Reduces number of queries, thus reducing workload for data managers and site personnel

To ensure consistency in data reporting, team members surveyed their medical writing and biostatistics departments, discovering that physical examination data is predominantly presented in tabular listings rather than summarized Trend analysis and summarization of abnormalities are primarily conducted on adverse event (AE) data, while medical history data is accessible for reference.

• Reduces coding needs (if PE abnormalities are coded)

Option c signifies a significant shift from conventional methods of collecting physical examination data The team proposes an alternative approach outlined in section 16.1, which is recommended as best practice In contrast, section 16.3 presents the traditional method for gathering physical examination data.

Definition Instructions to Clinical Site Implementation /

PESTAT Used to indicate if exam was not done as scheduled

If physical examination was not performed as planned then select ‘Not Done’, otherwise no action is needed

BASELINE: If examination is performed, CRF and CRF Instructions will direct site to report all abnormal findings/conditions on appropriate CRF (e.g., Medical History,

POST-BASELINE: If examination is performed and abnormality is new or worsened, CRF and CRF Instructions will direct site to capture all changes on appropriate CRF (e.g., Post-baseline

2 Date of Examination PEDTC Date of examination Record complete date of examination, day, month and year using the international date format For more detail see the Best Practice section

The date of examination may be derived from the date of visit and therefore a separate assessment date field is not required

Variable PEDTC is derived by concatenating CDASH Date and Time of Examination (if time is collected) into PEDTC using the ISO 8601 format

Time of examination Record the time of examination (as complete as possible) For more detail see the Best Practice section

Physical exams will be conducted for subjects according to each study's protocol schedule During these exams, the PE CRF page will be utilized to document whether the exam occurred and, if applicable, the date and time of the exam Sites are required to record any abnormalities found during the exam on the relevant CRF pages For baseline visits, abnormal findings should be reported on forms like Baseline Assessment, Medical History, or Adverse Event For post-baseline visits, appropriate forms include Post-Baseline Assessment or Adverse Event.

PEDONE Used to indicate if exam was not done as scheduled

If physical examination was not performed as planned then select ‘Not Done’, otherwise no action is needed

A subject/page level question can be used asking the site if the physical exam was performed at the specified time point

In cases where this field is utilized, the results should be mapped to PESTAT only if a comprehensive examination at the subject level has not been conducted If the examination has taken place, the PESTAT value will be null for the examined body systems, while body systems that were not examined will be marked as "Not Done."

2 Date of Examination PEDTC Date of examination Record complete date of examination, day, month and year using the international date format For more detail see the Best Practice section

The date of examination may be derived from the date of visit and therefore a separate assessment date field is not required

Time of examination Record the time of examination (as complete as possible).For more detail see the Best Practice section

PESPID Sponsor defined reference number None May be pre-printed on the CRF as an explicit line identifier or defined in the sponsor’s operational database

PETEST Verbatim term for the body system Per protocol, perform physical examinations of specified body systems

Sponsors should ensure that the Case Report Form (CRF) includes a comprehensive list of all body systems to be examined This approach removes the necessity for an "other/specify" category, as any identified abnormalities will be categorized under the predefined systems.

Regardless of whether the sponsor mandates the examination of all body systems at a specific time point, it is essential to utilize the complete list Sites should be instructed to enter 'Not Done' in the Exam Result field for any systems that are not examined.

6 Examination Result PERES Overall assessment of examined body system

For each body system listed, record the result of the examination (Normal or Abnormal) If the examination is not performed or not required select Not Done

For each body system listed on the CRF, provide the following options for results:

Normal, Abnormal and Not Done Sites should be directed to complete overall assessment for each exam category/body system listed

When assessing a body system, if it is found to be normal, the PEORRES value should be recorded as NORMAL In cases where the body system has not been examined, PEORRES should be set to Null, and PESTAT should indicate Not Done If the examination reveals an abnormality, PEORRES must include a description of the abnormal findings.

7 Abnormal Findings PEDESC Text description of any abnormal findings

Record all abnormal findings for the given body system in the space provided

Text entered under abnormal findings (PEDESC) should be mapped to PEORRES

8 Evaluator PEEVAL Role of the person who provided the evaluation

Enter the role of the person who provided the evaluation (e.g., investigator, adjudication committee, vendor)

Used only for results that are subjective

Should be null for records that contain collected or derived data

Protocol Deviations – DV (Findings)

4.15.1 Considerations Regarding Usage of a Protocol Deviations CRF

The Protocol Deviations sub-team advises against creating a Protocol Deviations Case Report Form (CRF), though individual sponsors may decide based on their company's needs Most participants noted that their organizations do not use specific CRFs for protocol deviations, relying instead on other CRF domains or system functionalities The sub-team did create a CDASH data collection standard for Protocol Deviations, aligning it with the SDTM DV domain, but did not classify any variables as highly recommended The DV table serves as a helpful guide for clinical teams in designing a Protocol Deviations CRF and study database if they opt to develop one.

Sponsors should not solely depend on a Protocol Deviations CRF for information on protocol deviations in a study Instead, they should incorporate monitoring, data review, and programming tools to evaluate any deviations that could impact the efficacy and safety datasets By leveraging this comprehensive information, sponsors can make informed decisions on the best methods for their company.

1 Were there any protocol deviations?

DVYN Indication of whether or not there was a protocol deviation

Enter “Yes” if a protocol deviation occurred and “No” if none occurred and subject has completed treatment

May be derived in the analysis (submission) dataset

DVTERM Verbatim text of the variation from processes or procedures defined in a protocol

Record protocol deviation identified This may be derived from clinical data or captured in the clinical data management system

DVDECOD Controlled terminology for the name of the protocol deviation

Select appropriate code from list of protocol deviation terms

May capture this programmatically or manually (manual may be a combination of manual review and programmed coding)

DVCAT Category of the deviation criteria Would not be entered by clinical site May be derived by the sponsor May be sponsor-defined (e.g., MAJOR or

The start date of the protocol deviation, referred to as DVSTDTC, must be recorded in the International date format Ensure to document the complete date when the protocol deviation commenced, and for further guidance, please refer to the Best Practice section.

This should be the start or occurrence of the protocol deviation and not the date it was discovered or reported

Variable DVSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into DVSTDTC using the ISO 8601 format

Start time of the protocol deviation If appropriate, record the time (as complete as possible) the protocol deviation began

For more detail instructions see the Best Practice section

This should be the start or occurrence of the protocol deviation and not the time it was discovered or reported

Variable DVSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into DVSTDTC using the ISO 8601 format

7 End Date DVENDT End date of protocol deviation Record the date that the Protocol deviation ended using the international date format

This should be the date the protocol deviation stopped and not the date it was discovered or reported

Variable DVSTDTC is derived by concatenating CDASH End Date and Time (if time is collected) into DVSTDTC using the ISO 8601 format

End time of protocol deviation Optionally, if appropriate, record the time (as complete as possible) the protocol deviation ended

This should be the time the protocol deviation stopped and not the time it was discovered or reported

Variable DVSTDTC is derived by concatenating CDASH End Date and Time (if time is collected) into DVSTDTC using the ISO 8601 format

9 Trial Epoch EPOCH Epoch associated with the start date/time of the protocol deviation

Record Epoch associated with the start date/time of the protocol deviation (e.g.,

TREATMENT PHASE, SCREENING and FOLLOW-UP)

May be derived in the analysis (submission) dataset

10 ID # DVSPID Sponsor-defined reference number Can be pre-printed on the CRF as an explicit line identifier or defined in sponsor’s operational database (e.g., Line number on a CRF page)

The team advises against recording protocol deviations on a Case Report Form (CRF), as this data is generally captured within the CRF or can be derived from existing information The SDS team has established the DV domain within the SDTM framework to specifically include only the protocol deviations documented on a designated protocol deviations CRF, while any derived protocol deviations should be reported in ADAM.

Subject Characteristics – SC (Findings)

Record the date of collection for subject characteristic data using the international date format, as outlined in the Best Practice section for detailed instructions.

The date of collection may be derived from the date of visit and if so, a separate collection date field is not required

Variable SCDTC is derived by concatenating CDASH Date and Time of Collection (if time is collected) into SCDTC using the ISO 8601 format

Time of collection Record the time (as complete as possible) of collection of subject characteristic data For more detail instructions see the Best Practice section

Record detailed information only when essential for analysis If the collection time can be inferred from the visit time, a separate field for collection time is unnecessary.

Variable SCDTC is derived by concatenating CDASH Date and Time of Collection (if time is collected) into SCDTC using the ISO 8601 format

The age (in weeks) of the newborn infant, counted from the first day of the woman’s last menstrual period (LMP) or health status indicators / Clinical Estimate (CE)

A constant that may be useful for analysis in pediatric or neonatal studies

4 Eye Color SCTESTCD Natural eye color Record the subject’s eye color Optional

5 Childbearing Potential SCTESTCD Subject’s childbearing potential Check the correct box to indicate the subject’s childbearing potential, or postmenopausal or sterilized as required for the form

6 Education SCTESTCD Education level achieved at start of study (Reference date)

SCTESTCD Sub-study participation information For some Phase 1 studies sub-study information is captured, such as “subject is on fasting sub-study” or “subject is on PK sub-study”

Substance Use – SU (Interventions)

The main recommendation is to avoid categorizing the initial response to a Yes/No flag question regarding substance use, instead opting for a more detailed response of 'Never, Current, or Former.' This approach, utilizing the prompt variable SUPPSU QNAM SUNCF, aligns with the diverse definitions of substance use protocols defined by sponsors By adopting these categories, numerous questions related to usage and frequency can be streamlined, effectively reducing the number of data points needed in the Substance Use Domain Additionally, optional details regarding duration, quantity, and specific start and stop dates can be collected for a more comprehensive understanding.

1 Type of Substance SUTRT The type of substance (e.g., TOBACCO,

Sponsors may request various types of substance use data, including information on illicit drug use and dietary habits The category value for this data may be pre-printed on the Case Report Form (CRF) as a label for the Prompt for Substance Use.

When a specific substance such as cigarettes or cigars is indicated on the CRF, the SUCAT should be categorized as "tobacco" and the SUTRT should be specified as "cigarettes." If the sponsor does not provide a specific type of tobacco on the CRF, then the SUTRT should default to "tobacco."

In the SUNCF Substance Use Occurrence assessment, please indicate the subject's tobacco, alcohol, and caffeine use by selecting the appropriate option: whether they have never used these substances, currently consume them, or have previously used them.

The team recommends the use of NEVER, CURRENT and FORMER as responses

The three options, NEVER, CURRENT and FORMER should be sponsor-defined

If the sponsor has specific definitions for the three, these definitions should be detailed in the instructions to the site

As this type of response does not easily correspond to an SDTM variable The Team recommends using SUNCF as the variable name in the clinical database

Note that SUNCF is not defined in the SDTM and, generally, should be dropped prior to submission If submitted, it should be stored in SUPPSU

Note that NEVER maps to SUOCCUR as

“N” CURRENT and FORMER map to SUOCCUR as “Y”

3 Type of Substance SUCAT Used to define a category of related records (e.g., TOBACCO, ALCOHOL,

Sponsors may request various types of substance use data, including illicit drug use and dietary information The category value may be pre-printed on the Case Report Form (CRF) as a label for the Prompt for Substance Use.

When a specific type of substance, such as cigarettes or cigars, is indicated on the Case Report Form (CRF), the Substance Use Category (SUCAT) should be recorded as "tobacco," while the Substance Type (SUTRT) should be noted as "cigarettes." If the sponsor does not specify a tobacco type on the CRF, the SUTRT should default to "tobacco."

4 Amount SUDOSTXT Substance use consumption amounts or a range of consumption information collected in text form [e.g., 1-2 (packs),

Tick the appropriate box to indicate the amount of tobacco / alcohol / caffeine the subject consumes on a regular basis

Where possible, the options for dose/amount should be pre-printed on the CRF

Note that in example given in the Definition, “(packs)” and “(ounces)” have been included as a point of reference They would, of course, be stored as SUDOSU

If the dose is part of a planned analysis, then the use of SUDOSE, a numeric variable, should be considered

5 Unit SUDOSU Units for SUDOSTXT (e.g., PACKS,

Not applicable Where possible, the options for dose/amount units should be pre-printed on the CRF

6 Frequency SUDOSFRQ Usually expressed as the number of uses consumed per a specific interval (e.g.,

PER DAY, PER WEEK, OCCASIONAL)

Not applicable Where possible, the options for dose/amount frequency should be pre- printed on the CRF

7 Start Date SUSTDTC Date substance use started Record the start date using the international date format For more detail instructions see the Best Practice section

Variable SUSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into SUSTDTC using the ISO 8601 format

Time substance use started Record the start time (as complete as possible) For more detail instructions see the Best Practice section

Variable SUSTDTC is derived by concatenating CDASH Start Date and Time (if time is collected) into SUSTDTC using the ISO 8601 format

9 End Date SUENDTC Date substance use ended Record the end date using the international date format For more detail instructions see the Best Practice section

Variable SUENDTC is derived by concatenating CDASH End Date and Time (if time is collected) into SUENDTC using the ISO 8601 format

Time substance use ended Record the end time (as complete as possible) For more detail instructions see the Best Practice section

Variable SUENDTC is derived by concatenating CDASH End Date and Time (if time is collected) into SUENDTC using the ISO 8601 format

11 Duration SUDUR The duration of the substance use (e.g., Record how long the subject has smoked)

This should only be collected on the CRF if this level of detail is needed and if SUSTDTC & SUENDTC are not collected on the CRF

To ensure accurate data collection, sponsor-defined options such as weeks, months, and years should be pre-printed on the Case Report Form (CRF) instead of allowing free text entries This approach facilitates the conversion of responses into ISO 8601 format, enhancing consistency and standardization in data reporting.

Vital Signs – VS (Findings)

The review of vital signs data elements was simplified as all sponsor-reviewed CRFs captured consistent data aligned with the SDTM VS domain A key discussion point was linking collected elements to SDTM-defined variables Many VS CRFs record each unique result in separate fields, resulting in distinct variables in the clinical data management system The SDTM VS domain employs a normalized structure, using one variable, VSTESTCD, for the test name and another, VSORRES, for the result The team proposed two options for the VS variable definition table: a normalized structure in line with SDTM and an alternative with unique variables for each test, with the former being favored for consistency across other findings domains.

VSDTC Date of measurements Record date of measurements using the international date format For more detail instructions see the Best Practice section

The date of measurement may be derived from the date of visit and therefore a separate measurement date field is not required

Variable VSDTC is derived by concatenating CDASH Date and Time of Vital Sign Measurements (if time is collected) into VSDTC using the ISO 8601 format

VSSPID Sponsor defined reference number None Pre-printed on the CRF as an explicit line identifier or defined in the sponsor’s operational database

VISITDY Study day of measurements, measured as integer days

None This may be a pre-printed field on the CRF, or more likely, a derived variable

4 Planned Time Point VSTPT Text description of time when measurement should be taken

None If applicable, this will be pre-printed on

CRF when measurements are required at multiple time points within a visit day

Time of measurements Record time of measurement (as complete as possible) For more detail instructions see the Best Practice section

Variable VSDTC is derived by concatenating CDASH Date and Time of Vital Sign Measurements (if time is collected) into VSDTC using the ISO 8601 format

6 Vital Sign Test Name VSTEST Verbatim name of the test or examination used to obtain the measurement or finding

Record the name of the vital sign test if not pre-printed on the CRF

It is recommended that the test names be pre-printed on the CRF

7 Vitals Status VSSTAT Used to indicate that a vital signs measurement was not done

If measurement not taken please indicate on CRF by selecting Not Done

If CRF design provides for individual status check boxes where site can indicate Not Done for the given parameter, information would be stored as Not Done in VSSTAT

If value exists in VSORRES then the result in VSSTAT is Null

According to CRF guidelines, if a site indicates "Not Done" or similar text in the result field, then the value of VSSTAT should be set to "Not Done." Conversely, if there is a numeric value present in the result variable (VSORRES), the value of VSSTAT should be assigned as Null.

8 Vital Sign Test Result or Finding

VSORRES Result of the vital signs measurement as originally received or collected

Record vital sign results Key data collected Highly

9 Original Units VSORRESU Original units in which the data were collected

Record or select the unit of measure associated with the test, if not pre-printed on the CRF

It is recommended that the units be pre- printed on the CRF when possible

VSLOC Location on body where measurement was performed

Record or select location on body where measurement was performed, if not pre- printed on CRF

Location may be pre-defined as part of CRF label

11 Position of Subject VSPOS Position of the subject during a measurement or examination

Document the subject's position at the time of testing This position may be specified in the Case Report Form (CRF) label, or the site may have multiple options to choose from.

The CDASH Project follows the CDISC Operating Procedure (COP-001) for Standards Development

(http://www.cdisc.org/about/bylaws_pdfs/CDISC-COP-001-StandardsDevelopment-Feb2006.pdf) Following is flow diagram that describes Stage II: Standards Development/Revision/Release of Version 1.0

The CDISC Standards Development Process requires at least three reviews to achieve consensus on the Version 1.0 standard Initially, domain-specific recommendations from teams undergo evaluation by the internal CDISC Technical Leadership Committee (TLC) to ensure alignment with existing CDISC standards These recommendations are then compiled into 'review packages' for external assessment by the Collaborative Group, which serves as a focus group for the CDASH Project Finally, all domains will undergo a comprehensive public review before the official release of Version 1.0.

The development of the Reviewed Versions (RV) in this document is based on the CDISC SDTM variable tables as a foundational reference While CDASH and SDTM variables may differ, SDTM variables focus on standardizing results for regulatory submissions, whereas CDASH variables are intended for data collection Additionally, the CDASH project emphasizes the collection of a minimal set of essential data variables, while SDTM encompasses a broader range of variables for comprehensive reporting.

• agree on basic data collection variables,

• map these variables to SDTM, to add definitions

• write instructions for investigative sites and for study Sponsors

During the initial CDASH Kick-off meeting in October 2006, ACRO presented the following guiding principles These guiding principles were reviewed at the initiation of each team

• Ensure that SDTM “required” elements are addressed directly or indirectly

• Be “standard” yet flexible to allow customization within defined limits

• Limit variables to required and necessary

• Comply with regulatory requirements (see Appendix E)

• Reduce redundancies; do not duplicate information found elsewhere in CRFs

• Increase collection of meaningful data

• Facilitate use of standards by all users

• Be appropriate for use in both pre- and post- approval studies

• Allow consistent and efficient collection, transmission, analysis and archival of data

The teams initiated their review by examining CRF samples provided by ACRO, along with additional industry-used CRF samples They documented the data collection variables assessed and justified their decisions for including or excluding these variables in the CDASH recommendations.

Each variable is categorized under a CDASH Core category, which includes Highly Recommended, Recommended, Conditional, and Optional Variable labels and definitions were created accordingly The SDTM submission variables are designated as the target for deliverable data, with data collection variables being mapped to the relevant SDTM variables where applicable.

Data collection variables that were reviewed and determined to be generally considered not necessary to collect (e.g., can be derived collected elsewhere) are included in the document in Appendix D

Each team is divided into sub-groups responsible for reviewing CRF samples, conducting quality control checks, and establishing administrative procedures Weekly or bi-weekly teleconferences serve as a platform for communication, allowing team members to discuss and identify essential data collection variables within specific domains.

In addition, team members were encouraged to collected feedback from numerous functional areas within their respective companies (including ex-US affiliates)

The CDASH project work is performed primarily by volunteers representing Pharmaceutical and

Biopharmaceutical companies (~50%), Contract Research Organizations (42%), Academia and

The CDASH Core Team consists of 15 qualified members from various disciplines, each contributing to safety domain teams or overseeing aspects of the final consolidated CDASH document For a detailed list of team members and their specific responsibilities, please refer to Appendix 6.

The Core Team played a crucial role in implementing the project plan by conducting regular conference calls and in-person meetings to meet strategic goals Each member of the Core Team oversees one or more teams of dedicated volunteer participants.

Teams were formed through an open invitation for volunteers, focusing on diversity by including representatives from various companies and functional areas, as well as multinational participation when feasible Each team consisted of 10 to 40 members.

APPENDIX B: Data Collection Variables Generally Considered Not Necessary to

This document includes variable tables that offer reviewers insights into the rationale behind the CDASH recommendations The variables listed have been assessed by the teams and deemed "generally unnecessary to collect on the CRF," with the reasons for these determinations provided in the "rationale" column.

The example Case Report Forms (CRFs) shared by volunteers illustrate various data collection variables; however, these tables serve as a sampling rather than an exhaustive list of all possible variables observed on CRFs.

There are no variables “Generally Considered Not Necessary for Collection on the CRF” listed for Comments, Physical Exam, Subject Characteristics and Vital Signs domains

Study Identifier Unique identifier for a study within the submission Collected in header or derived

Domain Abbreviation Two-character abbreviation for the domain most relevant to the observation

Unique subject identifier within the submission Collected in header or derived

Sequence Number Sequence number given to ensure uniqueness within a dataset for a subject Can be used to join related records

Group ID Used to tie together a block of related records in a single domain to support relationships within the domain and between domains

Reference ID Optional internal or external identifier Not needed

Optional Sponsor-defined reference number Perhaps pre- printed on the CRF as an explicit line identifier or defined in the sponsor’s operational database (e.g., line number on a Disposition page)

In general, this is not needed Some teams, however, have included this variable as optional when it would be useful

2 Numeric version of VISIT, used for sorting

Collected in header or derived

Planned Study Day of Visit

Not needed on the CRF

1 Study day of medical history collection, measured as integer days

2 Algorithm for calculations must be relative to the sponsor-defined RFSTDTC variable in

Demographics This formula should be consistent across the submission

Used when the occurrence of specific adverse events is solicited to indicate whether an adverse event occurred or not

Considered redundant, can be addressed during analysis

Continuing Flag Identifies an event that is ongoing at the time of a subject’s discontinuation from a study

Redundant field used for monitoring or cleaning

Expected Criteria Representation of the expectedness of the event Handled in Clinical Investigative Brochure

Duration Collected duration and unit of an adverse event Derived

Event diagnosis Provides the sender with an opportunity to combine signs and symptoms that were reported into a succinct diagnosis

Ongoing as of Date Gives reference to when the subject was last contacted to determine if the AE was still ongoing

Considered a redundant field, captured in other fields: Blank Stop Date and Outcome

Time Course Helps understand the nature of the AE Derived variable

Is this AE the reason for withdrawal from the study?

Captured elsewhere in the CRF (action taken)

Generic Dispensed An indicator that the drug name provided is a generic name

Assuming drug names are coded to a dictionary, this is redundant and should not also be a field on the CRF

Total Daily Dose Dose administered, standardized to amount per day, regardless of dosing interval (e.g., 200 mg BID would equate to a Total Daily Dose of 400 mg)

For general medications requiring detailed information, it is advisable to calculate or derive specifics from related fields such as Dosage Units, Dosage Amount, and Dosage Interval This approach helps prevent confusion and minimizes the need for complex calculations at the clinical site.

Response Did the condition for which the medication was taken respond to treatment

Applies to Medications of Interest

Prescription or OTC Indicate whether the drug required a prescription or if the subject obtained it OTC

This level of detail not required for General Medications

Device used to admin drug

For some drugs, such as asthma medications, the delivery device can affect the response

Was drug admin for exacerbation

Used to identify medications taken for a specific indication which has worsened

Was drug admin as a rescue Medication

Used to identify medications taken for a specific indication which has worsened

Calculated total exposure over a specified duration Applies to Medications of Interest, alternatively, can be calculated from other variables

Was drug ever used Asking if a specific medication was used (e.g., Was aspirin every used?)

Applies to Medication of Interest

Total duration Length of time subject was exposed to a drug If needed, can be calculated from Start

Date/Time and Stop Date/Time

Total duration unit Unit of time for subject exposure (e.g., minutes, hours, days, etc.)

If needed, can be derived

Was Medication stopped due to toxicity

Did the medication reach toxic levels, requiring it to be discontinued?

General Comments The team assumes that comments will be collected on a Comment CRF This comment CRF may be on the same page as the CM CRF

None Taken A single box that can be marked to indicate that no concomitant medications were taken

To eliminate ambiguity when medication details are absent, it is advisable to use a yes/no question, specifically "Were any drugs taken?" This recommendation can be found in Table 3.

Type of Medication Applies to Medications of Interest

Tiêu đề	Clinical Data Acquisition Standards Harmonization: Basic Data Collection Fields for Case Report Forms
Tác giả	CDISC CDASH Team
Thể loại	draft
Năm xuất bản	2008

Định dạng
Số trang	137
Dung lượng	877,59 KB
File đính kèm	cdash draft post.rar (795 KB)