An Approach-Creating Trial Design Models Jan 2015 Peter Mesenbrink Sangeeta Bhattacharya Welcome to the Overview of the Trial Design Model e-Learning lesson. This web-based training will provide you with an overview of the Trial Design Model. We will review the template used to define the trial design model and, provide details on what is included in each of the data domains that comprise the model.

Why is the Trial Design Model Important? SDTM Trial Design Model is a required part of all CDISC SDTM electronic data submissions to the FDA The metadata defined for Trial Elements (TE), Trial Arms (TA), Trial Visits (TV), Trial Summary (TS) and Trial Inclusion/Exclusion (TI) is converted into SAS data sets and included as part of the Case Report Tabulations that are part of the eCTD submitted to the FDA It is used the derivation of other SDTM and ADaM data sets Subject Elements (SE) – Planned and unplanned subject-level trial elements Subject Visits (SV) – Planned and unplanned subject-level trial visits Planned and actual treatment groups in ADSL Why is the TDM important? SDTM Trial Design Model is a required part of all CDISC SDTM electronic data submissions to the FDA. The metadata defined for Trial Elements (TE), Trial Arms (TA), Trial Visits (TV), Trial Summary (TS) , and, Trial Inclusion/Exclusion (TI) is converted into SAS data sets and included as part of the Case Report Tabulations that are part of the eCTD submitted to the FDA. | Overview of Trial Design Model | Business Use Only

Overview of TDM Trial Design Model - Purpose Define the study-level visit structure Define a subject’s planned path through the study so that study treatment can be packaged and the groups of subjects to be compared can be defined Provide summary information that is useful in understanding key features of the trial design. This is important in setting up the statistical analysis plan and comparing studies with similar endpoints within a specific disease area. What is the purpose of the trial design model? First, it allows us to define the study-level visit structure. In conjunction with the protocol, this information provides a clear basis for the planned visits of the trial. Second, it defines a subject’s planned path through the study so that study treatment can be packaged and the groups of subjects to be compared can be defined. This is where we define the trial arms. Trial arms indicate where the subject starts, where the subject ends, and, what are the options / paths a subject can take based upon the decision rules that exist during the course of a trial design. Lastly, it provides summary information which is useful in understanding key features of the trial design. This is important in setting up the statistical analysis plan, and, comparing studies with similar endpoints within a specific disease area when planning analyses for integrated summaries or meta analyses. | Overview of Trial Design Model | Business Use Only 3 3

Trial Design Domain Overview What “is planned” includes Trial Design domains: 5 CDISC domains What “actually happened” includes 2 Special Purpose domains: 2 CDISC subject-level data domains Special Purpose Subject Elements Subject Visits The trial design model details what is planned vs. the subject level data which detail what actually happened. In the current model, there are five trial design domains which detail what is planned. The CDISC defined data domains are Trial Elements, Trial Arms, Trial Visits, Trial inclusion/exclusion and Trial Summary. These are the five tabs that exist within the trial design model template. It is the responsibility of the Trial Statistician and Trial Programmer to ensure the timely completion of this template in conjunction with protocol finalization, and, the statistical analysis plan, (RAP Module 3), to ensure the proper set up of the clinical trial database, and, data transfer specifications. This will ensure that there is a clear plan for defining the treatment groups to be used in all statistical analyses. There are also two Special Purpose data domains which provide information at the subject level with respect to what actually happened. These are titled Subject Elements and Subject Visits. | Overview of Trial Design Model | Business Use Only 4

