Clinical Data Acquisition Standards Harmonization (CDASH)

Transcription

1 Clinical Data Acquisition Standards Harmonization () Prepared by: CDISC Team

2 Section Table of Contents Page 1.0 Orientation Purpose Organization of this Document General Notes Conformance to Recommendations Alignment with Other Standards The Study Data Tabulation Model (SDTM) Derived Data Data Collection Fields Not Included in the SDTM Conversion of Dates for Submission Collection of Partial Dates/Times Mapping Relative Times from Collection to Submissions CDISC Controlled Terminology Best Practice Recommendations Introduction to Best Practices Recommended Methodologies for Creating Data Collection Instruments Suggested CRF Development Workflow FAQs on Best Practices for Creating Data Collection Instruments Overview of Domain Tables Introduction Designations for Basic Data Collection Fields Explanation of Table Headers Horizontal (De-Normalized) and Vertical Data Structures (Normalized) Domain Tables Common Identifier s Common Timing s Adverse Event AE (Events) Comments CO (Special Purpose) Solicited Comments versus Unsolicited Comments Considerations Regarding Usage of a General Comments CRF Rationale Conclusion Prior and Concomitant Medications CM (Interventions) ii

3 Table of Contents Section Page General Medications Medications of Interest Non-Pharmacologic Therapies Demographics DM (Special Purpose) Collection of Age versus Date of Birth Conversion of Dates of Birth to ISO 8601 for SDTM Collection of Sex Collection of Ethnicity and Race Disposition DS (Events) Drug Accountability DA (Findings) Vertical/Normalized Horizontal/De-Normalized Example ECG Test Results EG (Findings) Scenario 1: Central Reading Scenario 2: Local Reading Scenario 3: Central Processing Exposure EX (Interventions) Inclusion/Exclusion Criteria Not Met IE (Findings) Collecting IE Data and Mapping to the SDTM IG Changes to Inclusion or Exclusion Criteria during the Study Laboratory Test Results LB (Findings) Scenario 1: Central Processing Scenario 2: Local Processing Scenario 3: Central Processing with Assessment of Clinical Significance Medical History MH (Events) Physical Examination PE (Findings) Best Practice Approach (Option A) Traditional Approach (Options B/C) Protocol Deviations DV (Events) Considerations Regarding Usage of a Protocol Deviations CRF Rationale Subject Characteristics SC (Findings) Examples of Subject Characteristics Questions (SCTEST) Substance Use SU (Interventions) Vital Signs VS (Findings) iii

4 Section Table of Contents Page 6.0 Change Control and the Process for Creating New Domains Appendices Appendix A: Commonly Used CDISC Controlled Terminology Appendix B: Regulatory References Appendix B1: Common Identifiers and Timing s Appendix B2: Adverse Events (AE) Appendix B3: Prior and Concomitant Medications (CM) Appendix B4: Demographics (DM) Appendix B5: Disposition (DS) Appendix B6: Drug Accountability (DA) Appendix B7: ECG Test Results (EG) Appendix B8: Exposure (EX) Appendix B9: Inclusion/Exclusion Criteria Not Met (IE) Appendix B10: Laboratory Test Results (LB) Appendix B11: Medical History (MH) Appendix B12: Physical Examination (PE) Appendix B13: Protocol Deviations (DV) Appendix B14: Substance Use (SU) Appendix B15: Vital Signs (VS) Appendix C: Contributors Appendix C1: Leadership Team Appendix C2: v1.1 Team Contributors Appendix C3: Participating Companies Appendix D: List of Abbreviations and Glossary Appendix E: Naming Fragments Appendix F: Acknowledgements Appendix G: Changes from V1.0 to V Appendix H: Representation and Warranties, Limitations of Liability, and Disclaimers Appendix H1: CDISC Patent Disclaimers Appendix H2: Representations and Warranties Appendix H3: No Other Warranties/Disclaimers Appendix H4: Limitation of Liability iv

5 1.0 Orientation 1.1 Purpose The Clinical Data Acquisition Standards Harmonization () Standard defines basic standards for the collection of clinical trial data. The standard is part of the Clinical Data Interchange Standards Consortium (CDISC) Technical Road Map, which is designed to realize the vision of a set of end-to-end harmonized standards for the collection and submission of data from clinical studies. The set of standards has been, and will continue to be, developed to support the streamlining of processes within medical research from the production of clinical research protocols through to reporting and/or regulatory submission, warehouse population and/or archive and post-marketing studies/safety surveillance. For more information, click on the following link: There is growing recognition around the globe that proprietary standards prevent data interchange, which is essential to effective partnering and information exchange between and among clinicians and researchers. Clinical care can reap benefits through medical research findings, and more clinicians will be interested in conducting research if the research process can be streamlined by integrating it into their clinical care workflow. CDISC encourages the adoption of its global standards for clinical research, which should continue to be harmonized with healthcare standards, to provide a means for interoperability among healthcare and research systems such that medical research can support informed healthcare decisions and improve patient safety. This document is intended to be used by persons involved in the planning, collection, management and analysis of clinical trials and clinical data, including Clinical Investigators, Medical Monitors, Clinical Research Associates (Monitors), Clinical Research Study Coordinators, Clinical Data Managers, Clinical Data and Statistical Programmers, Biostatisticians, Drug Safety, Case Report Form (CRF) Designers and other functions tasked with the responsibility to collect, clean and ensure the integrity of clinical trial data. 1.2 Organization of this Document This document has been organized into the following sections: Section 1: Orientation This section provides an overall introduction to the purpose and goals of the project, describes the organization of Standard Version 1.1, and defines Conformance. Section 2: Alignment with Other Standards This section describes the relationship of Standard Version 1.1 to the Study Data Tabulation Model Implementation Guide (SDTM IG), controlled terminology and other non-cdisc standards. Section 3: Best Practice Recommendations This section introduces the Best Practice recommendations and methodologies for creating data collection instruments. There is also a Frequently Asked Questions (FAQs) section on best practices for creating data collection instruments. Section 4: Overview of Domain Tables This section describes approaches that reflect common practice implemented by a significant number of organizations/companies, defines the core designations used throughout v1.1 and explains the table headers used in all domain tables. Section 5: Domain Tables This section describes the approach taken regarding common identifier and timing variables and contains metadata tables and/or recommendations for the following domains: Adverse Events (AE) Comments (CO) Prior and Concomitant Medications (CM) Demographics (DM) Disposition (DS) Drug Accountability (DA) ECG Test Results (EG) Exposure (EX) Inclusion and Exclusion Criteria (IE) Laboratory Test Results (LB) Medical History (MH) Physical Examination (PE) Protocol Deviations (DV) Subject Characteristics (SC) Substance Use (SU) Vital Signs (VS) 1

6 Section 6: Change Control and the Process for Creating New Domains This section describes the procedure for change control and maintenance of v1.1 as well as the procedure for creating new domains. Appendices This section provides additional background material regarding the project as well as references, changes from v1.0 to v1.1, and supplemental information relevant to implementation of v General Notes Paper CRFs vs. Electronic CRFs: The term CRF used throughout this document refers to both paper and electronic formats, unless otherwise specified. Fields vs. s: Data collection fields refers to terms that are commonly on the CRF. Data collection variables refers to what is in a clinical database. Study Treatment: The phrase study treatment has been used instead of investigational/medicinal product, study drug, test article, medical device, etc., in order to include all types of study designs and products. Mechanisms for Data Collection: Different data collection mechanisms can be used to control how data are collected, e.g., tick boxes, check boxes, radio buttons, drop-down lists, etc. For the purposes of this document, these terms will be used interchangeably. 1.3 Conformance to Recommendations Conformance is evaluated at the individual CRF level and means that: All Highly Recommended and applicable Recommended/Conditional Common Identifying and Timing s are present in the CRF or available from the operational database. All code lists displayed in the CRF use or map to current published CDISC Controlled Terminology when it is available. Subsets of published Controlled Terminology can be used. See Appendix A. The implementation of the CRF follows the Best Practice recommendations in Section 3.4 of v1.1. or is used. In cases where the data collection is done in a de-normalized presentation on the CRF, the relevant CDISC controlled terminology should be used in the or in place of the. If there is no CDISC Controlled Terminology available, the or should be standardized by the implementing organization and used consistently. As much as possible, this should be based on available SDTM variable naming fragments. One of the basic purposes of is to reduce unnecessary variability between CRFs, so QText and should be used verbatim as much as possible. Semantically consistent alternatives are acceptable in implementations where verbatim implementation of the QText or is not possible. If the QText or is represented as <prompt> in the domain tables this means that the implementer may use appropriate controlled terminology or protocol-specific wording as the prompt on the CRF. In cases where a CRF must be translated for language or cultural reasons, the implementer should ensure the translation is semantically consistent with the and in the domain tables. Proprietary questionnaires and other copyrighted data collection instruments: In order to maintain the validation of these collection instruments, studies that include these questionnaires should present the questions and reply choices in the manner that these were validated. In some cases, this may result in CRFs panels that are not conformant with the above items, or with the best practices; however, restructuring these questionnaires could invalidate them. The use of such questionnaires in their native format should not be considered to affect conformance. 2

