Page Comparison

Current Status:

• Updated CVARS version with E2E implementation and shinylive deployment.

• Final manuscript for CVARS E2E implementation.

Development of an open-source tool and package to enable generation of identified interactive plots for clinical review and direct inclusion in submissions to regulatory agencies. The initial scope is to develop a package to generate interactive forest and volcano plots for adverse events and FDA Medical Queries (FMQs) analysis outputs for inclusion in submissions to the FDA. This work is a collaboration among the American Statistical Association (ASA), PHUSE and the FDA.

Communication of Version Metadata for Open-Source Languages – Started Q

Project Scope:

This project aims to develop a new template or enhance an existing one such as the Study Data Standardisation Plan (SDSP) or Analysis Data Reviewer’s Guide (ADRG), to ensure that metadata pertaining to the versions of statistical packages and procedures is consistently documented in alignment with health authority expectations. This standardised template will streamline the submission of clinical study metadata to health authorities as part of the regulatory review process.

Current Status:

• Continue FDA Engagement

• Finalise Metadata Approach

• Onboard New Team Members

• Develop Project Plan

Regular Project Meeting Day/Time:

• Bi-weekly: Wednesdays 7-8pm GMT

Key Skills:

• Experience in statistical programming language

• Experience in processing metadata

Comparing Analysis Method Implementations in Software (CAMIS) – Started Q

Project Scope:

Comparing Analysis Method Implementations in Software (CAMIS) has evolved from the Clinical Statistical Reporting in a Multilingual World project.

Several discrepancies have been discovered in statistical analysis results between different programming languages, even in fully qualified statistical computing environments. Subtle differences exist between the fundamental approaches implemented by each language, yielding differences in results which are each correct in their own right. The fact that these differences exist causes unease on the behalf of sponsor companies when submitting to a regulatory agency, as it is uncertain if the agency will view these differences as problematic. Understanding the agency’s expectations will contribute significantly to enabling the broader adoption of multiple programming languages in the production of data submission packages for regulatory review

The CAMIS project seeks to clearly define this problem and provide a framework for assessing the fundamental differences for a particular statistical analysis across languages. In this context, the risk of interpreting numerical differences in analysis results due solely to differences in programming language can be mitigated, instilling confidence in both the sponsor company and the agency during the review period. This will be accomplished by:

1. Identifying common statistical analyses performed during submissions to narrow the scope of where discrepancies must be identified (e.g., continuous summaries, frequency counts, hazard models, bioequivalence testing, steady-state assessments, bioavailability testing, ANOVA)

2. Providing necessary documentation to produce equivalence in results between separate statistical analysis software packages/languages (where possible)

3. Evaluating and documenting differences in results between popular statistical analysis implementations as use cases

4. Provision of sample code for use cases through a publicly accessible code repository for both review and consumption

5. Promoting the notion that the ‘right’ implementation of a particular statistical analysis should be based sound statistical reasoning and not limited by the capabilities of a specific programming language or statistical analysis software package, nor its default settings

The CAMIS repository to document known differences is now live and open for community contributions. 

Current Status:

Current Status:

Research: Conduct a detailed analysis of the current teal framework and identify areas where flexibility can be introduced. A Proof-of-Concept will be provided after research.

Development: Create new functionalities that allow for the re-formatting, post-processing, and decoration of outputs generated by existing teal modules.

Testing: Develop test cases to ensure the new functionalities are compatible with existing modules and meet the customisation needs of different companies.

Documentation: Update the framework's documentation to include instructions on how to use the new features.

Training & Support: Provide training and ongoing support to users within the pharma industry to facilitate the adoption of the enhanced teal framework.