1. Acquire Pooled Data for Summaries of Clinical Safety/Efficacy

1. Acquire Pooled Data for Summaries of Clinical Safety/Efficacy Ref # A-001 Use Case Name Acquire Pooled Data for Clinical Summary of Safety/Efficacy Description and Type(s) of Acquire data from multiple studies that have been identified as Reporting Activities relevant to a Summary analysis of clinical safety or efficacy. Typically the analysis owner will specify precise time points or reporting events for each study, such as final CSR. Based on database specifications, assemble the data as needed to support summary analyses.

Related Use Cases:  Acquire and assemble data from multiple studies to complete a post-marketing commitment to health authorities  Update an ongoing integrated safety or efficacy database for a molecule or indication with databases from recently completed studies  Acquire and assemble data from multiple studies to address particular health authority questions  Pharmacovigilance analyses such as RMP  Periodic updates such as DSUR, PSUR  Data aggregation to support modelling and simulation for proof-of-concepts, dose finding, etc.

While the urgency / business benefits will differ between these related use cases, the steps to acquire and assemble data may not.

Urgency factor / Business Low to Medium Benefits Normally there is sufficient time to plan and coordinate database aggregation. A pivotal database lock & study report, or unplanned health authority queries can trigger compressed timelines to complete data aggregation for summary analysis.

Roles of users (optional) Standard Roles / Definitions? (primary and secondary users) Development Program Owner – identify databases in scope for aggregate analysis Analysis Owner – finalize analysis plan, including list of studies and precise copies of database Data Provider/Modeler – access specified databases and transform as needed for analyses

Stakeholders Assumptions and Requirements 1. Appropriate work areas exist (e.g., folder structure, (Preconditions) database location, etc.) 2. Team members have appropriate access to work areas 3. Specific reference copies (versions) of source data are available 4. Audit trail required for databases & results previously reported

Input / Trigger 1. Summary analysis plan stable or near final 2. List of studies and database copies available 3. Database specifications for individual studies available

Process / Steps followed 1. Review specifications of individual studies (protocols, CRFs, analysis plans, database specifications) 2. Review analysis plans for clinical summary 3. Review database quality reports for individual studies 4. Assess study differences or constraints that could impact summary analyses, such as: a. Different target pops, inclusion/exclusion criteria, etc. b. Differences in collection elements, such as age groups, geographical regions, etc. c. Omitted domains or data elements, d. Variability of missing data 5. Assess consistency of coding conventions and impact on planned analyses, such as a. Standard for of Drug Name terminology b. Standard for Adverse Event terminology (e.g., MedDRA version) c. Standard for event categorization (e.g., CTCAE version) --- for summary of efficacy --- 6. Assess differences in derivations, and whether to aggregate source or analysis databases --- 7. Develop programs to aggregate individual databases 8. Agree on quality assurance (QA) workflow for aggregated database 9. Execute agreed QA workflow a. (option) best-practice discussion around QA workflow 10. Publish aggregated database and inform stakeholders

Output Consolidate clinical database, ready for planned analysis # of people performing in a month/ year* (per group/ per division/ per Sponsor) *specify # of times done in a month/ year* (per group/ per division/ per Sponsor) *specify Related Use Cases