7 Sponsors should determine what additional data fields to add to address study-specific and therapeutic area requirements, and applicable regulatory and business practices. 3

8 2.0 Alignment with Other Standards 2.1 The Study Data Tabulation Model (SDTM) v1.1 identifies the basic data collection fields needed from a clinical, scientific and regulatory perspective to enable more efficient and consistent data collection at the investigative sites. SDTM and are clearly related. The SDTM and the SDTM Implementation Guide (SDTM IG) provide a standard for the submission of data. is earlier in the data-flow and defines a basic set of highly recommended and recommended/conditional data collection fields that are expected to be present on the majority of CRFs. The data collection fields (or variables) facilitate mapping to the SDTM structure. When the data are identical between the two standards, the SDTM IG variable names are presented in the domain tables. In cases where the data are not identical or do not exist in the SDTM IG, has suggested new variable names. For these new variables, SDTM IG variable names have been provided under the Additional Information for Sponsors column where applicable. The recommendations are based on the SDTM IG version All SDTM IG Required variables have been addressed either via data collection, determined to be derivable, or can be obtained from data sources other than the CRF Derived Data The SDTM standard contains derived data whereas the data collection fields do not Data Collection Fields Not Included in the SDTM The recommendation also includes some data collection fields that are not included in the SDTM IG (e.g., Were any adverse events experienced? or Were any medications taken? ). These collection fields are intended to assist in the cleaning of data and in confirming that no data are unintentionally missing. To facilitate the use of these types of fields, suggested variable names are provided (e.g., AEYN, CMYN) in the column and are shaded to denote that they are -suggested data collection variable names and not SDTM IG variable names. The Findings domain (DA, EG, IE, LB, SU, and VS) tables are presented in a structure that is similar to the SDTM submission model, which is to list the variable names and some examples of the tests. It is expected that implementers will include protocol-specific tests in a CRF presentation layout. Sponsors should use the recommendations to identify the types of data to collect while referring to the SDTM IG and CDISC Controlled Terminology for additional metadata, (e.g., labels, data type, controlled terminology). The standard has intentionally not reproduced other sections of the SDTM standard and implementers are asked to refer to the SDTM and SDTM IG on the CDISC website for additional information ( Conversion of Dates for Submission See section SDTM IG V3.1.2, section and for information about converting dates from the collection format to the submission format using ISO Collection of Partial Dates/Times Data collection and databasing processes should allow for the possibility of partial dates and times, since a partial date may be the most precise information that can be collected for some data. An example of when it may be necessary or appropriate to collect partial dates is found in the DM domain. In some countries, collection of a complete date of birth is restricted under privacy rules, so only a year, or year and month of birth might be collected. Other examples of commonly collected partial dates are found in CM and MH where the subject may not remember the complete date of when they started to take a medication, or when a significant medication history condition began. If a particular database does not allow for the storage of partial dates, the implementing organization may need to use separate database fields to collect year, month and day. The SDTM date format allows this partial date to be 4

9 submitted so the Reviewer can see what was collected. (If the missing parts of the date are imputed for analysis purposes, the imputed dates will be included in the analysis data, but not in the CRF data tabulations.) See Appendix E for examples of standard naming fragments (--YR, --MO, --DY, --TIM) that may be used to create variables for individual date components Mapping Relative Times from Collection to Submissions For all SDTM submissions, there is a defined period during which the subject is considered to be on study". The start and end dates of the on study period are submitted in the variables RFSTDTC and RFENDTC. The defined period may be protocol-specific, or it may be set by company policy, SOPs or other documented procedures. The on study period might be defined as being from the date/time of Informed Consent through the date/time of subject's completion of the study; or it might be from the date/time of first dose to the date/time of last dose. Regardless of how the on study period is defined, the dates (and optionally times) of the start and end of that period must be collected for all subjects. Consider the case where an Adverse Event is recorded as ongoing in a study with last dose defined as the end of the on study period. If it is known that the AE was followed to the last dose and the record updated accordingly, the assumption can be reasonably made that the AE was actually ongoing at the end of the study. However, if the Adverse Event record is not updated at the last dose, there is no way to verify if or when it resolved in relation to the end of the study period. If there is a need to collect information about whether an observation of interest occurred prior to a reference point or milestone other than the beginning of the study, or was ongoing or continuing at some reference point or milestone in the study other than the end of the defined on study period, the date/time of that reference point or milestone should also be collected. If this date/time has been collected, reasonable comparisons can be made to that date/time with prior, coincident, continuing, or ongoing questions. The following steps should be taken to ensure observations of interest that occur over time can be related to the study period in a meaningful way (SDTM variables --STRF and --ENRF): 1. To make comparisons against the on study period: Once the overall on study period has been defined, you must collect the dates (/times) of the start (e.g., date of informed consent, date of first dose) and end of that study period (e.g., date of last contact, date of last dose), as part of the clinical data with their respective domains (e.g., DS, EX). These dates will map into the RFSTDTC (start of study reference period) and RFENDTC (end of study reference period) variables in the SDTM DM dataset. 2. Collected comparisons ( prior, ongoing ) of when something started or ended in relation to the on study period (i.e., RFSTDTC-RFENDTC) will be mapped to the --STRF and --ENRF variables in the SDTM datasets when a Start Date and/or End Date are not collected. 5

10 3. To make comparisons against other reference points/milestones (SDTM variables --STTPT, STRTPT, ENTPT and ENRTPT): a. Collect start and end dates (A) for observations of interest whenever they are available, even if they are not complete (e.g., partial dates). b. When start and/or end dates are not available for observations of interest, collect a prior, coincident, ongoing flag (B, C) instead. c. Collect the date (/time) of the reference point or milestone, such as Screening Visit or Followup Visit so that a meaningful comparison can be made from the prior, coincident, ongoing flags (D, E). For information about mapping what is collected in prior, ongoing and continuing fields into the appropriate SDTM IG variables, see the SDTM IG V3.1.2 section CDISC Controlled Terminology Terminology applicable to data collection fields is either in production or under development by the CDISC Terminology Team. Production terminology is published by the National Cancer Institute s Enterprise Vocabulary Services (NCI EVS) and can be accessed via the following link: In cases where a field has associated controlled terminology, the code list is referenced in the column in the domain tables in this format: {codelist name}. In addition, the Commonly Used CDISC Controlled Terminology appendix includes subsets of controlled terminology for selected data collection fields. Although users may access directly the full EVS code lists (via the link above), we have identified the most commonly used terms as an aid for implementers. 6

11 3.0 Best Practice Recommendations 3.1 Introduction to Best Practices The Best Practices comprise the Recommended Methodologies for Creating Data Collection Instruments, a Suggested CRF Development Workflow and FAQs on Best Practices for Creating Data Collection Instruments. CRF layout are not included in v1.1, however, the Best Practices section includes some concepts related to layout because these concepts are important to consider when developing CRFs. There is arguably no more important document than the instrument that is used to acquire the data from the clinical trial, with the exception of the protocol, which specifies the conduct of that trial. The quality of the data collected relies first and foremost on the quality of that instrument. No matter how much time and effort go into conducting the trial, if the correct data points were not collected, a meaningful analysis may not be possible. It follows, therefore, that the design, development and quality assurance of such an instrument must be given the utmost attention Recommended Methodologies for Creating Data Collection Instruments Ref Methodology Rationale 1 Necessary Data Only CRFs should avoid collecting redundant data and should instead focus on collecting only the data needed to answer the protocol questions and to provide adequate safety and efficacy data. 2 Control The process of designing, printing, distributing CRFs, and accounting for unused CRFs must be controlled. The CRF development: Lifecycle should be a controlled process using a formalized, documented process that incorporates design, review, approval and versioning steps. Process should be controlled by SOPs covering, at a minimum, design, development, QA, approvals, version control and site training. Usually, only data that will be used for analysis and to assess safety of the product should be collected on the CRF due to the cost and time associated with collecting data. Data that are collected should generally be reviewed and cleaned. The Statistical Analysis Plan (SAP) should be reviewed to ensure that the parameters needed for analysis are collected and can be easily analyzed. The Statistician is responsible for confirming that the CRF collects all of the data necessary to support the analysis. A controlled process for developing CRFs will help ensure that CRFs comply with company standards and processes. 1 Good Clinical Data Management Practices, Version 4, October 2005, Society for Clinical Data Management Page 7

12 Ref Methodology Rationale 3 Adequate Review The team that designs the data collection instruments for a study should be involved in the development of the protocol and should have appropriate expertise represented on the CRF design team (e.g., statistics, programming, data management, clinical operations, science, regulatory, pharmacovigilance). 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. Programmers should review the CRF to ensure that the manner in which the data are collected on the CRF will not adversely affect the programming function. Medical and Scientific experts should provide sufficient information to ensure Clinical Data Management (CDM) staff understand the background, context, and medical relevance of the efficacy and/or safety 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 as well. Pharmacovigilance should review to ensure appropriate data capture and process to support expedited reporting. 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. Reviewers from different functions increase the probability that the CRF will be easier to complete and support the assessment of safety and efficacy. The CRF design team should ensure that the data can be collected in a manner consistent with the sponsor s processes and should also be easy for the site to complete. 4 Site Workflow The team developing the data collection instruments should consider the workflow at the site and the standard of care. The CRF should be quick and easy for site personnel to complete. Clinical Operations staff should review the CRF for compatibility with site workflow and site procedures. Although CDM may make the final decisions about CRF design, those decisions should be informed by study and user requirements. Page 8

13 Ref Methodology Rationale 5 Employ Standards Within the data collection environment, standards should be employed to collect consistent data across compounds and therapeutic areas (TA). standards should be used wherever possible and sponsor standards developed as needed. Using data collection standards across compounds and TAs saves time and money at every step of drug development. Using standards: 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 due to familiarity with standards 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. Addresses FDA Critical Path Opportunities Clarity CRF questions and completion instructions should not lead the site. 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. Data should be collected in a way that does not introduce bias or errors into the study data. Questions should be clear and unambiguous. This includes making sure that the options for answering the question are complete such as providing options for other and none when applicable. CRFs that are translated into other languages should follow the same development process as the original CRF to ensure the integrity of the data collected. Consideration of translation should be part of the CRF process and avoid the use of slang or other wording that would complicate or compromise translation into other languages. Cultural and language issues should be addressed appropriately during the process of translating CRFs to ensure the CRF questions have consistent meaning across languages. Page 9

14 Ref Methodology Rationale 8 Guidelines CRF questions should be as self-explanatory as possible, thereby reducing the need for separate instructions. When instructions are needed, prompts and short instructions may be placed on the CRF page. More detailed instructions may be presented in a CRF completion guideline. All instructions should be concise. should be standardized as much as possible. Putting short instructions and prompts on the CRF increases the probability that they will be read and followed and can reduce the number of queries and the overall data cleaning costs. Having standard instructions ensures that all sites will use the same conventions for completing the fields. Well-designed completion guidelines will also enhance the flow of the CRF. Providing short instructions and prompts on the CRF, and moving long instructions to a separate instruction booklet, facing page or checklist will decrease the number of CRFs, with the following benefits: Decreased CDM 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. 9 Data Cleaning s The database should contain an indication that an exam/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 a Check if not done box; in others it might be a blank flag or list of values to indicate why data are missing. The Yes/No assessment completed question is preferred over the Check if not done box because the Yes/No format helps to ensure that a response is provided where as it is not absolutely clear if the Not done box was missed/skipped if not checked. 10 What to database Data that are collected on CRFs should usually be databased. Some fields, such as Were there any Adverse Events Yes/No may need to be databased, but will not be included in the submission data. Some fields, such as Investigator s Signature, can be verified by the data entry staff, but an actual signature may not be databased unless there is an e-signature. This will provide a definitive indicator 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. Although the data recorded on worksheets are supporting documentation for key information collected elsewhere in the CRF, these data are not needed in the clinical database and do not need to be recorded on the CRF. If data are not required for reporting or analysis, but collecting the data aids the investigator or monitor, it is recommended that data be collected on a worksheet. Worksheets used at the investigator s site are not typically brought in-house and will not subsequently be databased (e.g., an entry criteria worksheet or a dose titration worksheet). All such worksheets should be considered source documents or monitoring tools, and should be maintained at the site with the study files. Worksheets should be developed in a parallel process along with CRF to ensure consistency. Page 10

15 3.3 Suggested CRF Development Workflow Yes Approved Protocol (or Stable Draft) Draft CRFs based on standards Modify CRFs (e.g. to be protocol specific) Review with cross functional team Changes needed? In-Study version changes (optional) No Use CRFs in study Approved CRFs Cross functional approval Finalize draft CRFs Process Complete Page 11

16 3.4 FAQs on Best Practices for Creating Data Collection Instruments Ref Question Best Practice Recommendation Rationale 1 Should No/Yes questions be preferred over Check all that apply questions? If an assessment can have composite responses (e.g., presence or absence of two or more symptoms), No/Yes questions for each component response (e.g., symptom) are preferred to Check all that apply questions. One exception to this recommendation might be assessments where the majority of options would be answered No. An example would be the collection of ECG abnormality data where approximately 45 abnormalities may be listed but only a few will apply. Another exception is the Check if ongoing question. This is a special use case of No/Yes where the question is usually presented as a single possible response of Yes in conjunction with an end date. In this case, if the box is checked, the field will contain Yes. If the box is not checked and there is an end date present, it may be set to No. No/Yes questions provide a definite answer. The absence of a response is ambiguous as it can mean No, None or that the response is missing. For the special use case for Check if ongoing, the presence of the end date provides a definitive implied response that the event is not ongoing. 2 Should there be a standard order for response boxes (e.g., Yes/No ) and other standardized lists? 3 What date format should be used for subject and sitecompleted CRF data? Use a consistent order of responses from question to question. Exceptions to this would be cases where a validated instrument (e.g. a standardized assessment questionnaire) is used. recommends the unambiguous format DD-MON-YYYY where DD is the day as a 2-digit numeric value, MON is the month as a 3-character letter abbreviation in English, or similar character abbreviation or representation in the local language, and YYYY is the year as a 4-digit numeric value. For electronic data capture (EDC), the user may be able to select a date from a calendar, and this would also meet the recommendation for an unambiguous date. If the recommended approach is not adaptable to the local language, a similarly unambiguous format should be used. If any part of a date is unknown, sponsors should define a convention to allow the site to indicate which part of the date is unknown, as is appropriate for the data management system being used. A consistent order of response boxes promotes ease of use of the CRF to help reduce data errors. It is also important that questions be carefully worded so they don t introduce bias or lead the investigator to a desired response. Using this data collection format (i.e., DD-MON-YYYY) will provide unambiguous dates. For example, the date 06/08/02 is ambiguous because it can be interpreted as June 8, 2002 or August 6, If subject-completed CRF pages are translated into a local language, the recommended date format for collection may make it easier to translate the documents. Dates are collected in this format, but reformatted and submitted as ISO See the SDTM IG and the User Guide for more information about ISO 8601 format. The method for capturing date values should allow the collection of partial dates, and should use a consistent method or convention for collecting the unknown date parts to facilitate standard programming. See the DM domain for suggested standard variable names (e.g., --YR, --MO, --DY). Page 12

17 Ref Question Best Practice Recommendation Rationale 4 What time format should be used for subject and sitecompleted CRF data? 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 database. When times are collected in a 24-hour format this eliminates the need to convert them to 24-hour format when they are formatted as ISO 8601 for submission. 5 Should manually calculated data items be recorded on the CRF? 6 Should Was assessment x performed? questions be collected? 7 Should Yes/No exam/assessment completed be preferred over Check if not done questions? Manually 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. An exception is when a treatment and/or study conduct decision should be made based on those calculations. In those cases it may be useful for the calculated field to be recorded within the CRF. It may also be useful to provide the site a step-by-step worksheet to calculate this data. The data collection instrument/crf should contain an indication that an assessment was not performed. The Yes/No assessment completed question is preferred over the Check if not done box. Data items which can be calculated from other data captured within the CRF are more accurately reported if they are calculated programmatically using validated algorithms. Capturing both the source data items and the calculated field would be a duplication of data. If the calculated field is used to make a treatment and/or study conduct decision, the results of the calculation would be required on the CRF to explain the decision made. This will provide a definitive indicator 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. The use of the Yes/No format helps to eliminate ambiguity about whether a CRF has been completed. A blank Not done can be ambiguous, i.e., if there is no data recorded in the CRF. In situations where there is no other dependent or related field to gauge the completeness of the field in question, a Yes/No response format should be used to eliminate ambiguity. One example is the Check if ongoing question. This is a special use case of No/Yes where the question is usually presented as a single possible response of Yes in conjunction with an end date. In this case, if the box is checked, the field will contain Yes. If the box is not checked and there is an end date present, it may be set to No. Page 13

18 Ref Question Best Practice Recommendation Rationale 8 Should free text be an option for a response to a specific question? (Also refer to the Comments Domain for additional information.) The general recommendation is that the collection of free text comments and general comments pages should be discouraged. Collection of free text should be limited to cases of specific safety or therapeutic need in reporting or analysis, such as Adverse Events, Concomitant Medications or Medical History. The recommendation is that questions be specific and clear rather than openended. Instead of free text comment fields, it is recommended that a thorough review of the CRF by the protocol development team be performed to maximize the use of pre-defined lists of responses. 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 time consuming for data entry and requires CDM resources to review the text for safety information and inconsistencies with other recorded data. 9 Should data be pre-populated in the CRF? 10 Should location of measurement, position of subject or method of measurement be collected for each assessment? 11 Should sites be given guidance on how to record verbatim terms for adverse events, concomitant medications or medical history in the CRF? In general, study data for each subject 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). These parameters should only be collected if the protocol specifies multiple options, or if the parameter is relevant to the consistency or meaning of the resulting data. recommends that sites record verbatim terms for non-solicited adverse events, concomitant medications or medical history reported terms. Sites should not be asked to select a preferred term from a coding dictionary as a mechanism for recording data. 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. For medical history and adverse events, this may include providing an understanding of the level of detail needed for accurate medical coding (e.g., Diabetes, Type I or Type II) and sites may be encouraged to record specific, medically correct terminology on the forms (e.g., hyperglycemia instead of high blood sugar"). The CRF is a tool to collect study data. Pre-population of some non- subject data such as investigator name, site identification, protocol number, etc. reduces errors and data entry time. Taking measurements in multiple locations may impact the value of the measurement and/or the ability to analyze the data in a meaningful way (e.g. when data obtained from different locations may bias or skew the analysis), collecting the location may be necessary to ensure consistent readings. For example, temperature obtained from the ear, mouth or skin may yield different results. Medical conditions can be coded in multiple ways in different dictionaries (MedDRA, SNOMED, WHO ART), and different people using the same dictionary may choose different codes to represent the same event. In some cases, similar codes may map into very different high-level terms. Harmonizing the coding choices between sites may be very difficult in the absence of a verbatim term. If a site has to use a list of codes to report, especially in the case of adverse events, it may limit their choices and there is a risk of introducing bias. This can also limit an organization s ability to detect trends that may affect data quality. Page 14

19 Ref Question Best Practice Recommendation Rationale 12 What should implementers consider when designing the flow order for CRFs? Headings Place fields that are routinely collected on multiple forms at the top or beginning of the form. For example, if the collection date and time are both collected, they should appear first and second respectively on each form where they are both collected. Clinical flow Fields should be placed on the form in the order that they are expected to be collected during the clinical assessment. It is acceptable to include fields from different domains on the same form. Group related fields for a single clinical encounter together, although multiple clinical encounters (ex. visits or time points) may appear together on one form. For example, if heart rate and temperature are taken every hour for four hours on study day 1, the form can collect the data for Hour 1 (heart rate result and unit, temperature result and unit), followed by the data for hour 2, and followed by hour 3 and 4. In this scenario, there would be labels indicating each time point within the Day 1. Group related fields together. Test results and their associated units should always appear next to each other. For example, the results of the ECG test PR should be followed by units. Data fields that are dependent on other data fields should be placed in the CRF in such a way that this dependence is obvious. For example, if there is a question in a paper CRF where Other, specify is an option, the text box used to specify the Other item should be placed in proximity to the Other question to indicate it is a sub-part of the Other question. An EDC example might be when a response to a question dynamically renders a related set of questions or value lists. The recommendations are general principles that may be implemented during CRF form design and /or database set up in different ways depending on the systems used. Providing the clinical site with a consistent and clinically logical order of these fields will result in less time to enter and more reliable data. Page 15

20 4.0 Overview of Domain Tables 4.1 Introduction The data collection fields included in the following domain tables are the most commonly used and should be easily identified by most implementers. It is recognized and expected that sponsors should add additional data collection fields to capture TA-specific data points as well as other data specified in the clinical study protocol or required according to local regulatory requirements. Use the recommendations when developing company standards on the sponsor level, taking into consideration the requirements of the stage of clinical development and the individual therapeutic area requirements. Standard should not be developed on a trial-by-trial basis within the sponsor organization. The domain tables are arranged in alphabetical order. CRF layout was not within the original scope of the project; however, to assist with standardization of CRF layout, data collection fields are presented within the domain tables in the order they commonly appear on a basic CRF. In addition, implementers are referred to FAQs for Best Practice for Creating Data Collection Instruments (Section 3.4) for a discussion on best practices for ordering fields on a case report form. 4.2 Designations for Basic Data Collection Fields In order to facilitate classification of the different types of data collection fields, the following categories were used: Highly Recommended (HR): A data collection field that should be on the CRF (e.g., a regulatory requirement). Recommended/Conditional (R/C): A data collection field that should be on a CRF based on certain conditions (e.g., complete date of birth is preferred, but may not be allowed in some regions; AE time should only be captured if there is another data point with which to compare it). In the absence of this data point other data points would be less meaningful. Optional (O): A data collection field that is available for use. It is assumed that sponsors will determine which data collection fields will be collected based on TA-specific data requirements, protocol and other considerations. Page 16

21 4.3 Explanation of Table Headers Question Text Information for Sponsors 1. : Contains the full question text for the data collection field. Question text may be used as the label on the CRF, or may be used in help text for the field. 2. : Contains the short prompt or label for the data collection field. 3. SDTM : Lists the SDTM-based variable name defined in the SDTM IG. ( ): This column also provides suggested variable names (e.g., CMONGO and CMTTIM). These variable names are SDTM-like variables and can help facilitate the derivation of SDTM IG variables needed for submission. 4. : This column contains the Release classification. This information is included to provide a general idea of how the variable maps to. Refer to for more information on the model. 5. : Describes the purpose of the data collection field. The text may or may not mirror the text in the SDTM IG (in the Label or CDISC Notes columns). Where applicable, CRF text examples are presented in italics. When an available code list better describes the text, a reference to the code list will be provided, in the format {code list name} (see Section 2.2 for information about controlled terminology). 6. : Contains information for the clinical site on how to enter collected information on the CRF. 7. : Contains further information, such as rationale and implementation instructions, on how to implement the CRF data collection fields. 8. : Contains the core designations for basic data collection fields (see Section 4.2 for definitions of core designations). 4.4 Horizontal (De-Normalized) and Vertical Data Structures (Normalized) Most of the Findings domain tables (EG, IE, LB, SU, and VS) are presented in a normalized structure (one record for each test) that is similar to the SDTM submission model, even though many data management systems hold the data in a de-normalized structure (one variable for each test). If you are modeling in a denormalized structure, you should create variable names for your Findings TEST and/or TESTCD values. To do this, you should generally base your variable names on available CDISC Controlled Terminology, and the variable naming conventions that are provided in the SDTM IG. Page 17

22 5.0 Domain Tables 5.1 Common Identifier s The following apply across all of the data collection domains. 1 What is the sponsor identifier? Sponsor SPONSOR Organization.identifier* A unique identifier for a study sponsor. An individual, company, institution, or organization that takes responsibility for the initiation and management of a clinical trial, although may or may not be the main funding organization. If there is also a secondary sponsor, this entity would be considered the primary sponsor. Not applicable This is typically pre-printed. It may be used as an identifier in external data warehouses (e.g. Janus) and in electronic medical records or other partnerships for sharing data. This field does not map directly to an SDTM variable. *See the model for O A corporation or agency whose employees conduct the investigation is considered a sponsor and the employees are considered investigators. 2 What is the study identifier? Protocol or Study STUDYID DocumentIdentifier. identifier* Unique identifier for a study. Not applicable. This is typically pre-printed/prepopulated. *See the model for HR Page 18

23 3 What is the site identifier? Site SITEID StudySite.identifier Unique identifier for a site within a study. Record your clinical site s identifier as defined by the sponsor. Paper: This is typically preprinted 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 recorded by the site. HR EDC: This should be prepopulated. SITENO has been deprecated in v1.1 and should no longer be used, because SDTM IG V3.1.2 has changed the SITEID variable definition to require uniqueness only within a study, and not within the submission. 4 What is the subject identifier? Subject SUBJID SubjectIdentifier.identifier Identifier assigned to each trial subject to protect the subject s identity, and used instead of the subject s name when the Investigator reports trial data. Record the identifier for the subject. Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be provided to the site using a pre-populated list in the system. HR Page 19

24 5 For this multistudy subject, what is the unique subject identifier? Unique Subject ID USUBJID SubjectIdentifier.identifier Identifier used to uniquely identify a subject across all studies or all applications or submissions involving the product. Not applicable. While in SDTM this is a Required variable for all subjects, in it may be used to record prospectively the identifier for subjects who are in multiple studies within a clinical program. O Rarely collected on the CRF. When a subject participated in more than one study or site within a development program, SDTM requires identification of the individual uniquely through this study-shared subject identifier. 6 What is the investigator identifier? Investigator INVID StudyInvestigator.identifier A unique identifier assigned to an Investigator. Record the sponsor-defined identifier for your site investigator. If an investigator is associated with more than one site or the site has more than one investigator, it may be necessary to collect this information. However, if there is only one investigator at each site, this may be equivalent to SITEID, and would not be necessary to collect. O Page 20

25 5.2 Common Timing s 1 What is the visit name? Visit VISIT PlannedActivity.name* A clinical encounter that encompasses planned and unplanned trial inventions, procedures, and assessments that may be performed on a subject. When applicable (e.g., on paper CRFs), record the visit name. This is typically pre-printed/prepopulated. *See the model for O 2 What is the visit number? Visit Number VISITNUM PlannedSubjectActivityG roup.sequencenumber A number assigned to a clinical encounter. When applicable (e.g., on paper CRFs), record the visit number. This is typically pre-printed/prepopulated. A visit number may be used to represent the chronological order of the clinical encounters. O 3 What is the visit date? Visit Date VISDAT PerformedActivity.actualDateRange* Date the clinical encounter occurred (or started). Record the date the visit took place or started in this format (DD-MON-YYYY). If the data being collected are visit-based, a date should be collected some way. This may be done once for the visit using VISDAT or may be done at the CRF level using the domainspecific --DAT field. R/C This may be recorded in either the header of the CRF or in the body of the CRF. This field does not map directly to an SDTM variable. *See the model for Page 21

26 4 What is the visit end date? Visit End Date VISENDAT PerformedActivity.actualDateRange* Date the clinical encounter ended. Record the date the visit ended in this format (DD- MON-YYYY). This is intended to be used only in cases where the start date and the end date of the visit may not be the same, e.g., sleep trials that run overnight. If this field is used, VISDAT functions as the visit start date. O This field does not map directly to an SDTM variable. *See the model for 5 What is the visit time? Visit Time VISTIM PerformedActivity.actualDateRange* Time the clinical encounter took place (or started). Record the time the visit took place (or started). Collecting the visit time is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. This may be useful in Phase I trials. O This field does not map directly to an SDTM variable. *See the model for 6 What is the visit end time? Visit End Time VISENTIM PerformedActivity. actualdaterange* Time the clinical encounter ended. Record the time the visit ended. If this field is used, VISTIM functions as the visit start time. O This field does not map directly to an SDTM variable. *See the model for Page 22

27 5.3 Adverse Event AE (Events) These recommendations are for non-solicited or pre-specified adverse events. As with all the data collection variables recommended in Standard Version 1.0, it is assumed that sponsors will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., TA-specific data elements and others as required per protocol, business practice and operating procedures). Sponsors should define the appropriate collection period for adverse events. Any AEs? AEYN PerformedObservation Result.value 1 Were any adverse events experienced? General prompt question regarding whether or not any AEs were experienced during the study. This provides verification that all other fields on the CRF were deliberately left blank. {NY} (See Section 2.2.) Indicate if the subject experienced any adverse events. If yes, include the appropriate details where indicated on the CRF. The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank. This field does not map directly to an SDTM variable. O 2 AE Identifier <line number> or <AE number> AESPID Implementation specific A sponsor-defined identifier that can be used for pre-printed numbers on the CRF. Example instruction: Record unique identifier for each adverse event for this subject. Number sequence for all following pages should not duplicate existing numbers for the subject. It can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile concomitant medications and/or medical history records with AEs. If CMAENO is used, this is the identifier to which CMAENO refers. O Page 23

