Tobacco products can lead to chronic health effects that can take decades to manifest (e.g., lung cancer can take 20+ years), which would require long-term studies to assess. Population models and simulations provide a desirable alternative for making estimates and predictions of likely impact on morbidity/mortality at the population level in the absence of empirical data. Mathematical, computational, and simulation models can also help guide regulatory activities such as new product authorizations and policy development. Such models take into consideration both users and nonusers of tobacco products and include cohort models, agent-based models, deterministic and stochastic systemic dynamic models, and static and dynamic social network models.
The objective of population modeling is to study the impact of tobacco products on the population as whole. Input parameters include demographic information, tobacco use transition probability and mortality and/or morbidity. The input parameters are typically derived from population-level sources (e.g., census data or other population-level surveys). However, depending on the objective, other sources of data may be used. When using these other sources, steps should be taken to ensure they are representative of the population.
Outputs of the model may include projections on morbidity/mortality and prevalence of use resulting from the impact of the desired objective of the model (such as new product authorizations or regulatory policy development).
In this section, these models are discussed with regard to inputs to, and outputs from the models, and how these models contribute to studies of tobacco products, and how they are represented in CDISC standards for submission to a regulatory authority.
Unknown User (a.paredes) will work on additional language to introduce the concept of "parameters" in the context of population modeling.
Scope clarified to baseline input parameters used to support downstream modeling only
To be included in a subsequent subsection:
- Sponsors need to submit software code/programs (applicant can choose whatever software they want; so we need to provide some guidance). Unknown User (a.paredes) to work internally to see if they can come up with some ideas.
- Procedural codes (raw code); matlab, sas, etc - FDA can't specify. FDA asks for an XML diagram to show logic of how sponsors build the code
- Sometimes sponsors develop GUI for reviewers rather than submitting code. FDA still needs both front end and back end access
- ADRG, define can be used to provide some information and links to programs
- ADRG template has a place to document programs
- ARM (analysis results metadata) allow for program references and links to programs
- We would need input on what the specific requirements should be. TCG has some language regarding programs
Overview
Content Tools