Download Acquire Pooled Data for Summaries of Clinical Safety

1. Acquire Pooled Data for Summaries of Clinical Safety/Efficacy
Ref #
Use Case Name
Description and Type(s) of
Reporting Activities
A-001
Acquire Pooled Data for Clinical Summary of Safety/Efficacy
Acquire data from multiple studies that have been identified as
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 proofof-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
Benefits
Low to Medium
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
(primary and secondary users)
(optional) Standard Roles / Definitions?
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
(Preconditions)
1. Appropriate work areas exist (e.g., folder structure, 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
# of people performing in a
month/ year* (per group/ per
division/ per Sponsor)
Consolidate clinical database, ready for planned analysis
*specify
# of times done in a month/
year* (per group/ per division/
per Sponsor)
*specify
Related Use Cases