28 3 What is the adverse event term? Adverse Event AETERM PerformedObservation Result.value* Verbatim (i.e., investigatorreported term) description of the adverse event. Record only one diagnosis, sign or symptom per line (e.g., nausea and vomiting should not be recorded in the same entry, but as two separate entries). Using accepted medical terminology, enter the diagnosis (if known); otherwise enter a sign or symptom. If a diagnosis subsequently becomes available, then this diagnosis should be entered on the AE form, replacing the original entries, where appropriate. In most cases, the verbatim term (i.e., investigator-reported term) will be coded to a standard medical dictionary such as MedDRA, WHO ART, after the data have been collected on the CRF. The coded data will be stored in field(s) not defined by. *See the model for HR Death should not be recorded as an event but should be recorded as the outcome of the event. The condition that resulted in the death should be recorded as the event. Do not use abbreviations. 4 Does the subject have <specific adverse event>? Example: Does the subject have high blood pressure? <specific adverse event> Example: High blood pressure AEOCCUR PerformedObservation Result.value* Used when the occurrence of a specific adverse event is solicited to indicate whether or not (N/Y) the event (AETERM) occurred. {NY} (See Section 2.2.) Please indicate if <specific adverse event> has occurred /is occurring by checking Yes or No. AEOCCUR should only be used for pre-specified adverse events as defined by the protocol. AEOCCUR should not be used for spontaneously reported adverse events. This field does not map directly to an SDTM variable. *See the model for O Page 24