Trial Design Domains – What Is Planned Order of completion CDISC Domains Description 1 Trial Elements (TE) Basic building blocks for time within the trial. What happens to a subject in each arm (i.e. what series of treatment and non-treatment time periods {trial elements} are planned for a subject assigned to that arm) 2 Trial Arms (TA) Planned sequence of elements, often equivalent to a treatment group. 3 Trial Visits (TV) Planned visits according to the protocol with start and end rules (One record per visit per Arm) 4 Trial Inclusion / Exclusion (TI) The inclusion/exclusion criteria used to evaluate subjects eligibility for study entry. 5 Trial Summary (TS) Key features of the trial design being implemented / basic sense of what the trial is about. Basic information about the trial such as phase, protocol title, trial objectives, planned and actual # of subjects. Let’s begin by looking at the five trial design domains which detail what is planned: Trial Elements are known as the basic building blocks for time within the clinical trial. It indicates what series of treatment and non-treatment time periods, (such as screening, rest, and washout) are planned for a subject assigned to that arm. Trial Arms indicates the subject‘s flow in a study and provides a basis for defining treatment groups. It provides the sequence of the elements in the order that they occur. The information in this domain will often be equivalent to treatment groups and will be used to derive the actual planned treatments. Trial Visits provide the planned visits according to the protocol with corresponding start and end rules. It includes one record per visit, per arm. Trial Inclusion/Exclusion includes the criteria used to evaluate a subject’s eligibility for study entry. Since the Inclusion/Exclusion data captured at the subject level only includes exceptions , (and only for those subjects who signed the informed consent), this domain is the only place that provides a way to review the criteria in each trial; thereby allowing us to see if the criteria was consistent across trials. Since it has versioning, it also allows you to see if the criteria have been modified during the course of the trial. Trial Summary provides a synopsis of the protocol, detailing key features of the trial design being implemented and providing a basic sense of what the trial is about. It includes basic information such as phase, protocol title, trial objectives, planned number of subjects, efficacy endpoints, primary analysis for those endpoints, sub-study information, etc. There are over thirty features that help to characterize the study. | Overview of Trial Design Model | Business Use Only 5 5

Special Purpose Domains – What Actually Happened Description Subject Elements (SE) What actually happened to a subject during the study - both what was planned and what was unplanned Subject Visits (SV) Actual visits - both those that were planned and those that were unplanned/unscheduled There are two Special Purpose domains that detail what actually happened to each subject: Where Trial Elements provides all of the planned elements within the study, Subject Elements details what actually happened to each subject during the study, including both what was planned and what was unplanned. For example, if a subject did not return for treatment when scheduled, the treatment could be included as part of the unplanned description of what happened, detailing why they did not receive treatment at the original time. Similarly, while Trial Visits provides the planned visits within the study, Subject Visits detail all actual visits including those which were planned and those which were unplanned, or unscheduled during the course of the trial. When created, the subject visit dataset contains lnformation from both the trial visits and subject visits, creating a complete set of visits that exist for a particular subject. When developing a clinical trial database, it is important that the trial statistician, trial statistical programmer, trial data manager, and database programmer are aligned and that the information which describes the trial design matches the information in the Study Setup Document ,(SSD), which defines what is included in each CRF screen in Oracle Clinical. When the data from the trial design model is merged with the data that is extracted from Oracle Clinical, if it does not match, the subject-level visit numbering data will not be processed in LSH. Please note that there will be changes to these domains when visit numbering is moved to GPS. | Overview of Trial Design Model | Business Use Only 6 6

Data Flow in Novartis Much is changing because of CDISC and Novartis Clinical Data Standards (NCDS) – new systems and applications, new / revised processes and roles, etc. Study Area = SDTM+ This diagram represents an overview of the current data flow at Novartis from collection to analysis and reporting. | Overview of Trial Design Model | Business Use Only

Challenges with Implementing Trial Design Every person could have a different interpretation of how to define trial design metadata. Thus as part of project-level planning, teams need to define conventions to be applied across all studies. Until a fully automated tool is developed there will be some work involved particularly for information that require extraction of text from the protocol and/or is not managed by controlled terminology. Model will continue to evolve over time as other knowledge is built-up on the availability of searchable metadata within and across clinical trials. Let’s review some of the challenges that have been encountered in trying to implement TDM within Novartis. Every person could have a different interpretation of how to define trial design metadata. Thus as part of project-level planning, teams need to define conventions to be applied across all studies. The level of automation available for the creation of the trial design metadata continues to increase and has improved greatly with the current template versus some of the initial versions, and, further full automation solutions continue to be explored. Lastly, the model will continue to evolve over time as other knowledge is built-up on the availability of searchable metadata within and across clinical trials. | Overview of Trial Design Model | Business Use Only