29 5 What is the date the adverse event started? Start Date AESTDAT AdverseEvent.occurrence DateRange* Date when the adverse event started. Record the start date of the AE using this format (DD- MON-YYYY). For the SDTM-based dataset, the SDTM IG variable AESTDTC is derived by concatenating Start Date (AESTDAT) and Time (AESTTIM if time is collected) and converting to the ISO 8601 format. HR For more detail see the Best Practice section This field does not map directly to an SDTM variable. See the model for Page 25

30 6 At what time did the adverse event start? Start Time AESTTIM AdverseEvent.occurrence DateRange Time when the adverse event started. If appropriate, record the time (as complete as possible) that the AE began. Collecting the time an AE was started is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the event started and the study design is such that it is important to know the AE start time with respect to dosing. R/C For the SDTM-based dataset, the SDTM IG variable AESTDTC is derived by concatenating Start Date (AESTDAT) and Time (AESTTIM if time is collected) into AESTDTC using the ISO 8601 format. For more detail see the Best Practice section. This field does not map directly to an SDTM variable. Page 26

31 7 What date did the adverse event end? End Date AEENDAT AdverseEvent. occurrencedaterange* Date when the adverse event resolved. Record the date that the AE resolved using this format (DD-MON-YYYY). If the AE is ongoing, leave the field blank. For the SDTM-based dataset, the SDTM IG variable AEENDTC is derived by concatenating End Date (AEENDAT) and Time (AEENTIM if time is collected) into AEENDTC using the ISO 8601 format. HR The definition of resolved is Sponsor specific. For more detail see the Best Practice section. This field does not map directly to an SDTM variable. *See the model for Page 27

32 8 At what time did the adverse event end? End Time AEENTIM AdverseEvent. occurrencedaterange Time when the adverse event resolved. If appropriate, record the time (as complete as possible) that the AE resolved. Collecting the time an AE resolved is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the event resolved and the study design is such that it is important to know the AE end time with respect to dosing. R/C For the SDTM-based dataset, the SDTM IG variable AEENDTC is derived by concatenating End Date (AEENDAT) and Time (AEENTIM if time is collected) into AEENDTC using the ISO 8601 format. For more detail see the Best Practice section. This field does not map directly to an SDTM variable. Page 28

33 9 Is the adverse event still ongoing? Ongoing? AEONGO Implementation specific Indicates AE is ongoing when no End Date is provided. {NY} (See Section 2.2.) Check the box if the adverse event has not resolved at the time of data collection; leave the End Date blank. See section Mapping Relative Times from Collection to Submissions for more information. This field will be completed to indicate that the AE has not resolved at the time of data collection, when no End Date is collected. In some cases the ongoing status may be determined from AE Outcome O The purpose of collecting this field is to help with data cleaning and monitoring, since this field provides further confirmation that the End Date was deliberately left blank. As described in Section 3.4.1, Best Practices, this is a special use case of Yes/No. Please refer to Section for additional information. Reference Section of the SDTM IG V3.1.2 for information about mapping relative times. This field does not map directly to an SDTM variable. Page 29

34 10a What was the severity of the adverse event? Severity AESEV AdverseEvent.severity Code* Description of the severity of the adverse event. {AESEV} (See Section 2.2.) The reporting physician/healthcare professional will assess the severity of the event using the sponsor-defined categories. This assessment is subjective and the reporting physician/ healthcare professional should use medical judgment to compare the reported Adverse Event to similar type events observed in clinical practice. Severity is not equivalent to seriousness. Either AESEV or AETOXGR must appear on the CRF. Some studies may mandate the collection of both. Refer to ICH E3 guidelines for CSR Section * See the model for R/C 10b What is the toxicity grade of the adverse event? Toxicity Grade AETOXGR AdverseEvent.grade Code* Description of the toxicity grade of the adverse event. {TOXGR} (See Section 2.2.) Severity CTCAE Grade The reporting physician/healthcare professional will assess the severity of the adverse event using the toxicity grades. Either AESEV or AETOXGR must appear on the CRF. Some studies may mandate the collection of both. Refer to ICH E3 guidelines for CSR Section CTCAE grade is commonly used in oncology studies although it can also be used elsewhere. R/C * See the model for 11 Is the adverse event serious? Serious AESER AdverseEventSeriousness.code Indicates whether or not the adverse event is determined to be serious based on what is defined in the protocol. Assess if an adverse event should be classified as serious based on the serious criteria defined in the protocol. This field is related to the individual serious adverse event type fields (reference 11a to 11f), which may or may not be collected on the CRF. R/C {NY} (See Section 2.2.) Either AESER or all the AESxxx fields (12a-12f) must be present on the CRF. Page 30