Areas of focus for TDM consistency across studies (1/2) Trial design model metadata should be a key source in determining the similarity of clinical studies for data pooling Trial Elements (TE) ELEMENT and ETCD used in definition of treatment group descriptions in drug packaging and analysis, inconsistency will necessitate mapping for pooled analyses Start and End rules (TESTRL, TEENRL) – Should be written for easy translation into programmable rules at the subject level in SE. When subjects receive more than one treatment, consistent definitions will simplify how AEs are counted across treatment groups. Also need to ensure that there is no gaps in time when one element ends and the next element starts Trial Arms (TA) EPOCH appears in every SDTM data set There are certain epoch names that are used in Oracle Clinical (OC) that should never appear in the TDM (UNPLANNED and SUMMARY) ARMCD can be simplified if is difficult to include all treatment elements in 20 characters or less 9 9

Areas of focus for TDM consistency across studies (2/2) Trial Visits (TV) Planned visit names (VISIT) should be identical between protocol, TDM, and clinical trial database to ensure that all planned and unplanned visits can be merged at the subject level and for easy translation into analysis visits in ADaM Start rules (TVSTRL, TVENRL) – Need to make clear when assessments taken count towards the planned visit so that unplanned visits can be kept to a minimum Trial Inclusion/Exclusion (TI) Does not need to match identically with what is in the protocol (e.g. can remove parenthetical text as needed to get criterion down to 200 characters) The number of the criterion in the protocol should match the number of the criterion in the TDM (e.g. Inclusion criterion #5 in the protocol, should have IETESTCD = INCL05 in the TDM) Trial Summary (TS) Will be updated several times during the course of the study If TSVAL is not known for a particular TSPARM leave blank and populate TSVALNF accordingly 10 10

Timing of Creation Pre Data Build Post Data Build Pros Visit structure matches study build Early attention provided by Study team Open CDISC run early eliminating late changes to SDTM/ADAM No impact on DB build/lock Timelines Cons Manage expectations on cross functional Collaboration Database build timelines impacted May Result in Lack of Consistency OpenCDISC run late may force unlocking of the clinical trial database or revisiting programmed SDTM/ADAM datasets What is the purpose of the trial design model? First, it allows us to define the study-level visit structure. In conjunction with the protocol, this information provides a clear basis for the planned visits of the trial. Second, it defines a subject’s planned path through the study so that study treatment can be packaged and the groups of subjects to be compared can be defined. This is where we define the trial arms. Trial arms indicate where the subject starts, where the subject ends, and, what are the options / paths a subject can take based upon the decision rules that exist during the course of a trial design. Lastly, it provides summary information which is useful in understanding key features of the trial design. This is important in setting up the statistical analysis plan, and, comparing studies with similar endpoints within a specific disease area when planning analyses for integrated summaries or meta analyses. | Overview of Trial Design Model | Business Use Only 11 11

What have we taken into Account? Learnings from recent BLAs/NDAs on the content of the SDTM trial design model data sets Supplemental qualifiers not allowed for SDTM trial design model data sets (i.e. the data elements are fixed and cannot be added to) Changes and improved understanding of the end-to-end data flow and how the metadata supports it. To maximize the amount of information in the TDM that can be populated through standard macros and drop down codelists and minimize the amount of manual entry and subsequent re-work Separate TDM requirements from PK merge requirements 12

How Have we defined a Process Defined a template (excel spreadsheet with visual basic macros) To be Completed by Statisticians and Programmers Easy export of different domains to create the necessary SAS data sets Template Stored in GPS(Unix-Our Statistical Programming Environment) Simplified versioning and approval process PDF rendition signed by lead statistician and lead statistical programmer Trial visits to be brought back into Oracle Life Science Hub (LSH) for visit numbering/re-numbering as .csv file with special delimiters 13

What have we defined in terms of Roles & Responsibilities Shared responsibility of TDM development between trial statistician and trial programmer Primary accountability is as follows: Trial Visits – Trial programmer in collaboration with Lead Data Manager (LDM) and Trial Statistician Trial Elements, Trial Arms, Trial Inclusion/Exclusion, Trial Summary – Trial Statistician (Collaboration with LDM on Trial Inclusion/Exclusion) Easier export of different domains to create the necessary SAS data sets by Study Programmer Simplified versioning and approval process Working copy versioned in GPS II /util directory for the clinical study by Study Statistician PDF rendition signed by lead statistician and lead statistical programmer Trial visits to be brought back into LSH for visit numbering/re-numbering as .csv file by Lead Data Manager 14

Other ways that TDM process will hopefully be improved in the near future Information to be added in disease level/study level analysis plans to define naming conventions for text that is not automated or managed by codelists/controlled terminology Standardization of start and end rules for trial elements and trial visits (e.g. will the randomization visit be called “RANDOMIZATION” or “BASELINE”, will treatment trial elements always start with the first dose of study treatment?) Naming conventions for visit names and treatment elements 15

Explanation of the Process 16

Instructions for completing the template (1/2) This is what you will see when you open the trial design model template until it can be permanently store in GPS in /util directory this will be found in the NCDS Knowledgebase 17

Instructions for completing the template (2/2) 18

Macros tab drives generation of TA and TV (1/2) This is the tab where the trial design model automation is built. To complete the in the NCDS Knowledgebase 19

Macros tab drives generation of TA and TV (2/2) This is the tab where the trial design model automation is built. To complete the in the NCDS Knowledgebase 20

Defining Trial Elements first in TE 21

Instructions for completing the template (1/2) This is what you will see when you open the trial design model template until it can be permanently store in GPS in /util directory this will be found in the NCDS Knowledgebase 22

Instructions for completing the template (2/2) 23

Macros tab drives generation of TA and TV (1/2) This is the tab where the trial design model automation is built. To complete the in the NCDS Knowledgebase 24

Macros tab drives generation of TA and TV (2/2) This is the tab where the trial design model automation is built. To complete the in the NCDS Knowledgebase 25

Trial Elements Only the ETCD and ELEMENT columns are needed to create the Trial Arms on the Macro tab 26

Defining Trial Arms and Epochs 27

TA after providing macro information 28

Defining Trial Visits 29

TV after providing macro information Need to still define start rules for trial visits and enter the Visit Day associated with a particular visit number 30

TS and using the controlled terminology All TSVAL values where controlled terminology exist one needs to select from the drop down menu the appropriate choice. If an appropriate choice is not available a request needs to be made Data Standards Governance to propose an addition to the controlled terminology 31

The SAS format row tells you the format and length of the value If you try to enter more than the maximum allowed length described by the SAS format, an error message will display on the screen indicating that the value you entered exceeds the maximum allowed length for the data element 32

Trial Inclusion/Exclusion simplified TI needs to be manual entered currently. If the criterion can not be entered into the five 200 character blocks provided. Sensible shortening is permitted. 33

TI after extracting information from the protocol 34

Export TDM Export TDM worksheet | Presentation Title | Presenter Name | Date | Subject | Business Use Only

What does the future hold? Further automated solutions continue to be developed either stand alone or integrated within eProtocol solutions Challenges remain in having a solution that works in all situations particularly in event-driven and adaptive trial designs but will improve in the future with: Disease-level structured protocols Therapeutic area standards which will increase the consistency and allow for the development of disease-level trial design model shells | Presentation Title | Presenter Name | Date | Subject | Business Use Only