35 12a 12b 12c Is the adverse event associated with a congenital anomaly or birth defect? Did the adverse event result in Persistent or significant disability or incapacity? Did the adverse event result in death? Congenital Anomaly or Birth Defect Significant Disability AESCONG Derived* Indicates if a serious adverse event was associated with a congenital anomaly or birth defect. {NY} (See Section 2.2.) AESDISAB Derived* Indicates if a serious adverse event was associated with a persistent or significant disability or incapacity. {NY} (See Section 2.2.) Death AESDTH Derived* Indicates if a serious adverse event resulted in death. Record whether the serious adverse event was associated with congenital anomaly or birth defect. Record whether the serious adverse event resulted in a persistent or significant disability or incapacity. Record whether the serious adverse event resulted in death. If the details regarding a Serious AE should be collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. In many cases sponsors will only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore do not need to be collected in the clinical database. *See the model for R/C R/C R/C {NY} (See Section 2.2.) 12d Did the adverse event result in initial or prolonged hospitalization for the subject? Hospitalization AESHOSP AdverseEvent.hospitalizationRequired Indicator Indicates if a serious adverse event resulted in an initial or prolonged hospitalization. {NY} (See Section 2.2.) Record whether the serious adverse event resulted in an initial or prolonged hospitalization. R/C 12e Is the adverse event Life Threatening? Life threatening AESLIFE Derived* Indicates if a serious adverse event was life threatening. Record whether the serious adverse event is life threatening. R/C {NY} (See Section 2.2.) 12f Is the adverse event a medically important event not covered by other serious criteria? Other Medically Important Event AESMIE Derived* Indicates if a serious adverse event is associated with other serious or important medical events. {NY} (See Section 2.2.) Record whether the serious adverse event is an important medical event, which may be defined in the protocol or in the Investigator Brochure. R/C Page 31

36 13 Is this event related to study treatment? Relationship to Study Treatment AEREL EvaluatedActivity Relationship.probabilityCode Indication of whether the study treatment had a causal effect on the adverse event, as determined by the clinician/investigator. Indicate if the cause of the adverse event is related to the study treatment and cannot be reasonably explained by other factors (e.g., subject s clinical state, concomitant therapy, and/or other interventions). Sponsored-defined terminology will be used to indicate the relationship between the AE and the study treatment (e.g. ICH E2B examples: Not Related, Unlikely Related, Possibly Related, Related). *See the model for HR 14 What action was taken with study treatment? Action Taken with Study Treatment AEACN DefinedActivity.name Code * Changes made to the study treatment in response to the adverse event. {ACN} (See Section 2.2.) Record changes made to the study treatment resulting from the adverse event. CDISC controlled terminology should be used to indicate the action taken with the study treatment in response to the AE. *See the model for HR 15 What other action was taken in response to this adverse event? Other Action Taken AEACNOTH DefinedActivity.name Code * Describes Other Action(s) taken in response to the adverse event that are unrelated to study treatment dose changes. Record all other action(s) taken resulting from the adverse event that are unrelated to study treatment. This field is usually collected as a free text field. Example: Treatment Unblinded, Primary Care Physician Notified. *See the model for O 16 What was the outcome of this adverse event? Outcome AEOUT PerformedObservation Result.value* Description of the subject s status associated with an event. {OUT} (See Section 2.2.) Record the appropriate outcome of the event in relation to the subject s status. CDISC controlled terminology should be used to indicate the outcome of the event as it relates to the subject s status. The Outcome controlled terminology includes ICH E2B values. HR *See the model for Page 32

37 17 Did the adverse event cause the subject to be discontinued from the study? Caused Study Discontinuation AEDIS Derived* Indication of whether the adverse event caused the subject to discontinue from the study. {NY} (See Section 2.2.) Record if the AE caused the subject to discontinue from the study. Since the Action Taken field was defined to only collect the changes made to the study treatment due to the AE, an additional field was created to identify the AE(s) that caused the subject to discontinue from the study. Some sponsors opt to capture this information only on the Subject Disposition CRF while others choose to collect this data on both the Subject Disposition and AE CRFs, so the specific AE term(s) and related data can be identified. O This field does not map directly to an SDTM variable. If the CRF is designed to link the DS and AE records then RELREC can be used to identify that relationship. See section 8.2 in the SDTM IG V3.1.2 for information on RELREC. *See the model for Page 33

38 5.4 Comments CO (Special Purpose) Solicited Comments versus Unsolicited Comments Solicited comments are defined as those entered in free-text data collection fields (such as Specify or Please comment ) intentionally included on the CRFs. These data collection fields provide the site with a pre-defined space to further explain or clarify an associated data collection field within the CRF. For example, the Vital Signs CRF may include a solicited comments data collection field which enables recording of free text, such as reason for performing assessment out of window. Unsolicited comments are those comments entered outside of pre-defined data collection fields (also referred to as marginal comments as they are often written in margins). These may include marginal CRF comments entered by site staff, written by the subject on diaries, or EDC capability to capture comments that are not generally included in any clinical domain. Although such comments may be intended to avoid queries, in practice they often lead to data not being entered into the correct data collection field and cause additional work in the review process Considerations Regarding Usage of a General Comments CRF Solicited comments have also historically been collected using a General Comments CRF. Most organizations contributing to the project are discontinuing or have discontinued such practices. The CO domain has no mandatory data elements for inclusion in a separate Comments CRF, and the recommendation is to avoid the creation of a General Comments CRF. This recommendation is not meant to discourage investigators from providing unsolicited comments where they are appropriate, or to discourage solicited free-text comment data collection fields that may appear within another established domain. Where comments are collected, they should use a variable naming convention that is conformant to (e.g., COVAL) Rationale Clinical data must be entered in appropriate data collection fields; otherwise, there is a potential for hidden safety events. For example, if an unsolicited general comment of subject visit was delayed as he had the flu was captured, this would necessitate that flu be entered in the Adverse Event CRF and not left as a comment. CRF development teams are encouraged to strive for data collection methods maximizing the use of pre-defined lists of responses rather than relying on a General Comments CRF. If there is no mechanism for recording general comments (not related to specific data points), it will be the responsibility of teams to design data collection tools capable of capturing all required data for analysis purposes in dedicated fields. The recommendation is that CRF development teams consider what additional information may be needed within a specific CRF. It is better to ask specific questions through creation of well-defined data collection fields rather than inconsistently capturing information within general comments data collection fields. General comments are inefficient for processing due to their variable and unstructured nature, and therefore offer limited or no value for statistical analysis, as they cannot be tabulated. An additional concern is the potential for inappropriate, or sensitive, information to be included within general comments data collection fields. For example, a comment could contain a subject s name or may have unblinding information. Unsolicited comments which may have been intended to avoid queries, for example subject visit was delayed due to his holidays, are not regarded as clinical data. The Investigative site or monitor should be trained to enter the contents of the comments in the appropriate data collection field rather than making marginal notes on the CRF. Sponsors, in the course of determining their approach to managing comments, are encouraged to take into account that there is a higher time/cost consideration associated with unsolicited comments, as they are labor intensive to data-enter, review and act upon Conclusion References to requirements related to submission of the unsolicited comments were not identified in ICH E3 and E6. The recommendation is that only the parameters captured in appropriate CRF data collection fields Page 34

39 are considered clinical study data that is submitted to regulatory parties in datasets; all other comments are considered unsolicited comments. Page 35

40 5.5 Prior and Concomitant Medications CM (Interventions) The same basic data collection variables should be collected for all medications/treatments (Prior, General Concomitant Medications and Medications of Interest). It is assumed that additional fields will be added as applicable for each specific Medication of Interest. The term Prior refers to medications/treatments that were started before study participation since limited information may be available on prior medications taken by a subject; the core requirements were constrained to reflect this limitation. Sponsors should define the appropriate collection period for prior and concomitant medications/treatments in the study protocol General Medications General medications/treatments are defined as any medications/treatments reported by a subject when asked if they have taken any medications in an open-ended way that does not ask about any specific drug. Additional information might be sourced by referring to a subject s medical record Medications of Interest Medications of interest are defined as any medications or classes of drugs specifically mentioned in the protocol, (e.g., excluded medications, drugs requiring a washout period prior to dosing in study, or rescue medications). Medications of interest were not the primary focus for this domain due to the fact that by definition, the collection of data for drugs specifically mentioned in the protocol is likely to change from protocol to protocol and data collection will be at a higher degree of detail and those details can change significantly depending on the exact nature of the medications of interest. Among the many reasons for this are: 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. As with all the data collection variables recommended in the standard, it is assumed that sponsors will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., TA-specific data elements and others as required per protocol, business practice and operating procedures). The CMOCCUR field provides a structure for capturing the occurrence of specific medications of interest Non-Pharmacologic Therapies Both and SDTM include therapies as part of the definition of the treatment, but all examples refer to medications. If sponsors wish to capture non-pharmacological therapies (e.g., aromatherapy, massage, acupuncture), they can use the CM domain if the treatments require equivalent data capture. In this case, the question text, prompt, CRF instructions, etc. may be modified to refer to therapy instead of or in addition to medication. Most coding dictionaries currently do not include non-pharmacological therapies, and appropriate processes should be developed to handle this. Alternatively, sponsors can choose to develop a separate interventions domain to capture this information. Page 36

41 1 Were any medications taken? Any meds? CMYN PerformedObservation Result.value General prompt question to aid in monitoring and data cleaning. {NY} (See Section 2.2.) 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. This field does not map directly to an SDTM variable. O 2 What is the medication /treatment identifier? <line number> or <CM number> CMSPID Implementation specific A sponsor-defined identifier which can be used for pre-printed numbers on the CRF. Example instruction: Record unique identifier for each medication for this subject. Number sequence for all following pages should not duplicate existing numbers for the subject. It can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile concomitant medications and/or medical history records with AEs. O Page 37

42 3 What was the term for the medication/ therapy taken? or What was the term for the medication taken? Medication or Therapy CMTRT Material.name* Verbatim drug name or therapy (include only therapies with data collection characteristics similar medications). Record only one medication per line. Provide the full trade or proprietary name of the drug or therapy; otherwise the generic name may be recorded. In most cases, the verbatim drug names or therapy will be coded to a standard dictionary such as WHO DRUG after the data have been collected on the CRF. For the collection of verbatim drug name or therapy, the recommendation is to ask the sites to provide the full trade or proprietary name since it is more exact than the generic. The full trade name provides the base generic and the appropriate salt for that particular drug. In addition, for coding purposes it helps with ATC selection. HR For example the medication Tylenol with codeine #1 has a different ATC code from Tylenol with codeine #3. *See the model for 4 Did the subject take < specific medication/ treatment >? or Has the subject taken < specific medication/ treatment >? < specific medication/treat ment > CMOCCUR PerformedObservation Result.value* Used when the occurrence of a specific medication or treatment is solicited to indicate whether or not (N/Y) the treatment or medication (CMTRT) was taken or given. This field can be used for either prior or concomitant medication/treatments. Please indicate if < specific medication/treatment > was taken by checking Yes or No. CMOCCUR should only be used for specific medications as defined by the protocol. CMOCCUR should not be used for spontaneously reported concomitant medication/treatments. *See the model for O {NY} (See Section 2.2.) Page 38

43 5 What were the active ingredients? Active Ingredients CMINGRD Product.code* Medication Ingredients. Prior to a subject s clinical visit, remind all subjects to bring all medications bottles, packs etc. they are taking with them to their clinical visit. Record all active ingredient(s) off the medication label and separate each ingredient with a comma for the name of drug medication or therapy taken. For example, the medication Dolmen, if manufactured in Spain, the active ingredients should be collected as noted below: Active Ingredient: Acetylsalicylic Acid, Ascorbic acid, codeine phosphate This may be collected in addition to the Medication/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 medications. 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 This field does not map directly to an SDTM variable. O *See the model for Page 39

44 6 For what indication was the medication/ therapy taken? Indication CMINDC Activity.reasonCode* The reason for administration of a concomitant (non-study) medication. (e.g., Nausea, Hypertension) 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 based on clinical investigator s evaluation. If taken to treat a condition, and a diagnosis was made, the indication should be the diagnosis. If taken to treat a condition, and no diagnosis was made, the indication should be the signs and symptoms. If taken as prophylaxis, report 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 (i.e., in the classification of medications), for reconciling the medications taken by a subject with their provided medical history and/or AEs/SAEs as part of the data clean-up and monitoring process, etc. *See the model for R/C 7 What was the ID for the adverse event(s) for which the medication was taken? AE ID CMAENO PerformedObservation Result.identifier* Identifier for the adverse event that is the indication for this medication. Record the identifier of the Adverse Event for which this medication was taken. Intent is to establish a link between the adverse event and the medication taken for the adverse event. This field does not map directly to an SDTM variable. O CMAENO can be used in RELREC to identify a relationship between records in CM dataset and records in the AE dataset. See section 8.2 in the SDTM IG V3.1.2 for information on RELREC. *See the model for Page 40

45 8 What was the ID of the medical history condition(s) for which the medication was taken? MH ID CMMHNO PerformedMedicalCon ditionresult.identifier Identifier for the medical history condition that is the indication for this medication. Record the identifier of the medical history event for which this medication was taken. Intent is to establish a link between the medical history condition and the medication taken for the medical history condition. This field does not map directly to an SDTM variable. O CMMHNO can be used to identify a relationship between records in the CM dataset and records in the MH dataset. See section 8.2 in the SDTMIG V3.1.2 for information on RELREC. 9 What was the individual dose of the medication/ therapy? Dose CMDSTXT PerformedSubstance Administration.active IngredientDose Description The dose of medication taken per administration. Record the dose of medication taken per administration (e.g., 200). Where this level of dosing information is required by a sponsor, this field may be included. Defining this data collection field as a dose text field allows for flexibility in capturing dose entries as numbers, text or ranges. O This field does not map directly to an SDTM variable. The data collected in this dose text-format field should be separated or mapped to either SDTM IG CMDOSE if numeric or CMDOSTXT if text. Page 41

46 10 What was the total daily dose of the medication/ therapy? Total Daily Dose CMDOSTOT PerformedSubstance Administration.period ActiveIngredientDose Total* Total daily dose taken. Record the total dose of medication taken daily. For use when only total daily dose is collected in the CRF. For general medication, it is not recommended to use Total Daily Dose. Instead, this can be calculated or derived from other fields such as Units, Dose, and Frequency. O *See the model for 11 What was the unit of the medication/ therapy? Dose Unit CMDOSU PerformedSubstance Administration.active IngredientDose The unit associated with the medication taken (e.g., mg in 2mg three times per day ). Record the dose unit of the dose of medication taken (e.g., mg.). When sponsors collect data for amount of dose taken (i.e., Dose, Total Daily Dose), Unit must be collected as well. O {UNIT} (See Section 2.2.) 12 What was the dose form of the medication/ therapy? Dose Form CMDOSFRM Material.formCode* of the pharmaceutical dosage form (e.g., TABLET CAPSULE, SYRUP) of delivery for the drug. {FRM} (See Section 2.2.) Record the pharmaceutical dosage form (e.g., TABLET CAPSULE, SYRUP) of delivery for the medication taken. 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. O *See the model for 13 What was the frequency of the medication /therapy? Frequency CMDOSFRQ PerformedSubstance Administration.dose FrequencyCode* How often the medication was taken (e.g., BID, PRN). {FREQ} (See Section 2.2.) Record how often the medication or therapy was taken. (e.g., BID, PRN). When collected, the recommendation is to collect dosing information in separate fields for specific and consistent data collection and to enable programmatically utilizing these data. See below for the rest of the dosing information components (Dose per Administration, and Unit.) O *See the model for Page 42

47 14 What was the route of administration of the medication /therapy? Route CMROUTE PerformedSubstance Administration.route OfAdministrationCode Identifies the route of administration of the drug. {ROUTE} (See Section 2.2.) Provide the route of administration for the drug. This additional information may be important to collect on the CRF when the sponsor would want to capture a medication s route of administration for purposes such as coding and the medication may have more than one route. Some companies may use route in coding medications to be able to choose a precise preferred name and ATC code. R/C 15 What was the start date of the medication /therapy? Start Date CMSTDAT PerformedActivity. daterange* Date when the medication was first taken. Record the date the medication or therapy was first taken using this format (DD-MON- YYYY). If the subject has been taking the medication for a considerable amount of time prior to the start of the study, it is acceptable to have an incomplete date. Medications taken during the study are expected to have a complete start date. The preferred method is to collect a complete Start Date. Partial dates (e.g., providing year only) for medications started a considerable amount of time prior to the start of study are acceptable. For the SDTM-based dataset, the SDTM IG variable CMSTDTC is derived by concatenating Start Date (CMSTDAT) and Time (CMSTTIM if time is collected) and converting into ISO 8601 format. HR Prior medications that are exclusionary should have both a start and end date For more detail see the Best Practice section. This field does not map directly to an SDTM variable. *See the model for Page 43

48 16 What was the start time of the medication/ therapy? Start Time CMSTTIM PerformedActivity. daterange* Time the medication was started. Record the time (as complete as possible) that the medication or therapy was started. Recommend collecting the time a medication was started when a protocol or data collection scenarios supports it. Typically, a start time is not collected unless the subject is under the direct care of the site at the time a medication or therapy is administered. R/C For the SDTM-based dataset, the SDTM IG variable CMSTDTC is derived by concatenating Start Date (CMSTDAT) and Time (CMSTTM if time is collected) and converting ISO 8601 format. For more detail see the Best Practice section. This field does not map directly to an SDTM variable. *See the model for 17 Was the medication/ therapy taken prior to the study? Taken Prior to Study? CMPRIOR Implementation specific To determine if medications were taken prior to study start. {NY} (See Section 2.2.) Check if the medication or therapy was started before the study. See section Mapping Relative Times from Collection to Submissions and the SDTM IG for more information. This field does not map directly to an SDTM variable. R/C Page 44

49 End Date CMENDAT PerformedActivity. daterange* 18 What was the end date of the medication/ther apy? Date that the subject stopped taking the medication or therapy. Record the date the subject stopped taking the medication or therapy using this format (DD- MON-YYYY). If the subject has not stopped taking the medication leave this field blank. The assumption is that sponsors should either have a complete end date or will indicate that the medication or therapy was ongoing at the time of collection or at the end of the study. However, in cases where the End Date can be determined from dates collected elsewhere in the CRF it is not necessary to include an End Date in the CRF. For example, if all concomitant medications are administered as a single dose, the End Date will be the same as the Start Date. R/C For the SDTM-based dataset, the SDTM IG variable CMENDTC is derived by concatenating End Date (CMENDAT) and Time (CMENTIM if time is collected) and converting to ISO 8601 format. For more detail see the Best Practice section. This field does not map directly to an SDTM variable. *See the model for Page 45

50 19 What was the end time of the medication /therapy? End Time CMENTIM PerformedActivity. daterange* Time when the subject stopped taking the medication or therapy. Record the time (as complete as possible) that the medication or therapy was stopped. Recommend collecting the time a medication or therapy was ended when a protocol or data collection scenarios supports it. R/C Typically, an end time is not collected unless the subject is under the direct care of the site at the time a medication or therapy is stopped. For the SDTM-based dataset, the SDTM IG variable CMENDTC is derived by concatenating End Date (CMENDAT) and Time (CMENTIM if time is collected) and converted to ISO 8601 format. For more detail see the Best Practice section. This field does not map directly to an SDTM variable. *See the model for Page 46

51 20 Is the medication /therapy still ongoing? Ongoing CMONGO Implementation specific Indicates medication or therapy is ongoing when no End Date is provided. {NY} (See Section 2.2) Record the medication or therapy as ongoing if the subject has not stopped taking the medication or therapy at the time of data collection and the end date should be left blank. This box should be checked to indicate that the medication or therapy has not stopped at the time of data collection. It is expected that every recorded medication or therapy should have either an End Date or be checked as Ongoing, but not both. R/C However, in cases where ongoing concomitant medications are not permitted, it may not be necessary to include an Ongoing field in the CRF. Reference section for more information about collecting relative date/time and see section of the SDTM IG V for information about mapping relative times. This field does not map directly to an SDTM variable. Page 47

52 5.6 Demographics DM (Special Purpose) Privacy concerns surrounding the DM & SC data were noted and addressed. Some of the variables collected may map in a many-to-one fashion (i.e., many collected components map to one SDTM IG variable). This approach provides flexibility in categorizing some variables to facilitate compliance with local privacy issues Collection of Age versus Date of Birth It is recognized that sponsors may collect the age or date of birth of the subject, or both. Knowing the age at a given date leaves the sponsor with a window of uncertainty of, at most, 366 days if the age needs to be recalculated for a date which is different than the date the age was collected. Knowing the precise date of birth provides the ability to calculate accurately an age for any date however a precise (and complete) date of birth may be seen as personally identifying information for some privacy oversight boards or governmental regulators. requires the collection of the year,, makes the collection of day and month of birth conditional, and the collection of time of birth optional (such as when needed for infant, neonatal or pediatric studies). This approach collects sufficient data about the date of birth, which would give a window of uncertainty of, at most, 31 days for all age calculations. SDTM allows for the reporting of dates as collected (e.g., year only, year + month, year + month + day, year + month + day + time). By identifying the component parts of a complete SDTM IG variable BRTHDTC (year + month + day +/- time of birth), provides a flexible solution which balances the collection of meaningful analytical data while meeting local regulatory privacy requirements. recommends collecting the date of birth (minimally birth year and birth month) and deriving age, rather than collecting age, even when there are privacy concerns with collecting the complete date of birth. Age is an optional variable. recommends collecting the components of a full date of birth as follows: Day + Month +/- Year +/- Time of birth. The design of the CRF should place the fields to be collected together, but they may be electronically stored together or separately, however the entry and storage is best managed. If entered or stored separately, the date of birth values collected may be concatenated into a reportable date, with possibly a lesser degree of precision than a complete date. The sponsor should be able use the concatenated data for analysis. This imprecision should also obscure the personal information enough to protect the privacy of the trial participant and should satisfy regulatory or privacy boards that oversee the collection of these data. Regardless of the precision of the birth date that is collected, recommends the unambiguous format DD- MON-YYYY where DD is the day as a 2-digit numeric value, MON is the month as a 3- character abbreviation - or an appropriate equivalent in the local language, and YYYY is the year as a 4-digit numeric value. See Section Conversion of Dates for Submission for more information Conversion of Dates of Birth to ISO 8601 for SDTM It is expected that what is collected for BRTHDAT will be submitted in SDTM BRTHDTC in the ISO 8601 format. If data are collected in a manner resulting in one of the reduced precision levels noted above, then the submitted AGE (SDTM required variable), if not collected on the CRF, should be derived using a documented algorithm that describes how the age was derived and/or imputed for those birth dates collected with reduced precision. When the birth year and birth month components are collected but the birth day is not collected, the sponsor may report the date in SDTM compliant ISO 8601 structure and the BRTHDTC variable would be created by populating the year and month components of ISO 8601 and omitting the day. The birth date can be thought to be composed of one or more of the elements of year, month, day and time. These components can be stored in one variable (BRTHDAT) or as a separate variable for each of the components (BRTHDY, BRTHMO, BRTHYR). Page 48

53 See Section Conversion of Dates for Submission for more information Collection of Sex The collection of some demographics data is useful to perform simple analyses based upon population stratification. These analyses are based on phenotypic traits of the subjects. The first, and most obvious of these data, is the sex of the subject, as reported by subject or caretaker. This is the self-reported sex of the individual and/or is the clinician s assignment based on a physical examination. This is not to be confused with a genotypic determination of a subjects' chromosomally determined gender, but a less scientifically controlled method of visual determination that HL7 has defined as administrative sex Collection of Ethnicity and Race A secondary analysis is often made using the phenotypic race of the subject. The racial determination, as defined by the U.S. Center for Disease Control as an arbitrary classification based on physical characteristics;..., has historically been seen as a grouping of people based on physical traits such as skin color, cranial or facial features, hair texture, etc. and that these traits were attributed to...a group of persons related by common descent or heredity (the second part of the CDC definition). Today most scientists study human genotypic and phenotypic variation using concepts such as population and clinal gradation". Many contend that while racial categorizations may be marked by phenotypic or genotypic traits, the idea of race itself as well as actual divisions of persons into races, are social constructs. While genotyping would provide a more scientific approach to categorizing population groups for clinical analysis (safety or efficacy), the demographics domain does not contain these genotyping data, but instead provide a self-reported approach that aligns more closely to the phenotype of the subjects. The category of ethnicity is similar to race but, as defined by the CDC, is an arbitrary classification based on cultural, religious, or linguistic traditions; ethnic traits, background, allegiance, or association. In a fairly heterogeneous country, such as in the U.S., ethnicity data might be useful only to confirm that ethnic groups are not being discriminated against by being unfairly excluded from clinical research. In other more homogenous countries, such as Japan, the ethnicity of subjects might be collected to assure regulators that the results in this ethnic group should be the same as in the rest of the population of the country (or so that data of subjects who were outside of Japan could be used in the same manner as for subjects who are within Japan). 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 MHLW reporting to Japan). These may be collected as an extension to the suggested NCI-CDISC code list. Race Other has been included in Version 1.1 as a free-text field to capture responses. The use of this variable is optional and should be used with caution because, when submitting data to the FDA, the FDA requires that all races be mapped to the 5 standard races recognized by the FDA, and providing an Other, Specify field might lead to mapping errors or difficulties. Countries other than the US do not require the capture of Race, which is why it is R/C (only required if data is going to be submitted to the FDA). Page 49