diff --git a/_quarto.yml b/_quarto.yml index 5c2b353..598eda0 100644 --- a/_quarto.yml +++ b/_quarto.yml @@ -68,6 +68,7 @@ website: collapse-level: 2 contents: - documentation/index.qmd + - auto: documentation/*.qmd - section: Version 7.1 contents: - section: User Guides diff --git a/docs/concepts/facts/LinearRegressionLMPriors.html b/docs/concepts/facts/LinearRegressionLMPriors.html index 44fed66..41ed7ef 100644 --- a/docs/concepts/facts/LinearRegressionLMPriors.html +++ b/docs/concepts/facts/LinearRegressionLMPriors.html @@ -394,7 +394,7 @@

Interpretatio The standard deviation around the expectation of the final visit response. This dictates how close the imputed final endpoint responses are to the mean response for a subject given \(\alpha\) and \(\beta\). Lower \(\lambda_t\) implies higher correlation between the early visit response and final visit response. -

```tpptxlgagaafd #| standalone: true #| viewerHeight: 1000

+

```ddqkfmcfhjlyc #| standalone: true #| viewerHeight: 1000

library(shiny) library(DT) library(ggplot2) library(htmltools)

alignCenter <- function(el) { htmltools::tagAppendAttributes(el, style=“margin-left:auto;margin-right:auto;” ) }

sketch = htmltools::withTags(table( class = ‘display’, thead( tr( th(rowspan = 2, ’‘), th(rowspan = 2, style = “border-right: solid 1px;”,’Observed Visit Data’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘B1 priors’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘B2 priors’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘BB priors’) ), tr( th(“mean”), th(style = “border-right: solid 1px;”, “SD”), th(“mean”), th(style = “border-right: solid 1px;”, “SD”), th(“center”), th(style = “border-right: solid 1px;”, “weight”), ) ) ))

diff --git a/docs/documentation/glossary.html b/docs/documentation/glossary.html new file mode 100644 index 0000000..c1230fd --- /dev/null +++ b/docs/documentation/glossary.html @@ -0,0 +1,848 @@ + + + + + + + + + +Glossary + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + +
+ +
+ + +
+ + + +
+ +
+
+

Glossary

+
+ + + +
+ + + + +
+ + + +
+ + +
+

Abbreviations

+

Table 1 gives an overview of the acronyms and abbreviations used in the documentation.

+
+
+
+Table 1: List of terms used in the user guides +
+
+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDefinition
CapA limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap.
ControlIs the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.
CoreFACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.
CRMContinual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).
DEDose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.
EDEnrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications.
FACTSFixed and Adaptive Clinical Trial Simulator.
Final EndpointThe final value, or state, of a subject’s endpoint.
GUIGraphical User Interface, the part of the FACTS application that the user interacts with.
MethodIn the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.
ModelIn the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.
MTDThe dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD).
MTD+The dose most likely to be the MTD+ – the dose with the highest Pr(MTD+).
Pr(MTD)A dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses.
Pr(MTD+)A dose’s probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range.
ProfileA profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.
ResponseThe change in a subject’s endpoint compared to their baseline state.
ScenarioA scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include:
-) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups
-) the properties of subjects’ early responses and the correlation with their final outcome
-) the rate at which subjects are recruited into the trial
-) the rate at which subjects drop out of the trial.
SPECThe Design Engine Specification, describes the system algorithms, and meaning of parameters.
ResponseThe change in a subject’s endpoint compared to their baseline state.
SubjectSomeone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.
Treatment ArmSubjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.
UGThe User Guide; describes how to use the system.
+
+
+
+ + +
+ +
+ + + +
+ + + + + \ No newline at end of file diff --git a/docs/documentation/index.html b/docs/documentation/index.html index 547f5a3..e5ef6dc 100644 --- a/docs/documentation/index.html +++ b/docs/documentation/index.html @@ -152,6 +152,12 @@ Documentation + +
  • +
    + + Glossary +
  • @@ -255,21 +261,28 @@
    - +
    • +
  • +
    + + Glossary +
  • diff --git a/docs/documentation/v71/examples/CRM/example2.html b/docs/documentation/v71/examples/CRM/example2.html index b3fdcba..d39742a 100644 --- a/docs/documentation/v71/examples/CRM/example2.html +++ b/docs/documentation/v71/examples/CRM/example2.html @@ -152,6 +152,12 @@ Documentation
    +
    • +
  • +
    + + Glossary +
  • diff --git a/docs/documentation/v71/examples/Staged/example1.html b/docs/documentation/v71/examples/Staged/example1.html index b2aee16..ca16250 100644 --- a/docs/documentation/v71/examples/Staged/example1.html +++ b/docs/documentation/v71/examples/Staged/example1.html @@ -152,6 +152,12 @@ Documentation
    +
    • +
  • +
    + + Glossary +
  • diff --git a/docs/documentation/v71/examples/Staged/example2.html b/docs/documentation/v71/examples/Staged/example2.html index 4abf8b7..9aa1bf3 100644 --- a/docs/documentation/v71/examples/Staged/example2.html +++ b/docs/documentation/v71/examples/Staged/example2.html @@ -152,6 +152,12 @@ Documentation
    +
    • +
  • +
    + + Glossary +
  • diff --git a/docs/documentation/v71/userguides/core.html b/docs/documentation/v71/userguides/core.html index 6c0e895..f4b886c 100644 --- a/docs/documentation/v71/userguides/core.html +++ b/docs/documentation/v71/userguides/core.html @@ -181,6 +181,12 @@ Documentation
    +
    • +
  • +
    + + Glossary +
  • diff --git a/docs/documentation/v71/userguides/crm.html b/docs/documentation/v71/userguides/crm.html index 04e732b..6855030 100644 --- a/docs/documentation/v71/userguides/crm.html +++ b/docs/documentation/v71/userguides/crm.html @@ -235,6 +235,12 @@ Documentation
    +
    • +
  • +
    + + Glossary +
  • diff --git a/docs/documentation/v71/userguides/installation.html b/docs/documentation/v71/userguides/installation.html index 49d147b..cc022c3 100644 --- a/docs/documentation/v71/userguides/installation.html +++ b/docs/documentation/v71/userguides/installation.html @@ -152,6 +152,12 @@ Documentation
    +
    • +
  • +
    + + Glossary +
  • diff --git a/docs/search.json b/docs/search.json index 2c1934f..8995268 100644 --- a/docs/search.json +++ b/docs/search.json @@ -171,6 +171,26 @@ "Concepts" ] }, + { + "objectID": "concepts/index.html#what-youll-find-here", + "href": "concepts/index.html#what-youll-find-here", + "title": "Concepts", + "section": "What You’ll Find Here", + "text": "What You’ll Find Here\n\nBasics of Clinical Trials: Learn the essentials, terminology, and best practices that define the clinical trial landscape. From study design and data collection to regulatory considerations, we’ll walk you through the elements that matter most.\nStatistical & Mathematical Fundamentals: Uncover the foundational concepts in statistics and mathematics that empower you to make data-driven decisions. Understand key analyses, Bayesian approaches, and appreciate why certain metrics and models are essential to reliable results.\nTips & Tricks for Using FACTS: Gain insider know-how that helps you work smarter and faster.", + "crumbs": [ + "Concepts" + ] + }, + { + "objectID": "concepts/index.html#how-to-make-the-most-of-this-section", + "href": "concepts/index.html#how-to-make-the-most-of-this-section", + "title": "Concepts", + "section": "How to Make the Most of This Section", + "text": "How to Make the Most of This Section\nUse the Concepts section as a springboard to build your expertise, whether you’re new to clinical trials or looking to refine your analytical skills. By solidifying your grasp of fundamentals and strengthening your analytical toolkit, you’ll be better equipped to understand results and ask the right questions. Check back often as we continue expanding these resources to support your growth.", + "crumbs": [ + "Concepts" + ] + }, { "objectID": "concepts/bayes/bayes1.html", "href": "concepts/bayes/bayes1.html", @@ -254,624 +274,641 @@ "text": "We pride ourselves in delivering fast support and will go above and beyond for you.\n\n\nGeneral Inquiries and Help using FACTS\nPlease contact us directly via e-mail at facts@berryconsultants.com.\n\n\nGet FACTS\nTo directly apply for a free 3-months FACTS Evaluation license, please use the following online form.\nTo directly enquire about a free demo or a regular license, please use the following online form.\nIf you are unsure, feel free to contact us directly via email at facts@berryconsultants.com.\n\n\nGeneral Inquiries about Berry Consultants\nPlease use the following online form." }, { - "objectID": "documentation/v71/examples/Staged/example1.html", - "href": "documentation/v71/examples/Staged/example1.html", - "title": "Example 1", + "objectID": "documentation/index.html", + "href": "documentation/index.html", + "title": "Documentation", "section": "", - "text": "First example", + "text": "Welcome to the Documentation section — your go-to repository of in-depth user guides and practical examples that illuminate every aspect of FACTS. Whether you’re just getting started or delving into advanced functionalities, these resources are designed to help you navigate our software with confidence and ease.", + "crumbs": [ + "Documentation" + ] + }, + { + "objectID": "documentation/index.html#what-youll-find-here", + "href": "documentation/index.html#what-youll-find-here", + "title": "Documentation", + "section": "What You’ll Find Here", + "text": "What You’ll Find Here\n\nUser Guides: Access detailed manuals covering the full range of our engines. From foundations to advanced features, learn how to set up your desired trial design, learn about best practices and obtain focused understanding of the subject matter, and troubleshoot common issues.\nInstallation Instructions: Get up and running quickly with clear guidance. Our installation resources walk you through every phase—downloading the software, deploying it in various environments, and start FACTSing!\nExamples: Explore a range of constructed and real-world studies that demonstrate our software’s capabilities in action and discover strategies to optimize performance.", + "crumbs": [ + "Documentation" + ] + }, + { + "objectID": "documentation/index.html#how-to-get-the-most-out-of-this-section", + "href": "documentation/index.html#how-to-get-the-most-out-of-this-section", + "title": "Documentation", + "section": "How to Get the Most Out of This Section", + "text": "How to Get the Most Out of This Section\nThis section contains resources for the current and past versions of FACTS, which you can choose in the sidebar. If necessary, begin by reviewing the installation guides. Later, you may consult engine-specific user manuals for deeper insights, and explore our curated examples to bring theory into practice. With these resources at your fingertips, you’ll gain a richer, more informed understanding of FACTS and maximize your potential for success.", + "crumbs": [ + "Documentation" + ] + }, + { + "objectID": "documentation/v71/examples/Staged/example2.html", + "href": "documentation/v71/examples/Staged/example2.html", + "title": "Example 2", + "section": "", + "text": "Second example", "crumbs": [ "Documentation", "Version 7.1", "Examples", "Staged", - "Example 1" + "Example 2" ] }, { - "objectID": "documentation/v71/examples/CRM/example1.html", - "href": "documentation/v71/examples/CRM/example1.html", - "title": "Example 1", + "objectID": "documentation/v71/examples/CRM/example2.html", + "href": "documentation/v71/examples/CRM/example2.html", + "title": "Example 2", "section": "", - "text": "First example", + "text": "Second example", "crumbs": [ "Documentation", "Version 7.1", "Examples", "CRM", - "Example 1" + "Example 2" ] }, { - "objectID": "documentation/v71/userguides/installation.html", - "href": "documentation/v71/userguides/installation.html", - "title": "FACTS Installation Guide", - "section": "", - "text": "This document describes how to install and verify the installation of the FACTSTM (Fixed and Adaptive Clinical Trial Simulator) software. It is intended for anyone concerned with the installation of the system.\n\n\n\nThis document covers the installation and installation verification FACTS. It is only intended to demonstrate the usage of the software to the extent that it verifies the software will execute properly in the installed environment.\nFor parameter meanings or detail into the internal workings of the design engines or algorithm check the appropriate System Requirements Document. For appropriate guidance on usage check the User Guides.\n\n\n\nThis document is a guide to the FACTS installation, including both the desktop application and the grid components.", + "objectID": "documentation/v71/userguides/core.html#purpose-of-this-document", + "href": "documentation/v71/userguides/core.html#purpose-of-this-document", + "title": "FACTS Core User Guide", + "section": "2.1 Purpose of this document", + "text": "2.1 Purpose of this document\nThis document describes how to use the ‘Quantities of Interest’ and ‘Design’ options that are common across the FACTS Core design engines. It is intended for all end users of the system.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#purpose-of-this-document", - "href": "documentation/v71/userguides/installation.html#purpose-of-this-document", - "title": "FACTS Installation Guide", - "section": "", - "text": "This document describes how to install and verify the installation of the FACTSTM (Fixed and Adaptive Clinical Trial Simulator) software. It is intended for anyone concerned with the installation of the system.", + "objectID": "documentation/v71/userguides/core.html#scope-of-this-document", + "href": "documentation/v71/userguides/core.html#scope-of-this-document", + "title": "FACTS Core User Guide", + "section": "2.2 Scope of this document", + "text": "2.2 Scope of this document\nThis document covers the design options that are common across the four FACTS Core Design Engines: Continuous, Dichotomous, Time-to-Event and Multiple Endpoint. Design elements that are unique to a particular engine (primarily data simulation and simulation output) are covered in the endpoint specific Core Engine User Guide.\nThis document does not address the use of FACTS Enrichment Designs, Dose Escalation, or Platform Trials, which have separate User Guides.\nThe screenshots provided are specific to a particular installation and may not reflect the exact layout of the information seen by any particular user. They were taken from FACTS V7 & V6[1] installed on Windows 10 or 11. If FACTS is installed on different versions of Windows, or with different Windows ‘themes’ there will be some differences in appearance introduced by Windows. The contents of each tab, however, will still be consistent with the screenshots in this document.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#scope-of-this-document", - "href": "documentation/v71/userguides/installation.html#scope-of-this-document", - "title": "FACTS Installation Guide", - "section": "", - "text": "This document covers the installation and installation verification FACTS. It is only intended to demonstrate the usage of the software to the extent that it verifies the software will execute properly in the installed environment.\nFor parameter meanings or detail into the internal workings of the design engines or algorithm check the appropriate System Requirements Document. For appropriate guidance on usage check the User Guides.", + "objectID": "documentation/v71/userguides/core.html#context-of-this-issue", + "href": "documentation/v71/userguides/core.html#context-of-this-issue", + "title": "FACTS Core User Guide", + "section": "2.3 Context of this Issue", + "text": "2.3 Context of this Issue\nThis is the version of the user guide for inclusion with the FACTS 7.1 release.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#context-of-this-issue", - "href": "documentation/v71/userguides/installation.html#context-of-this-issue", - "title": "FACTS Installation Guide", - "section": "", - "text": "This document is a guide to the FACTS installation, including both the desktop application and the grid components.", + "objectID": "documentation/v71/userguides/core.html#citing-facts", + "href": "documentation/v71/userguides/core.html#citing-facts", + "title": "FACTS Core User Guide", + "section": "2.4 Citing FACTS", + "text": "2.4 Citing FACTS\nIf writing in LaTex and using Bibtex, if you wish to cite FACTS (thank you!), can we suggest the following:\n(techreport?){FACTS71,\n  author = {{FACTS Development Team}},\n  title = {{FACTS}: Fixed and Adaptive Clinical Trial Simulator},\n  year  = {2024},\n  month = {03},\n  number = {Version 7.1},\n  type         = {Computer Software},\n  institution = {Berry Consultants LLC},\n  address = {Austin, TX},\n  note   = {https://www.berryconsultants.com/software/facts/}\n}\nThis will result in a reference that, for example in the APA style, will look like the following:\nFACTS Development Team (2024). FACTS: Fixed and adaptive clinical trial simulator. Computer Software Version 7.1, Berry Consultants LLC, Austin, TX. https://www.berryconsultants.com/software/facts/.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#desktop-requirements", - "href": "documentation/v71/userguides/installation.html#desktop-requirements", - "title": "FACTS Installation Guide", - "section": "3.1 Desktop Requirements", - "text": "3.1 Desktop Requirements\nFACTS can be run on a standard system laptop or desktop running Windows 10 or 11 with the Windows .NET framework v4 or higher installed and at least 1 GB per core or more memory.\nIn addition:\n\nFACTS is expected to run on a display with a resolution of at least 1024x768 pixels and preferably greater.\n\nUser choice of non-default Windows styles/themes may result in unexpected and impractical foreground and background color combinations.\nFACTS 7.0 targets .NET Framework 4.8. Future versions of FACTS will target the latest available .NET Framework version.\nFACTS is now a 64-bit application and will be installed on the target machine’s Program Files area. Previous to FACTS 6.4 versions of FACTS were 32-bit applications installed on the target machine’s Program Files (x86) area.", + "objectID": "documentation/v71/userguides/core.html#definition-of-terms", + "href": "documentation/v71/userguides/core.html#definition-of-terms", + "title": "FACTS Core User Guide", + "section": "2.5 Definition of Terms", + "text": "2.5 Definition of Terms\nThe following acronyms and abbreviations are used in this document.\nActive Comparator A treatment arm where subjects are treated with some existing therapy which the user either wishes to compare the novel treatment to (in addition to control), or wishes to use to check that the study has been properly designed to show a difference from control.\nBaseline The subject’s baseline is their endpoint value before treatment on the trial is started. In FACTS the subject’s baseline is measured at their first visit, any prior visits (e.g. for screening to see if the patient is eligible for the trial) are not included in the simulation.\nCap A limit on the number of subjects recruited. In FACTS users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) but through the use of early stopping rules the actual number recruited may be less, depending on the data observed.\nControl Is the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\nCore FACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\nCRM Continual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\nDE Dose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\nED Enrichment Designs: a mode of FACTS for designing trials where the same treatment is tested in different settings, for example different sub-populations or different but related indications.\nDose Response Model This is a model used in the statistical analysis of the final response as a function of the treatment dose. FACTS includes both parametric and non-parametric models including ‘no model’.\nEndpoint An endpoint is a measure of the subject’s health that is being analyzed in order to learn about the effects of the treatments being studied in the trial.\nFACTS Fixed and Adaptive Clinical Trial Simulator\nFinal Endpoint The final value, or state, of a subject’s endpoint.\nGroup The very neutral term ‘groups’ is used in ED, because the ED design could be used in a number of different settings. The groups could be for instance different patient sub-populations with the same disease, different disease sub-populations such as different sarcoma types, or even different but related diseases that the same treatment might be effective against (migraine, dental pain and post-operative pain for instance). The key characteristic is that there is a need to study each independently (with their own control) but also look across the different groups for some purpose – this might be for analysis where there is an expectation of commonality in response on control, or in the difference from control on the treatment arms; or operationally where there is limited budget, drug supply or time across the groups; or for the purposes of decision making – where the treatment has to be successful in more than one group to be worth considering for further development.\nGUI Graphical User Interface, the part of the FACTS application that the user interacts with.\nHistoric Control A ‘historic control’ is where no control arm is included in the study, and the response on the arms where the novel treatment administered is compared to data from control arms from other already complete studies.\nImputation When the Bayesian statistical models are fitted to the simulated data within FACTS, if longitudinal modeling has been included, then multiple imputation is used for missing subject final endpoint values, whether missing due to the subject having dropped out or their final visit simply not occurred yet. The value is separately sampled at each iteration of the MCMC, from the posterior distribution of the longitudinal model, given the subject’s interim endpoint values.\nInterim Visit A visit between the baseline visit and final visit, at which a subject’s endpoints are measured.\nIntermediate Endpoint The value of a subject’s endpoint at a visit after their baseline visit, but before their final visit. Intermediate endpoint values can be used to estimate, using a longitudinal model, what the subject’s final endpoint will be (or would have been) thus providing additional information for analysis. Multiple imputation is used ensure that these estimated responses are included in the analysis with the correct weighting.\nLongitudinal Model An analysis model that models the relationship between a subject’s interim endpoint values and their final endpoint value, that can be used to impute their final endpoint value when it is not available.\nMethod In the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\nModel In the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\nProfile A profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\nQOI\nQuantity of Interest (QOI) A value to be calculated because it is of interest. The quantity may be of interest because it is to be used in an interim decision, to adapt allocation, for final evaluation, or to ensure it is value is written out in the FACTS results files for analysis outside of FACTS.\nResponse The change in a subject’s endpoint compared to their baseline state.\nScenario A scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include:\n\nthe distribution of the final change from base line, or probability of response or rate of events in the different treatment groups,\nthe properties of subjects’ early responses and the correlation with their final outcome,\nthe rate at which subjects are recruited into the trial,\nthe rate at which subjects drop out of the trial.\n\nSPEC The Design Engine Specification describes the system algorithms, and meaning of parameters.\nSubject Someone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\nTreatment Arm Subjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\nUG The User Guide, describes how to use the system.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#computation-requirements", - "href": "documentation/v71/userguides/installation.html#computation-requirements", - "title": "FACTS Installation Guide", - "section": "3.2 Computation Requirements", - "text": "3.2 Computation Requirements\nFACTS relies on running simulations and these simulations can be very computationally intensive. When running simulations, each simulation can be run separately (they do not depend on the results of other simulations) though to do so can be somewhat inefficient – repeatedly starting new processes and generating separate output files for every simulation that will need to be gathered together in a single “simulations.csv” file and then summarized. Thus FACTS allows the user to specify a “packet size” and the total number of simulations for each scenario to be simulated is divided by this packet size to create a set of independent jobs.\nIf the simulations are run on the users laptop or PC, FACTS will spawn a simulation thread for every core on the local machine up to the maximum number of simulation ‘packets’ that have been requested. The simulations are run at reduced priority so it is possible to continue to use the machine e.g. for email or Word whilst they run. Thus usually 2 or 4 sets of simulations are run in parallel depending on the processor in the laptop or PC.\nThere are a number of options for speeding up the running of FACTS simulations:\n\nThe simplest technically (and the approach we used to take at Berry Consultants) is to have a large multi-core server (say 32 core) remotely accessible to FACTS users and FACTs installed on it. To use, the user copies the “.facts” files to be simulated to a network shared directory which can be accessed from the server. Then after remotely logging into to the server, the user copies these files to a drive on the server, runs the simulations, zips up the results (within the FACTS GUI there is the FACTS File > Export Project menu command to do this) and copies them back to the network shared drive and thence to their local machine.\nUse the FACTS network share folder “grid” interface, implemented using file transfers to and from a shared network drive. On a machine that can act as a client to a grid of compute nodes managed by one of the standard grid management packages (they used to be called “SunGrid” and “Condor” but have metamorphosed over the years) a “sweeper script” runs that transfers jobs to the grid. The jobs automatically transfer their results back to this shared drive. FACTS copies the job to a unique subfolder on the shared network location and then watches for a change in the lock file name - “submitted”, “running”, “complete” that are managed by the sweeper script. Once the simulations are complete FACTS copies the results back to the local machine. The fact that the simulations have been submitted to the grid are stored in the “.facts” file. Whenever that “.facts” file is open in FACTS, FACTS will poll the remote network drive to check if the simulations are complete.\nA more sophisticated FACTS grid interface that uses a web services to communicate between the FACTS client and a Linux server running a web-server (Apache Tomcat) and database (MySQL). The web service is used to submit jobs and they are stored in the database. A database process then submits them to the grid, once again managed by one of the standard grid management packages. The simulation results are then stored in the database for FACTS to download once complete. This provides a more robust and manageable interface, but it more work to set up. We can provide documentation and scripts and we can assist in setting this up. This is the form of grid that we now use in-house at Berry Consultants.\nTechnically as 3. (but for a fee) Berry Consultants can set and manage the grid for you in the cloud. Please contact us to discuss your requirements and for pricing. Therefore FACTS is able to offload the simulations from the desktop to be run by an external system. The interface describing the interactions with the external system is described in the FACTS Grid Interface document. With a FACTS Enterprise License, the command line executable files to run simulations externally under either Windows or Linux environments are available upon request.", + "objectID": "documentation/v71/userguides/core.html#references", + "href": "documentation/v71/userguides/core.html#references", + "title": "FACTS Core User Guide", + "section": "2.6 References:", + "text": "2.6 References:\n[Dunnett] Dunnett CW. A multiple comparison procedure for comparing several treatments with a control. Journal of the American Statistical Association 1955; 50: 1096–1121.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#installation-instructions", - "href": "documentation/v71/userguides/installation.html#installation-instructions", - "title": "FACTS Installation Guide", - "section": "4.1 Installation Instructions", - "text": "4.1 Installation Instructions\nThe FACTS Desktop installation package consists of:\nsetup.exe a Windows installation program, Setup.msi the FACTS Microsoft Installer file Examples.zip a Zip file containing example FACTS projects, Documents.zip a Zip file containing the FACTS documentation. Config.xml an XML file containing the local configuration settings. These files are usually made available for download from Berry Consultants Microsoft App Center site. Download instructions are in a separate document. Versions of these files with the standard file extensions (.msi and .zip) modified are available it may have been these versions that were downloaded to circumvent firewall restrictions and these files will need to be renamed prior to use. Installation will take only a few moments. - Ensure that all the files have the correct file extension and are located on a local drive on the machine on which FACTS is to be installed. Windows can treat installs from networked drives as less trustworthy than installs from local drives and this can result in an incomplete installation. - Right click the setup.exe Windows installation program and select “Run as Administrator”. - Follow the instructions on the screen to complete the installation. - During FACTS installation you will have to option to enable FACTS to report Analytics back to the App Center. This allows to see how much FACTS is used and which features in FACTS are being used. It does NOT include any user or license information, we can’t see WHO is doing what, only WHAT is being done. Obviously we’d be grateful if you’d enable them. Analytics are off by default they will only be enabled of you enable them. Once installed analytics can be turned on or off from the FACTS “Settings” menu command.", + "objectID": "documentation/v71/userguides/core.html#facts-7.1-changes-to-facts-core", + "href": "documentation/v71/userguides/core.html#facts-7.1-changes-to-facts-core", + "title": "FACTS Core User Guide", + "section": "3.1 FACTS 7.1 Changes to FACTS Core", + "text": "3.1 FACTS 7.1 Changes to FACTS Core\nIn FACTS 7.1 FACTS Core and FACTS Staged Design for all endpoints:\n\nThere is a new Quantity of Interest: a frequentist Conditional Power, that can be calculated for the current trial or a specified future trial.\n\nFor Dichotomous endpoints only:\n\nFor p-value QOIs, users can now choose whether they should be derived using a normal approximation (this is the default option and was used in all previous versions of FACTS) or a Fisher’s exact test.\nThere is new Bayesian analysis model for dichotomous endpoints: “Beta-Binomial”, this is only available as an independent dose model, it cannot be combined with any dose response models.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#config.xml", - "href": "documentation/v71/userguides/installation.html#config.xml", - "title": "FACTS Installation Guide", - "section": "4.2 Config.xml", - "text": "4.2 Config.xml\nIncluded with the FACTS installation files is a configuration file that can be edited to local settings before the install files are distributed to users. It is also possible to provide an updated copy of the configuration file to users and ask them to update their default configuration, it is also possible for users to locally modify their configuration and revert to the installed configuration details.\nPrior to installation, a configuration file, ‘config.xml’, is available as one of the installation files. This file can be edited to set up a number of default settings for FACTS.\nThe settings are listed between the tags: <configuration> <userSettings> and </userSettings> </configurations>, for example:\n<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<configuration>\n <userSettings>\n <GridLocation>C:\\\\work\\\\grid</GridLocation>\n <GridOpSys>1</GridOpSys>\n <GridListenerDelay>10000</GridListenerDelay>\n <LocalRVersions>\n <value>version=\"3.3.2\" path=\"C:\\\\Program Files\\\\R\\\\R-3.3.2\\\\bin\\\\R.exe\" active=\"1\"</value>\n <value>version=\"RStudio\" path=\"C:\\\\Program Files\\\\RStudio\\\\bin\\\\RStudio.exe\"</value>\n </LocalRVersions>\n <FactsSimulationServicePortURL>http://nowhere.com:8080/axis2/services/FactsSimulationServicePort</FactsSimulationServicePortURL>\n <GridSimMethod>0</GridSimMethod>\n </userSettings>\n</configuration>\nSpecifically, the following values may be adjusted, as desired:\n\nLocalRVersions – a list of available R (or RStudio) versions, each one bracketed by the tags and and composed of two parameters “version” which can contain any string to be used to identify that version of R and “path” which should contain location of “.exe” that should be run when the user requests R to be run or a Design Report to be generated.\nGridSimMethod – 0 or 1, Determines how FACTS tries to connect to the grid, 0 means the network file share & sweeper script method (option 2 above) is to be used, 1 means that the Web Service method (option 3 or 4 above) is to be used\nIf the network file share method is to be used to connect to the grid then:\n\nGridLocation – the network location of the network file share.\nGridOpSys – 0 or 1, the type of the operating system that is running on the nodes of the grid: 0 – Linux, 1 – Windows (the simulation engine executables have different names in the two environments).\nGridListenerDelay – the delay (in milliseconds) between each poll of the network file share for changes in the state of the simulation results.\n\nIf the Web Service grid access method is to be used to connect to the grid then:\n\nFactsSimulationServicePortURL – specifies the URL to the FACTS web-service endpoint.\n\n\nNote, this configuration file is only used on the initial load of FACTS – subsequently, a local user configuration file is created in a location under the AppData folder – e.g.:\nC:\\Users\\<user_id>\\AppData\\Local\\Berry_Consultants_Inc\\FACTS_File_Loader_Url_<Windows unique file id >\\6.1.6.17435\\user.config\nAny changes made to the configuration from the UI (under the ‘Settings’ menu) are saved to this local file. – and the original config file is only used if the options are reset.\nNB, these local configuration are FACTS version and build specific (note the version and build number in the directory) – which means that if a new install is run, local configuration modifications will be lost.", + "objectID": "documentation/v71/userguides/core.html#facts-7.0-changes-to-facts-core", + "href": "documentation/v71/userguides/core.html#facts-7.0-changes-to-facts-core", + "title": "FACTS Core User Guide", + "section": "3.2 FACTS 7.0 Changes to FACTS Core", + "text": "3.2 FACTS 7.0 Changes to FACTS Core\nIn FACTS 7.0 FACTS Core and FACTS Staged Design:\n\nFACTS Core Continuous, Dichotomous and Multiple Endpoint no longer hav a requirement that there at least two arms in a trial and can simulate single arm trials without requiring ‘fake’ control or second arms. Both Bayesian posterior probability and p-value QOI’s can be evaluated comparing against an absolute response.\nA change that breaks backwards compatibility: FACTS used to be inconsistent in the time units it used for the patient accrual date using days (rather than weeks, which is the time unit used everywhere else). FACTS now outputs the patient accrual date in weeks and expects it to be input in weeks (see the analysis tab and deterministic accrual option).", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#notes-on-access-permissions", - "href": "documentation/v71/userguides/installation.html#notes-on-access-permissions", - "title": "FACTS Installation Guide", - "section": "4.3 Notes on access permissions", - "text": "4.3 Notes on access permissions\nFACTS uses the locations C:\\Program Data\\BerryConsultants and <user>\\AppData\\Local\\BerryConsultants, we have seen some IT departments set the default access permissions to deny access to these locations contrary to Microsoft’s intention and the access will need to be granted for FACTS to run. When FACTS runs simulations it spawns one or more simulations processes, and we have encountered environments where these processes do not get permission to write to network drives. If these permissions cannot be changed, it will be necessary for users to save their “.facts” file run in a directory on the local drive before running simulations, so the results can be written there and then copied/moved to the network drive once complete.\n\n4.3.1 License Installation\nWhen FACTS is first run, it may require the license to be entered. The user can choose the file when prompted, or cut and paste the information into the dialog box. Alternatively, the file can be dropped in the application folder and it will be picked up when needed. Note, depending on access permissions, it may be necessary to initially load FACTS with admin rights in order to load the license key from file.\nSubsequent runs, and subsequent installations of mod level updates, will not require the license to be re-entered.", + "objectID": "documentation/v71/userguides/core.html#facts-6.5-changes-to-facts-core-design-options", + "href": "documentation/v71/userguides/core.html#facts-6.5-changes-to-facts-core-design-options", + "title": "FACTS Core User Guide", + "section": "3.3 FACTS 6.5 Changes to FACTS Core Design options", + "text": "3.3 FACTS 6.5 Changes to FACTS Core Design options\nFACTS 6.5 Core:\n\nIn FACTS Core and Staged Continuous, Dichotomous and Multiple Endpoint there is a new option for p-value QOIs to be evaluated with a super-superiority or non-inferiority delta, and for current trial predictive probabilities the same delta is assumed for the prediction of success.\nIn FACTS Core and Staged Time-to-Event:\n\nWith a Time-to-Event predictor, the timing of interims can be governed by the number of predictor events observed.\nWith a Time-to-Event predictor the file termination can be governed by the number of predictor events observed.\nWith any predictor it is possible to disable the use of the predictor model to predict event times for those patients who have not yet observed an event. The Bayesian analysis of the two endpoints is thus completely de-coupled.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/installation.html#installation-verification", - "href": "documentation/v71/userguides/installation.html#installation-verification", - "title": "FACTS Installation Guide", - "section": "4.4 Installation Verification", - "text": "4.4 Installation Verification", + "objectID": "documentation/v71/userguides/core.html#facts-6.4-changes-to-facts-core-design-options", + "href": "documentation/v71/userguides/core.html#facts-6.4-changes-to-facts-core-design-options", + "title": "FACTS Core User Guide", + "section": "3.4 FACTS 6.4 Changes to FACTS Core Design options", + "text": "3.4 FACTS 6.4 Changes to FACTS Core Design options\nFACTS 6.4 Core:\n\nintroduces three new models: the Hierarchical, Linear, and Hierarchical Linear models. The Linear model subsumes the 2-parameter logistic model for dichotomous data.\nAdds options to dichotomous and time-to-event endpoints to allow posterior probability QOIs to be evaluated on the comparison of log-odds or hazard rate (as an alternative to pre-existing comparison of rates or hazard ratio)", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Installation Guide" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html", - "href": "documentation/v71/userguides/crm.html", - "title": "FACTS Dose Escalation CRM", - "section": "", - "text": "This document describes how use the FACTS Dose Escalation (DE) CRM design engine. It is intended for all end users of the system.\n\n\n\nThis document covers the FACTS Dose Escalation N-CRM design engine user interface.\nThis document does not address the internal workings of the design engines or algorithms, which are addressed in the associated Design Engine Specification. It also does not address the use of FACTS Core Designs or Enrichment Designs, which are covered in other User Guides.\nThe screenshots provided are specific to a particular installation and may not reflect the exact layout of the information seen by any particular user. They were taken from FACTS 6.3 and later installed on Windows 10. Different versions of Windows or the use of different Windows themes will introduce some differences in appearance. The contents of each tab, however, will be consistent with the software.\n\n\n\nThis document has been updated for the version 7.1 release of Dose Escalation FACTS.\n\n\n\nIf writing in LaTex and using Bibtex, if you wish to cite FACTS (thank you!), can we suggest the following:\n@techreport{FACTS71,\n author = {{FACTS Development Team}},\n title = {{FACTS}: Fixed and Adaptive Clinical Trial Simulator},\n year = {2024},\n month = {12},\n number = {Version 7.1},\n type = {Computer Software},\n institution = {Berry Consultants LLC},\n address = {Austin, TX},\n note = {https://www.berryconsultants.com/software/facts/}\n}\nThis will result in a reference that, for example in the APA style, will look like the following:\nFACTS Development Team (2024). FACTS: Fixed and adaptive clinical trial simulator. Computer Software Version 7.1, Berry Consultants LLC, Austin, TX. https://www.berryconsultants.com/software/facts/.\n\n\n\nTable 1 gives an overview of the acronyms and abbreviations used in this document.\n\n\n\nTable 1: List of terms used in the CRM user guide\n\n\n\n\n\n\n\n\n\nName\nDefinition\n\n\n\n\nCap\nA limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap.\n\n\nControl\nIs the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\n\n\nCore\nFACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\n\n\nCRM\nContinual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\n\n\nDE\nDose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\n\n\nED\nEnrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications.\n\n\nFACTS\nFixed and Adaptive Clinical Trial Simulator.\n\n\nFinal Endpoint\nThe final value, or state, of a subject’s endpoint.\n\n\nGUI\nGraphical User Interface, the part of the FACTS application that the user interacts with.\n\n\nMethod\nIn the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\n\n\nModel\nIn the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\n\n\nMTD\nThe dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD).\n\n\nMTD+\nThe dose most likely to be the MTD+ – the dose with the highest Pr(MTD+).\n\n\nPr(MTD)\nA dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses.\n\n\nPr(MTD+)\nA dose’s probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range.\n\n\nProfile\nA profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nScenario\nA scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include: -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups -) the properties of subjects’ early responses and the correlation with their final outcome -) the rate at which subjects are recruited into the trial -) the rate at which subjects drop out of the trial.\n\n\nSPEC\nThe Design Engine Specification, describes the system algorithms, and meaning of parameters.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nSubject\nSomeone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\n\n\nTreatment Arm\nSubjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\n\n\nUG\nThe User Guide; describes how to use the system.", + "objectID": "documentation/v71/userguides/core.html#facts-6.3-changes-to-facts-core-design-options", + "href": "documentation/v71/userguides/core.html#facts-6.3-changes-to-facts-core-design-options", + "title": "FACTS Core User Guide", + "section": "3.5 FACTS 6.3 Changes to FACTS Core Design options", + "text": "3.5 FACTS 6.3 Changes to FACTS Core Design options\nIn FACTS 6.3 FACTS Core there are 3 new 2D dose response models – 2 factorial models and a 2D-NDLM response model.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-purpose", - "href": "documentation/v71/userguides/crm.html#sec-purpose", - "title": "FACTS Dose Escalation CRM", - "section": "", - "text": "This document describes how use the FACTS Dose Escalation (DE) CRM design engine. It is intended for all end users of the system.", + "objectID": "documentation/v71/userguides/core.html#facts-6.2-changes-to-facts-core-design-options", + "href": "documentation/v71/userguides/core.html#facts-6.2-changes-to-facts-core-design-options", + "title": "FACTS Core User Guide", + "section": "3.6 FACTS 6.2 Changes to FACTS Core Design options", + "text": "3.6 FACTS 6.2 Changes to FACTS Core Design options\nThere were no changes to the Core Design options in DACTS 6.2.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-scope", - "href": "documentation/v71/userguides/crm.html#sec-scope", - "title": "FACTS Dose Escalation CRM", - "section": "", - "text": "This document covers the FACTS Dose Escalation N-CRM design engine user interface.\nThis document does not address the internal workings of the design engines or algorithms, which are addressed in the associated Design Engine Specification. It also does not address the use of FACTS Core Designs or Enrichment Designs, which are covered in other User Guides.\nThe screenshots provided are specific to a particular installation and may not reflect the exact layout of the information seen by any particular user. They were taken from FACTS 6.3 and later installed on Windows 10. Different versions of Windows or the use of different Windows themes will introduce some differences in appearance. The contents of each tab, however, will be consistent with the software.", + "objectID": "documentation/v71/userguides/core.html#facts-6.1-changes-to-facts-core-design-options", + "href": "documentation/v71/userguides/core.html#facts-6.1-changes-to-facts-core-design-options", + "title": "FACTS Core User Guide", + "section": "3.7 FACTS 6.1 Changes to FACTS Core Design options", + "text": "3.7 FACTS 6.1 Changes to FACTS Core Design options\nIn FACTS 6.1 FACTS Core has the new feature of ‘design variants’ that allow the user to easily simulate and evaluate FACTS Core design at different sample sizes. This change doesn’t alter the design options – but it does make it much easier to explore the effect of the change of sample size on a design.\nThere are two additional changes concern frequentist calculations:\n\nBetter control over which frequentist analyses are computed and output. There is now no longer a need to ‘enable’ frequentist analysis; the user can just select which ones are required.\nThe ability to use p-values for early stopping decisions at interims – if there is too little final data to compute a p-value the values of ‘1’ is returned.\n\nAnd there is one change that effects TTE QOIs (Quantities of Interest), it is now possible to specify Target QOIs that use the predictor endpoint in a TTE design.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-context", - "href": "documentation/v71/userguides/crm.html#sec-context", - "title": "FACTS Dose Escalation CRM", - "section": "", - "text": "This document has been updated for the version 7.1 release of Dose Escalation FACTS.", + "objectID": "documentation/v71/userguides/core.html#subject-responses", + "href": "documentation/v71/userguides/core.html#subject-responses", + "title": "FACTS Core User Guide", + "section": "4.1 Subject Responses", + "text": "4.1 Subject Responses\nThe methods used to simulate subject responses vary by endpoint type. For each endpoint, the endpoint specific user guides provide information about simulating subject responses.\nFor simulating dichotomous responses see: FACTS Core Dichotomous User Guide\nFor simulating continuous responses see: FACTS Core Continuous User Guide\nFor simulating time to event responses see: FACTS Core Time-to-Event User Guide\nFor simulating multiple endpoint responses see the continuous or dichotomous user guide, depending on the type of endpoints used in the multiple endpoint study.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-citing", - "href": "documentation/v71/userguides/crm.html#sec-citing", - "title": "FACTS Dose Escalation CRM", - "section": "", - "text": "If writing in LaTex and using Bibtex, if you wish to cite FACTS (thank you!), can we suggest the following:\n@techreport{FACTS71,\n author = {{FACTS Development Team}},\n title = {{FACTS}: Fixed and Adaptive Clinical Trial Simulator},\n year = {2024},\n month = {12},\n number = {Version 7.1},\n type = {Computer Software},\n institution = {Berry Consultants LLC},\n address = {Austin, TX},\n note = {https://www.berryconsultants.com/software/facts/}\n}\nThis will result in a reference that, for example in the APA style, will look like the following:\nFACTS Development Team (2024). FACTS: Fixed and adaptive clinical trial simulator. Computer Software Version 7.1, Berry Consultants LLC, Austin, TX. https://www.berryconsultants.com/software/facts/.", + "objectID": "documentation/v71/userguides/core.html#accrual", + "href": "documentation/v71/userguides/core.html#accrual", + "title": "FACTS Core User Guide", + "section": "4.2 Accrual", + "text": "4.2 Accrual\nThe Accrual sub-tab provides an interface for specifying accrual profiles; these define the mean recruitment rate week by week during the trial. During the simulation, the simulator uses a Poisson process to simulate the random arrival of subjects with the specified mean accrual rate.\nAccrual profiles are list on the left of the screen, as depicted below. These accrual profiles may be renamed by double-clicking on them, and typing a new profile name. After creating a profile, the user must create at least one recruitment region. Early in the trial design process, detailed simulation of the expected accrual pattern is typically not necessary and a single region with a simple mean accrual rate is sufficient.\nTo model more accurately the expected accrual rates over the trial, the user may specify multiple regions for each accrual profile and separately parameterize them. Regions are added via the table in the center of the screen (Figure 7‑1). Within this table, the user may modify:\n\nthe peak, mean weekly recruitment rate,\nthe start date (in weeks from the start of the trial) for this recruitment region,\nwhether the region will have a ramp up phase and if so when the ramp up will be complete (in weeks from the start of the trial).\nWhether the region will have a ramp down, and if so when the ramp down start and when the ramp down will complete (in weeks from the start of the trial).\n\nRamp up/ramp down define simple linear increase/decreases in mean recruitment rate from the start to the end of the ramp. Note that simulation of accrual is probabilistic but ramp downs are defined in terms of time, so even if ramp downs are planned so that at the average accrual rate they will occur as the trial reaches cap, there is a risk in simulations when accrual has been slower than average, that ramp downs occur before the full sample size is reached. It is advisable to have at least one region that doesn’t ramp down to prevent simulations being unable to complete.\nA graph of the recruitment rate of the highlighted region is shown as well. As the recruitment parameters are changed, the graph will update to show the time at which full accrual is reached. An accrual profile that does not reach full accrual is invalid and cannot be used to run simulations.\n\nIn the screenshot above you can see the two step ramp up in accrual from two regions – each starting at different offsets into the trial.\nNote that the accrual profile graph is only the mean expectation; actual accrual is simulated using exponential distributions for the intervals between subjects, derived from the mean accrual profile specified here. Thus some simulated trials will recruit more quickly than this and some more slowly.\nThere are commands to import and export region details from/to simple external XML files. When importing, the regions defined in the external file are added to the regions already defined, they don’t replace them.\nThis is an example of a very simple region file defining just one region:\n<?xml version=“1.0” encoding=“utf-8”?>\n<regions>\n<region>\n<name>Region 1</name>\n<rate>5</rate>\n<start>0</start>\n<ramp-up />\n<ramp-down />\n</region>\n</regions>\n\n4.2.1 Deterministic Accrual\nIf “Deterministic” accrual has been specified on the Study > Study Info tab, then on the Accrual tab, rather that specifying an accrual profile from which subject recruitment times are simulated, the user loads a file of specific accrual dates for every subject.\n\nThe user specifies a “.dat” file to load that contains the subject accrual dates in weeks[2] from the start of the trial.\nThe required file format is a text file with comma separate values. One row per subject, with 3 fields on each row:\n\nthe subject ID, (an integer)\nthe ID of the region where the subject was recruited (an integer)\nand the subjects randomization date (in weeks from the start of the trial – this is a ‘real’ number allowing fractions of a week to be specified)\n\nThe file must contain sufficient entries to allow the maximum number of subjects specified on the Study > Study Info tab to be recruited.\nAfter successfully loading a file, the FACTS GUI shows a plot of the resulting weekly accrual rate", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-definitions", - "href": "documentation/v71/userguides/crm.html#sec-definitions", - "title": "FACTS Dose Escalation CRM", - "section": "", - "text": "Table 1 gives an overview of the acronyms and abbreviations used in this document.\n\n\n\nTable 1: List of terms used in the CRM user guide\n\n\n\n\n\n\n\n\n\nName\nDefinition\n\n\n\n\nCap\nA limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap.\n\n\nControl\nIs the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\n\n\nCore\nFACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\n\n\nCRM\nContinual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\n\n\nDE\nDose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\n\n\nED\nEnrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications.\n\n\nFACTS\nFixed and Adaptive Clinical Trial Simulator.\n\n\nFinal Endpoint\nThe final value, or state, of a subject’s endpoint.\n\n\nGUI\nGraphical User Interface, the part of the FACTS application that the user interacts with.\n\n\nMethod\nIn the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\n\n\nModel\nIn the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\n\n\nMTD\nThe dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD).\n\n\nMTD+\nThe dose most likely to be the MTD+ – the dose with the highest Pr(MTD+).\n\n\nPr(MTD)\nA dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses.\n\n\nPr(MTD+)\nA dose’s probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range.\n\n\nProfile\nA profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nScenario\nA scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include: -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups -) the properties of subjects’ early responses and the correlation with their final outcome -) the rate at which subjects are recruited into the trial -) the rate at which subjects drop out of the trial.\n\n\nSPEC\nThe Design Engine Specification, describes the system algorithms, and meaning of parameters.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nSubject\nSomeone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\n\n\nTreatment Arm\nSubjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\n\n\nUG\nThe User Guide; describes how to use the system.", + "objectID": "documentation/v71/userguides/core.html#drop-out-rates", + "href": "documentation/v71/userguides/core.html#drop-out-rates", + "title": "FACTS Core User Guide", + "section": "4.3 Drop-out Rates", + "text": "4.3 Drop-out Rates\nFor the continuous and dichotomous engines, and the multiple endpoint engine, the default dropout scenario is that no subjects drop out of the study before observing their final endpoint data. If dropouts are expected, the user can specify either the “Dropouts per Dose,” or “Dropouts per Dose per Visit.”\nIf “Dropouts per Dose” is selected, then each subject has a probability of not having an observable final endpoint value equal to the dropout rate of the dose that subject is randomized to. If each subject has multiple visits and “Dropouts per Dose” is selected, then the conditional probability of dropping out before each visit given that the subject had not dropped out up to the visit before rates are all equal. In other words, if the total dropout rate is πD, the probability of dropping out between visits i and i + 1 given that the subject had not dropped out at visit i is \\(1 - \\left( 1 - \\pi\\_{D} \\right)^{\\frac{1}{V}}\\) where V is the total number of visits.\nIf “Dropouts per Dose per Visit” is selected, then each subject has a user specified probability of dropping out before a visit v that is specified as the conditional probability of dropping out before visit v given that that they had not dropped out by visit v − 1. This leads to a total dropout rate πD for a participant that is equal to:\n\\[\\pi\\_{D} = 1 - \\prod\\_{v = 0}^{V}{(1 - \\pi\\_{v})}\\]", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#facts-7.1-changes-to-n-crm", - "href": "documentation/v71/userguides/crm.html#facts-7.1-changes-to-n-crm", - "title": "FACTS Dose Escalation CRM", - "section": "2.1 FACTS 7.1 Changes to N-CRM", - "text": "2.1 FACTS 7.1 Changes to N-CRM\nIn FACTS 7.1 there were new features added to N-CRM:\n\nIt is now possible to backfill to the current escalation dose (also known as “frontfilling”).\nIt is now possible to specify a third queue concept – maximum number of patients in their DLT period on the current MTD estimate.\nIt is now possible to define the concept of “near” target/MTD as part of stopping rules, for both fine-grained and regular dosing.", - "crumbs": [ - "Documentation", - "Version 7.1", - "User Guides", - "FACTS Dose Escalation CRM" - ] - }, - { - "objectID": "documentation/v71/userguides/crm.html#facts-7.0-changes-to-n-crm", - "href": "documentation/v71/userguides/crm.html#facts-7.0-changes-to-n-crm", - "title": "FACTS Dose Escalation CRM", - "section": "2.2 FACTS 7.0 Changes to N-CRM", - "text": "2.2 FACTS 7.0 Changes to N-CRM\nIn FACTS 7.0 the only change was on the Analysis tab, when entering subject data manually, the FACTS GUI now ensures that a cohort number is entered for every subject.", + "objectID": "documentation/v71/userguides/core.html#posterior-probabilities", + "href": "documentation/v71/userguides/core.html#posterior-probabilities", + "title": "FACTS Core User Guide", + "section": "5.1 Posterior Probabilities", + "text": "5.1 Posterior Probabilities\nThese are Bayesian quantities to be calculated at each interim and at the final analysis.\n\nA Posterior Probability is specified as:\n\nCompare:\n\nContinuous: Means\nDichotomous: Rates or Log-odds\nTime-to-Event: Hazard Ratio or Hazard Rates.\n\n\n\n\nCondition: “>” or “<” a comparison value.\nRelative to an absolute value or relative to the response on a specific dose.\nThe comparison can include a delta, which is the absolute value to be compared against if the comparison is absolute, or a value that the difference relative to the comparison arm is compared to.\nThe QOI will be given a “name” derived from these details and a short or Alternative name that will be used in the output files to allow easier access from other software, e.g. from within R.\nIf the endpoint is TTE and the design includes a predictor endpoint, then the definition of the QOI includes the specification of which endpoint it applies to.\n\n\n5.1.1 Notes on setting Delta’s\nIn the three endpoints delta’s are defined as:\n\nContinuous A CSD (Clinically Significant Difference) in the estimates of the mean response.\nDichotomous A CSD in the estimate of the response rates\nTime-to-Event A CSHRD (Clinically Significant Hazard Ratio Difference) in the estimate of the Hazard Ratio\n\nA “standard” hypothesis test for demonstrating superiority to control uses a delta of 0. Testing for superiority with a non-zero delta is different, and the implications need to be carefully understood[3]. Where the term CSD is used in this document, it should be taken to refer to CSHRD as well unless it is specifically stated otherwise.\nWhen setting a target treatment difference from control for the study to beat, it is also common to require a degree of confidence that the target has been beaten. To achieve posterior probabilities of > 50% that the target has been beaten, the estimated mean difference will have to be greater than the target difference.\nThus, when setting a delta, we are setting up two hurdles the study drug must beat, first the delta and then on top of that an additional margin to give a > 50% confidence that the margin has been beaten. Thus, it is necessary to avoid setting the target delta too large. A common rookie error is to set the delta to the ‘expected difference’ (the value that might have been used in a conventional sample size calculation). In scenarios where the simulated response is equal to the ‘expected difference’ and hence the CSD this will give probabilities of being better than control by the delta of 50% on average, regardless of the sample size.\nIt is inadvisable to require a posterior probability of 50% or better than the response is better than the Control by the delta as this turns the test into one that simply depends on whether the point estimate of the response is better.\nIt is inadvisable to require posterior probability of less than 50% for success, as such criteria have the undesirable characteristic that they can be met in circumstances where it can be seen that if further data was gathered consistent with what has already been seen, it would lead the threshold no longer being met! The posterior distribution would shrink so that there was no longer sufficient of the tail above the CSD.\nIt is better therefore to use a delta that is less than the expected difference that it is hoped to achieve, somewhat like having a non-inferiority margin around the target. So, when the design is simulated with a response at the expected difference the target will be clearly exceeded. A useful default value to use for a delta is half the ‘expected difference’. This usually yields “comprehensible” probability thresholds for both success and futility.\nUsing a delta has benefits however – simply being better than control but for very small difference can be established simply by having large sample sizes. Being better than control by a delta establishes some confidence that there is some patient benefit. Use of a delta is also useful if otherwise success thresholds “well out in the tail” (e.g. > 0.99) are required such as the equivalent of an early look in a conservative Group Sequential design. Though the use of a delta does mean that there is a less direct equivalence to a p-value.\n\n\n5.1.2 P-value Delta’s\nSeparately from the CSD/CSHRD delta, with a continuous or dichotomous endpoint (but not time-to-event), a frequentist super-superiority/non-inferiority delta can be specified.\nThese use the same selection of super-superiority/non-inferiority as the CSD\n\nCurrently, unlike the CSD delta that is only applied to the default posterior probability QOI and MED target QOI, the p-value delta is applied to all the p-value QOIs and it cannot be overridden.\nThe value of the p-value delta is constrained to be 0 or positive. The ‘direction’ of the delta depends then on the direction of the endpoint (whether “higher/lower is better” or “a response is a positive/negative outcome”.\n\n\n\nFigure 8‑1: Accrual\n\n\n\n\n\n\n\n\n\n\n\n\nHigher is better / Response is positive\n\n\nLower is better / Response is negative\n\n\n\n\n\n\nSuper-Superiority\n\n\nTrt – Control > delta\n\n\nTrt – Control < -delta\n\n\n\n\nNon-inferiority\n\n\nTrt – Control > -delta\n\n\nTrt – Control < delta\n\n\n\n\nFigure 8‑1: Accrual\nSign of delta and direction of test\nIf no control arm is included p-values, with a continuous or dichotomous endpoint, the treatment response is compared to a fixed value:\n\nContinuous – compared to a response of 0.\nDichotomous – compared to a rate of 0.5.\n\nNow with p-value deltas the p-value QOIs (and current trial predictive probability QOIs) can be compared to any fixed value – by specifying a delta that combined with the default value (of 0 or 0..5) gives the absolute value that you want to compare to.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#facts-6.5-changes-to-n-crm", - "href": "documentation/v71/userguides/crm.html#facts-6.5-changes-to-n-crm", - "title": "FACTS Dose Escalation CRM", - "section": "2.3 FACTS 6.5 Changes to N-CRM", - "text": "2.3 FACTS 6.5 Changes to N-CRM\nIn FACTS 6.5 there was a new feature added to N-CRM:\n\nIt is now possible to generate a design report – a Word document describing design - once the design has been simulated. In FACTS 6.5 there was two small changes to the functionality:\nWhen deriving toxicity/efficacy priors from quantiles at the lowest and highest doses, the “middle” probability option now refers to the median dose rather than the reference dose and is now optional. When pre-6.5 FACTS files are loaded in FACTS 6.5, the “middle” probability option will be ignored and replaced by 0.5.\nWhen deriving toxicity/efficacy priors from specific quantiles the specification of at least two dose levels is now required whereas previously the specification of at least three dose levels was required.\n\nIn FACTS 6.5 there were some improvements in the simulated behavior:\n\nDesigns which include efficacy, the “Maximum cohorts used to determine MTD” parameter on the Allocation Rule tab is now observed, in FACTS 6.4 and earlier it was ignored.\nIn N-CRM designs using open enrollment without accrual pausing, FACTS will now output entries in the cohort file for subjects that have been lost following stopping rules being met.\nIn N-CRM designs using open enrollment, FACTS will no longer prematurely apply stopping conditions when there are still subjects whose outcomes have been observed, but not yet processed.\nIn N-CRM designs using open enrollment, FACTS will now report the selected MTD/MED/OSD and associated state to be the dose where the stopping conditions were first met, unless the MTD has subsequently decreased post stopping rules being met. This is to prevent a dose above the one selected when the stopping conditions were met being reported as the MTD when it is very likely that there is insufficient data on this higher dose to justify its selection. If rather than reporting the MTD at the point when the stopping rules where met, you would like the trial to resume if the dose selected as MTD has changed (and this the stopping rules possibly no longer met), ensure that the ”Pause accrual and wait for completers” option is selected on the “Stopping Criteria” tab. This allows the trial to resume if the recruitment cap has not been met.\nFACTS Command Line mode and FLFLL (FACTS Linux File Loader Lite) now correctly handle the processing of N-CRM designs whose prior was derived using the “Legacy Prior” option.", + "objectID": "documentation/v71/userguides/core.html#predictive-probabilities", + "href": "documentation/v71/userguides/core.html#predictive-probabilities", + "title": "FACTS Core User Guide", + "section": "5.2 Predictive Probabilities", + "text": "5.2 Predictive Probabilities\nThere are two types of predictive probabilities –\n\nBayesian predictive probabilities, which are Bayesian predictions of frequentist outcomes and take into account the uncertainty around a set of parameters,\nand conditional power, which aims to calculate the frequentist probability of success assuming a set of parameters to be true.\n\nThe primary difference between the Bayesian predictive probabilities and the conditional power calculations is that the Bayesian predictive probabilities are calculated taking the variability around the estimated treatment effect into account, while the conditional power calculations assume that the observed test statistic of past data is the exact effect that future data will be generated from.\nFor both Bayesian predictive probabilities and conditional power, we differentiate two types, predicting the outcome in the current trial and predicting the outcome in a future trial.\n\n5.2.1 Bayesian predictive probabilities\n\n5.2.1.1 Current Trial Bayesian Predictive Probabilities\nIn the current trial, the outcome can be predicted under one of two assumptions:\n\nThat no new subjects are recruited, but all those who have been recruited are followed up until they are complete.\nThat the trial continues recruiting using the current allocation ratios until the trial maximum sample size is reached, and all subjects recruited are followed up until complete.\n\nPredictive probabilities currently can only predict outcomes based on p-values. Note that since p-values are only calculated as comparisons against a control arm, predictive probabilities of success in the current trial are only available if the current trial includes a control arm.\n\nThe user specifies how missingness is handled in the final analysis, the p-value test type – unadjusted, Bonferroni or Dunnett’s and the (one sided) alpha level for the significance test. The QOI assumes that the specified default p-value delta is used in the final test.\nThe predictive probability of the current trial at the maximum sample size is only available:\n\nIf the allocation is either fixed, or fixed with arm dropping, but not adaptive allocation.\n\nThe predictive probability is calculated by simulating the remaining subjects, assuming their allocated at the current probabilities of allocation and simulating their final response based on the rate of response or (Normal) distribution of responses observed so far for each arm.\n\nIgnoring the possibility of the trial stopping or dropping an arm at a future interim\nIgnoring the possibility of future subject drop-outs.\n\nThere is one simulation of the remaining data per MCMC loop, potentially significantly increasing the time to perform the overall simulation of the trial.\nIf there is no data available on the arms involved in the Bayesian predictive probability calculation, FACTS will still perform the simulation of future subject outcomes based on posterior distribution. The posterior distribution for the arms with no available data will be the same as the user specified prior distribution.\n\n\n5.2.1.2 Current Trial Bayesian Predictive Probabilities – Time-to-Event\nUnlike the Continuous and Dichotomous endpoints, to predict the probability of success at full enrolment with a Time-to-Event endpoint, it is also necessary to simulate the accrual rate (and hence how many events might be observed).\n\nFor TTE, for a Predictive Probability of Success at Full Enrolment, there are new parameters to determine how accrual is modelled. There are 3 models for accrual\n\nFixed Rate, the parameters for this are:\n\nThe fixed (mean) accrual rate per week to simulate.\n\nEstimated from the Last ‘W’ Weeks accrual data, using a Poisson distribution, with a Gamma prior. The parameters for this are\n\nThe number of past weeks W to use the accrual data from.\nThe prior mean for the model of the accrual rate\nThe weight of the prior\n\nEstimated from all the accrual data from the start of the trial, using a Poisson distribution, with a Gamma prior, the parameters for this are:\n\nThe prior mean for the model of the accrual rate\nThe weight of the prior\n\n\n\n\n5.2.1.3 Future Trial Bayesian Predictive Probabilities\nFor predictive probabilities for a future trial, a predictive probability of success in a subsequent phase 3 trial is estimated during the current trial. The probability of success in phase 3 is calculated for each study arm, based on the specification of the phase 3 trial given here of:\n\nwhether the aim is to show superiority or non-inferiority,\nthe sample size per arm,\nthe required one-sided alpha,\nand the super-superiority margin or non-inferiority margin (if any).\n\nGiven these criteria, FACTS calculates the predicted probability of success of the subsequent trial for that endpoint assuming the estimate of the response on that endpoint, integrated over the uncertainty in those estimates. The conventional expected power of the specified future trial is calculated for the treatment effect in each MCMC sample and then averaged. This predicted probability of success can then be used in the stopping criteria and final evaluation criteria for the current trial.\nThis QOI is an extension of the “probability of success in phase 3” in earlier versions of FACTS – the difference now is that multiple different possible future trials can be specified in different QOIs and used for different decisions.\n\nThis predictive probability has the following parameters that must be specified:\n\nWhether the future trial will be for Superiority or Non-inferiority.\nThe size of the future trial in terms of the number of subjects on each arm.\nThe (one sided) alpha level that will be used to determine the significance of the trial.\nThe Super-superiority margin (if any) or the non-inferiority margin. The default p-value delta is not used for this QOI it is specified as part of the QOI and can be different from the default.\n\nAs with all QOIs the QIO will be given an alternative shorter name that can be used when accessing the output files from other software such as R.\nIf there is no data available on the arms involved in the Bayesian predictive probability calculation, FACTS will still calculate the predictive probability of the future trial being a success based on the estimated posterior distribution. The posterior distribution for the arms with no available data will be the same as the user specified prior distribution.\n\n\n\n5.2.2 Conditional Power\nConditional power is currently available for Continuous and Dichotomous endpoints in Core and Staged Designs.\nWhen creating a Conditional Power QOI, the first specification that must be made is whether the conditional power should be calculated for the current trial or for a hypothetical future trial. The two selections are fundamentally different.\nThe Current Trial conditional power takes the information collected in the trial so far, and assumes that for the remainder of the current trial the data collected has an effect equal to the point estimate of the already collected data. The previously collected trial data is then combined with hypothetical future data and weighted based on the amount of information that has been and will be observed by the end of the trial. The result is the probability that the current trial will reject the null hypothesis at a provided alpha level under the assumption that the future patients are generated from a population having a treatment effect exactly equal to the past data’s test statistic.\nThe Future Trial conditional power also uses the information accrued in the trial so far to calculate the assumed treatment effect moving forward, but assumes that a new study would be started that does not use the data from the current trial in its analysis. The new study is assumed to be a 1:1 randomized study if there is a control arm, and a single arm study if no control, with a sample size per arm, objective, and alpha level specified at the time of QOI creation.\nIf a conditional power is ever calculated for an arm with no final response data or against a control arm with no final response data, the conditional power will be called missing (-9999 in FACTS).\n\n5.2.2.1 Current Trial Conditional Power\nWhen creating a current trial conditional power, the missingness strategy, multiplicity adjustment, final sample size, and alpha level for the significance test must be specified.\n\n\nHandle missingness using:\nMissingness handling for a continuous endpoint can be specified as:\n\nIgnore: subjects that are known dropouts are not included in the current or final sample size, and are not used to estimate the treatment effect.\nLast Observation Carried Forward (LOCF): subjects that are known dropouts have their last observed endpoint value assumed to be their final endpoint. Subjects with no early observed data are ignored. Subjects that have data to carry forward are considered complete, and are used to estimate the current treatment effect.\nBaseline Observation Carried Forward (BOCF): subjects that are known dropouts have their baseline value assumed to be their final endpoint. They are included in the current information as complete subjects and are used to estimate the current treatment effect. BOCF is only available for the continuous endpoint and when simulating baseline for subjects.\nFailure: subjects that are known dropouts are assumed to have a negative outcome at their final visit. If responses are good, the subject is a non-response, and if responses are bad, the subject is a responder. Failure is only available for dichotomous endpoints.\n\n\n\nTest Type\nThe test type can either be Unadjusted or Bonferroni. An unadjusted test will always use the specified alpha level in the significance test. The Bonferroni adjustment will divide the specified alpha value by the number of non-control arms enrolling in the study in the enrolment period leading up to the current analysis time.\n\n\nSample Size:\nThe current trial conditional power can be calculated at two different future time points.\n\nCurrent Enrollment: That no new subjects are recruited, but all those who have been recruited are followed up until they are complete.\nTrial Maximum: That the trial would continue recruiting subjects using the current allocation ratios until the trial maximum sample size is reached, and all subjects recruited are followed up until they have the opportunity to complete.\n\n\n\nOne-sided Alpha\nThe threshold that the current trial would have to be less than in order to be considered a success. The success/futility values specified in the design tab are not used in the conditional power calculation. This value may be adjusted by the “Test type:” input.\n\n\nSuper-Superiority (Non-inferiority) margin for p-value:\nThis value cannot be changed on the QOI pop-up. It’s instead modified at the bottom of the QOI page. The objective of the current trial cannot be different for each individual current trial conditional power QOIs.\n\n\nAdditional Notes\nCurrently, conditional power will always assume that there is no correction applied to combine the different p-values from the analysis timepoints, i.e. no combination test is used.\nThe conditional power of the current trial at the maximum sample size is only available if the allocation is either fixed, or fixed with arm dropping, but not adaptive allocation or deterministic allocation.\nConditional power for the current trial is calculated\n\nIgnoring the possibility of the trial stopping or dropping an arm at a future interim\n\n\n\nIgnoring the possibility of future subject drop-outs.\n\n\n\n\n5.2.2.2 Future Trial Conditional Power\nConditional power of a future trial is reduced to a power calculation for a future trial, given the current frequentist estimates of treatment effect and standard deviation and a set of assumptions for the future trial, such as sample sizes, hypothesis to be tested, and significance levels to be used.\nThe test type of the future trial can be set to Superiority or Non-inferiority. If the superiority or non-inferiority margin is set to 0, then both types of tests simplify to traditional tests of superiority with no margin. If a non-zero margin is set, then the future trial must meet the success criteria indicated by the test type and the margin. The margin cannot be negative, but a super superiority test with a margin of -0.5 is equivalent to a non-inferiority test with a margin of 0.5.\nThe subjects per arm dictates how many subjects would be enrolled on each arm in the future study. If there is a control arm in the current trial, then the future trial is assumed to be randomized 1:1 between the active arm and the control. If there is no control arm in the current study, then the future trial is a single arm trial testing against the performance goal specified in the Freq. Comparison Response box in the QOI creation pop-up.\nThe One-sided Alpha is the significance level of the final analysis test of the future trial. The future trial is assumed to have 1 active arm, so there are no adjustments to the alpha level available.\nThe superiority margin or non-inferiority margin indicate the amount that the active arm must be better/not worse than the control arm by. If there is no control arm then this is the Freq Comparison response, which is the value that the active arms must be significantly better than in order to be declared a success. The frequentist margin for p-value QOIs on the QOI tab is not used for Future conditional power calculations – the future trial can have a different objective than the current trial.\n\n\n\n5.2.2.3 Technical Aspects of Conditional Power Calculations\nThe conditional power calculations in FACTS are all calculated similarly to Jennison and Turnbull (2000)[4].\nFor continuous endpoint conditional power calculations, the conditional power of the future trial is calculated using a pooled standard deviation from all arms. For dichotomous conditional power calculations, each arm has its own standard deviation based on the MLE estimate of its proportion. These decision result in the conditional power tests matching how simple p-values are calculated for continuous and dichotomous endpoints.\nThe following sections will provide formulae to calculate the conditional power in the case where there is a control arm. Simplifications for when the arm is being compared to a fixed value rather than a control arm are simple: information fractions are only a function of the active arm standard deviation and the test statistic does not have a second sample mean subtracted from the active arm.\nThe value of δ, which can be a non-inferiority margin or a super superiority margin, is always positive coming out of FACTS. To make the math more concise we can define a couple of coefficients for the δ term that allow it to be used without re-writing formulas for different hypothesis test setups. If high values of the endpoint are good, then s1 = 1, and if low values of the endpoint are good, then s1 = −1. If the specified δ is a non-inferiority margin, then s2 = 1, and if it’s a super superiority margin then s2 = −1.\n\nContinuous Conditional Power for the Current Trial\nLet t be the interim index that the conditional power is being computed at, and T be the time of the analysis that the conditional power is being computed for. Then Zk is the test statistic of the data collected up to the current interim analysis in the study, Ik is the information level at the time of the interim analysis, and IK is the information level at the end of the study that the conditional power is being calculated for.\nLet arm 1 be the control and arm 2 be the active arm,  \\(\\overline{x\\_{it}}\\) be the sample mean of arm i at time t, \\(\\widehat{\\sigma\\_{i}^{2}}\\) be the sample variance of arm i at time t, n*i**t be the number of subjects with complete known final data on arm i* at interim analysis t, and n*i**T be the number of subjects with complete known final data on arm i* at the time that conditional power is being calculated for. The pooled variance estimate is \\(\\widehat{\\sigma^{2}} = \\sum\\_{d = 1}^{D}\\widehat{\\frac{\\sigma\\_{d}^{2}}{n\\_{dt}}}\\) where D is the total number of arms in the study.\nThen,\n\\[I\\_{t} = \\left( \\frac{\\widehat{\\sigma^{2}}}{n\\_{1t}} + \\widehat{\\frac{\\sigma^{2}}{n\\_{2t}}} \\right)^{- 1}\\]\n\\[I\\_{T} = \\left( \\frac{\\widehat{\\sigma^{2}}}{n\\_{1T}} + \\widehat{\\frac{\\sigma^{2}}{n\\_{2T}}} \\right)^{- 1}\\]\n\\[Z\\_{t} = \\left( {\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} + s\\_{1}s\\_{2}\\delta \\right)\\sqrt{I\\_{t}}\\]\nwhere δ is the non-inferiority or super superiority margin.\nThen for a one-sided alpha level of α, let z1 − α be the critical value corresponding to α.\nIf high values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{Z\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} + s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{{- Z}\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} - s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\n\n\nCalculation of Continuous Conditional Power for a Future Trial\nMost of the future trial conditional power calculation is the same as the above current trial conditional power. There are some simplifications.\n\\({\\overline{x}}\\_{it}\\) and \\(\\widehat{\\sigma\\_{i}^{2}}\\) are the same as in the current conditional power calculation. It, the weight of the current trial Z-score, is set to 0. IK is now the information at the end of the future trial, and is calculated as:\n\\[I\\_{T} = \\left( \\frac{\\widehat{\\sigma^{2}}}{n\\_{T}} + \\widehat{\\frac{\\sigma^{2}}{n\\_{T}}} \\right)^{- 1}\\]\nwhere nT is the sample size per arm in the future trial and again σ̂2 is the pooled variance.\nIf high values of the endpoint are good, the conditional power of a future trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} + s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of a future trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} - s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]\n\n\nCalculation of Dichotomous Conditional Power for the Current Trial\nThe dichotomous conditional power calculations are similar in spirit to the continuous conditional power calculations. One substantial difference is in how the dichotomous conditional power tests handle a non-inferiority or super superiority margin, δ. The method of calculating an appropriate test statistic for a frequentist hypothesis test is not obvious when the null scenario has a non-zero δ.\nWhen there is no margin, the estimate for each treatment is simply based on the observed response proportion \\(\\widehat{p\\_{i}}\\) for arm i, and the test statistic for a comparison of the control arm, c, with dose d is the usual Wald test\n\\[Z\\_{d} = \\frac{\\widehat{p\\_{d}} - \\widehat{p\\_{c}}}{\\sqrt{\\frac{\\widehat{p\\_{d}}(1 - \\widehat{p\\_{d}})}{n\\_{d}} + \\frac{\\widehat{p\\_{c}}(1 - \\widehat{p\\_{c}})}{n\\_{c}}}}\\]\nWhen there is a margin, FACTS uses the Farrington-Manning Likelihood Score test statistic to estimate quantities \\(\\widetilde{p\\_{d}}\\) and \\(\\widetilde{p\\_{c}}\\) based on the MLEs of the arm proportions governed by the constraint that \\(\\widetilde{p\\_{d}} - \\widetilde{p\\_{c}} = - s\\_{1}s\\_{2}\\delta\\). These constrained MLE estimates are used in the standard error of the test statistic. The FM test statistic is then,\n\\[Z\\_{FM,d} = \\frac{\\widehat{p\\_{d}} - \\widehat{p\\_{c}} + s\\_{1}s\\_{2}\\delta}{\\sqrt{\\frac{\\widetilde{p\\_{d}}(1 - \\widetilde{p\\_{d}})}{n\\_{d}} + \\frac{\\widetilde{p\\_{c}}(1 - \\widetilde{p\\_{c}})}{n\\_{c}}}}\\]\nSee the PASS documentation[5] or SAS documentation[6] for a complete description of the calculations that go into the FM test. In the SAS documentation, note that the FM test is the same as the Miettinen-Nurminen test without including the \\(\\frac{n}{n - 1}\\) variance correction. The FM test was used rather than the MN test because as δ → 0, the FM test converges to the simple Wald test.\nOnce the test statistic has been resolved, the dichotomous conditional power for the current trial is calculated as follows. For calculating the conditional power for arm 2 compared to the control arm, called arm 1 without loss of generality, let It be the current information amount and IT be the amount of information that the conditional power is being calculated for. Then,\n\\[I\\_{t} = \\left( \\frac{\\widetilde{p\\_{1}}\\left( 1 - \\widetilde{p\\_{1}} \\right)}{n\\_{1t}} + \\frac{\\widetilde{p\\_{2}}\\left( 1 - \\widetilde{p\\_{2}} \\right)}{n\\_{2t}} \\right)^{- 1}\\]\n\\[I\\_{T} = \\left( \\frac{\\widetilde{p\\_{1}}\\left( 1 - \\widetilde{p\\_{1}} \\right)}{n\\_{1T}} + \\frac{\\widetilde{p\\_{2}}\\left( 1 - \\widetilde{p\\_{2}} \\right)}{n\\_{2T}} \\right)^{- 1}\\]\n\\[Z\\_{t} = \\left( \\widehat{p\\_{2}} - \\widehat{p\\_{1}} + s\\_{1}s\\_{2}\\delta \\right)\\*\\sqrt{I\\_{t}}\\]\nwhere δ is the super superiority or non-inferiority margin, and n1t and n2t are current number of completers on the control and active arm, and n1T and n2T are the number of completers that will be on the control and active arm at time that the conditional power is being calculated for. Additionally, if there is no non-inferiority or super superiority margin δ, then all \\(\\widetilde{p\\_{\\*}}\\) values are equal to their corresponding \\(\\widehat{p\\_{\\*}}\\) values.\nFor a one-sided alpha level of α, let z1 − α be the critical value corresponding to α.\nIf high values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{Z\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} + s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{{- Z}\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} - s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\n\n\nCalculation of Dichotomous Conditional Power for a Future Trial\nMost of the calculation quantities for the future trial conditional power are the same as the current trial conditional power. The only difference is that for the future trial conditional power we discard the influence of the current trial test statistic on the final analysis, so It = 0. Then the conditional power calculations become:\nIf high values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} + s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} - s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#facts-6.4-changes-to-n-crm", - "href": "documentation/v71/userguides/crm.html#facts-6.4-changes-to-n-crm", - "title": "FACTS Dose Escalation CRM", - "section": "2.4 FACTS 6.4 Changes to N-CRM", - "text": "2.4 FACTS 6.4 Changes to N-CRM\nIn FACTS 6.4 there were no changes to the Dose Escalation simulators.", + "objectID": "documentation/v71/userguides/core.html#p-values", + "href": "documentation/v71/userguides/core.html#p-values", + "title": "FACTS Core User Guide", + "section": "5.3 P-values", + "text": "5.3 P-values\nA p-value QOI simply allows the user to specify which test type to be used (unadjusted, Bonferroni, Dunnett’s or Trend Test), and how missing data is to be handled (ignored, LOCF or BOCF – if baseline is being simulated). If a control arm is present, P-values are comparisons against the control arm, if there is no control arm present, p-value QOIs are comparisons against a fixed response or fixed rate that is specified at the bottom of the QOI tab (it cannot be set differently for separate QOIs).\nNote that for dichotomous endpoints p-value are calculated using the Test of Proportions, this test statistic asymptotically approaches a normal distribution and at least 5 success and 5 failures should be observed for this to be reasonable.\nThe p-values are calculated including the default frequentist delta that has been specified at the bottom of the screen. They cannot be modified as part of QOI, the value of the delta and nature of the test is the same for all the p-value QOIs.\nIn a TTE design with a predictor the p-values are only calculated for the final event endpoint, not the predictor.\n\n\n5.3.1 P-values when there is no control arm\nIf there is no control arm (not currently an option in Time-to-Event), the p-value delta is instead interpreted as the objective response or response rate to compare to. The option to set the trial type is also disabled (“Superiority” is selected and the “non-inferiority option is greyed out). For a non-inferiority trial comparing to an objective response or response rate simply use the objective rate minus the non-inferiority delta (if a higher response is better) or the objective rate plus the non-inferiority delta (if a lower response is better).\nIt is currently only possible to have one objective rate to compare against.\nThe same objective rate will be used for the target p-value test in the predictive probabilities.\n\n\n\n5.3.2 Fisher-Exact Test\nOn the bottom of the QOI tab, we can specify what statistical test to use when calculating p-values. Options are “Normal approximation” (default) and “Fisher exact test”. “Normal approximation” uses a t-test and should yield similar results to a Chi-Square test without continuity correction, while “Fisher exact test” uses an exact Fisher’s exact test for 2x2 tables.\nIf “Fisher exact test” is chosen as the test type, all p-value QOIs will use a Fisher’s exact test, except for future trial predictive probabilities, which will still use a t-test.\nIf “Fisher exact test” is chosen as the test type, only “Bonferroni” and “Unadjusted” are available as multiplicity corrections and any QOIs previously created using different multiplicity corrections will be deleted.\n“Fisher exact test” is not available for non-inferiority comparisons.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#facts-6.3-changes-to-n-crm", - "href": "documentation/v71/userguides/crm.html#facts-6.3-changes-to-n-crm", - "title": "FACTS Dose Escalation CRM", - "section": "2.5 FACTS 6.3 Changes to N-CRM", - "text": "2.5 FACTS 6.3 Changes to N-CRM\nIn FACTS 6.3 a number of changes were made to improve facilities in N-CRM, or improve the way existing facilities were implemented. These were:\n\nNew run-in options: the existing run-in scheme is available as “simple run-in”, “custom run-in” allows a specific sequence of doses and number of subjects to test at each dose to be specified, “small cohort pre-escalation” allows a run that uses a smaller cohort size but follows the dose escalation rules and over dose control.\nNew “backfill” options in open enrolment. Backfill allows subjects that become available at a time when they can’t be allocated to the current dose (because the maximum number of subjects without final results have already been allocated to the current dose).\nImproved handling of “maximum subjects without final results” in open enrolment. In earlier versions of FACTS this was a “global” maximum, which led to a suboptimal allocation pattern and overly cautious rejection of subjects that became available. The new model applies a maximum “per dose” so that once the trial has escalated to a new dose strength, any subjects without final results on lower doses do not block allocation to the new dose, in addition it is possible to specify two different maximums – one for when a dose has just been escalated to but has not been “cleared” (typically smaller and more cautious), and one when a dose has been cleared but we continue to allocate to it because it is the target dose (typically larger and more confident). This method is such an improvement that we recommend moving any design using open enrolment to this new version of FACTS.\nImproved Ordinal Toxicity model – the way the likelihood is calculated has been improved – reducing the uncertainty in the model fit. Any design using an ordinal model will need to re-calibrate the prior if you move the design to FACTS 6.3. If you have a design already complete, or in execution we recommend you remain using the earlier version of FACTS for that trial.", + "objectID": "documentation/v71/userguides/core.html#target-doses", + "href": "documentation/v71/userguides/core.html#target-doses", + "title": "FACTS Core User Guide", + "section": "5.4 Target Doses", + "text": "5.4 Target Doses\nThe target dose QOIs are Bayesian posterior probabilities based on MCMC sampling of how often each dose meets the specified target criteria. There are 3 types of target specifiable\n\nMax – the dose with the maximum response, this has no parameters to specify, so is available as a pre-defined default QOI.\nMED – a Minimum Effective Dose, the lowest dose that has a response better than an absolute or relative target.\nED – an effective dose, the dose that achieves a specified proportion (quantile) of the maximum improvement in response relative to an absolute value or the performance of a specific treatment arm.\n\n\nA Target dose posterior probability is specified as:\n\nMED or EDq.\nRelative to an absolute value or relative to the response on a Control or the Active Comparator.\nThe delta the MED must be better than, or the quantile of the effective dose.\nIf the endpoint is TTE and the design includes a predictor, then the definition of the QOI includes selecting which endpoint the QOI refers to.\n\nThe QOI will be given a name derived from these details, and alternative simpler name that can be used when accessing the output files from other software such as R.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#facts-6.2-changes-to-n-crm", - "href": "documentation/v71/userguides/crm.html#facts-6.2-changes-to-n-crm", - "title": "FACTS Dose Escalation CRM", - "section": "2.6 FACTS 6.2 Changes to N-CRM", - "text": "2.6 FACTS 6.2 Changes to N-CRM\nIn FACTS 6.2 features available separately in the other FACTS CRM engines (CRM (Toxicity), bCRM & CRM Ordinal) were all incorporated into N-CRM. This allowed these features to be used in conjunction with N-CRM’s target toxicity band methodology, overdose control and open enrollment features, as well as in conjunction with each other for the first time.\nThe new features are:\n\nFrom CRM (Toxicity) the option to specify that the data is coming from ‘two groups’ and for the toxicity experienced in the two groups to be modelled with a joint model [CRM 2 Sample]. This allows a trial where there are two patient populations (such as adults and children) or where there are two versions of the treatment to be simulated.\nFrom bCRM the option to model a second binary efficacy endpoint [bCRM] and the for dose allocation to proceed in two stages – the first to establish an MTD and the second to establish an MED.\nFrom CRM Ordinal the option for the toxicity endpoint to be modelled not as binary endpoint, but one with different categories of toxicity, and with a joint model applied to the different categories [CRM Ordinal]. The endpoint can be to model either 3 or 4 categories of toxicity:\n\ncategory 1 is “no toxicity”,\ncategory 2 is “mild toxicity”,\ncategory 3 is “toxicity”\ncategory 4 (if included) is “severe toxicity”\n\n\nAll decision making is made in terms of the probability of observing a category 3 (or worse) toxicity.", + "objectID": "documentation/v71/userguides/core.html#decision-quantities", + "href": "documentation/v71/userguides/core.html#decision-quantities", + "title": "FACTS Core User Guide", + "section": "5.5 Decision Quantities", + "text": "5.5 Decision Quantities\nThe QOI’s so far have defined values to be calculated across all the doses. For a Success / Futility decision to be taken, as well as the quantity to be tested, it is necessary to specify the treatment arm whose value is to be used. This selection can be by specifying a specific arm, but normally it is specified by using a “Probability of being Target” selection criteria. A simple and common example is “The probability of the response being better than that of the Control of the Treatment arm with the maximum response”:\n\n\nA decision QOI consists of (1) a QOI that has been calculated for each dose, and (2) at Target Dose QOI. The dose with the highest probability of being the target dose is selected and the value of the “per dose” QOI for that dose is the value used in the decision.\nFor example, evaluating a decision QOI that is the combination of\n\nThe probability of being better than Control by 2 points (Pr(θd – θ0 > 2))\nwith the target dose EDq relative to control; Quantile 0.9\n\nis the probability that the response of the ED90 is better than control by 2 points.\nInstead of a Target Dose QOI, it is also possible to specify a specific dose, or to use the terms “Max probability over all doses” and “Min probability over all doses” which mean that the dose with the minimum or maximum value of the per dose QOI is used. This enables:\n\nDecisions QOIs testing specific doses, for example by defining a Posterior probability QOI that compares all doses against the lowest dose, and then a Decision QOI using that posterior probability with the highest dose selected as the target dose it is possible to based decisions on the posterior probability that the highest dose is better than the lowest dose.\nA Decision QOI using “Max …” allows a decision to be based on whether a probability or p-value is greater than a threshold at any dose, or less than a threshold at all doses.\nA Decision QOI using “Min …” allows a decision to be based on whether a probability or p-value is less than a threshold for any dose or greater than a threshold at all doses.\n\nThere is one special case: if the QOI chosen is the Trend Test p-value, then because this is not actually a per-dose value, only one “Target dose” can be selected: “Overall Significance”.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#facts-6.1-changes-to-n-crm", - "href": "documentation/v71/userguides/crm.html#facts-6.1-changes-to-n-crm", - "title": "FACTS Dose Escalation CRM", - "section": "2.7 FACTS 6.1 Changes to N-CRM", - "text": "2.7 FACTS 6.1 Changes to N-CRM\nIn FACTS 6.1 N-CRM has the new feature of ‘design variants’ that allow the user to easily simulate and evaluate an N-CRM design at different sample sizes. This change includes 4 elements:\n\nUnder the ‘Study’ tab the user can now specify the number of design variants, and for each variant the maximum study size in Cohorts.\nOn the simulation tab FACTS will display a copy of each simulation scenario for each variant.\nThe simulation results now include the Ppn of trials that stopped for each stopping reason: stopping because all doses are too toxic (the toxicity estimates exceed the overdose criteria), because a stopping rule was met or because the study cap was reached.\nThere are now a set of cross variant graphs that show trellis plots of the key summary graphs by design variant and scenario.", + "objectID": "documentation/v71/userguides/core.html#standard-evaluation-variables", + "href": "documentation/v71/userguides/core.html#standard-evaluation-variables", + "title": "FACTS Core User Guide", + "section": "5.6 Standard Evaluation Variables", + "text": "5.6 Standard Evaluation Variables\nThese 2 parameters are used across some of the default QOIs and hence specified outside the normal QOI dialog boxes.\n\nThe CSD value\nand whether absolute or relative to the Control arm\n\nthese are used in both the default “Pr(CSD)” and the “MED relative to Control” QOIs. \nNote that the CSD value here is designed to be usually entered as a positive value, as in earlier versions of FACTS. Its sign is automatically adjusted if “lower score means subject improvement” or if the trial is a non-inferiority trial.\nThese adjustments are not made for other user entered QOI, the directions of comparison both for the definition of the probability to be calculated and the comparison of the resulting probability with a threshold are under the user’s control as are whether delta’s are –ve or +ve. This allows the user to define QOI’s in whatever fashion is natural to them and the team.\nWhen there is no custom and practice as to how an endpoint and associated probability are expressed and used, it is recommended that the usual practice should be to create probabilities that are large when they are ‘good’ and low when they are ‘bad’. So tests for success are usually “> threshold” and for futility are “< threshold”. Using this convention whenever it is does not feel unnatural will reduce confusion and the opportunity for mistakes.\n\n5.6.1 The direction of comparison for default QOIs\nNote that as a result of being able to specify whether a higher or lower response represents improvement, and whether the aim is superiority or non-inferiority, the CSD or the NIM will almost always be a positive value. FACTS will automatically determine which direction is appropriate (e.g. if lower values are subject improvement, the engine will realize a CSD will need to be subtracted from the control score before comparing with the estimate of response on a treatment arm).", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#overdose-control", - "href": "documentation/v71/userguides/crm.html#overdose-control", - "title": "FACTS Dose Escalation CRM", - "section": "3.1 Overdose Control", - "text": "3.1 Overdose Control\nOverdose control can be specified on the Study > Toxicity tab. Overdose control specifies a limit on the probability that a dose has a toxicity rate above a certain level. After fitting the Bayesian logistic regression model, all doses for which the posterior probability that their toxicity rate lies above the specified level exceeds the specified limit are ineligible for allocation. Because the Bayesian Logistic regression is monotonic, this means that after every analysis either all doses are permitted for allocation or there will be a dose level above which no dose is permitted for allocation.\n\n\n\n\n\n\nFigure 1: Setting the overdose control limit\n\n\n\nThe overdose control is specified in terms of the “toxicity bands” (concept of allowing ranges for the target toxicity, excess toxicity, unacceptable toxicity and under-dosing explained in more detail in this section) and can either be in terms of the “excess and unacceptable toxicity bands” or just the “unacceptable toxicity band”. The “excess and unacceptable toxicity band” is every toxicity rate above the upper bound of the target band. Care should be taken when setting the permitted threshold for this joint band. If set below 0.5, it will likely exclude doses whose mean expected toxicity rate is within the target band with the risk that this makes the escalation decision in the design too cautious. Initially it might be recommended to just use the “unacceptable band” for specifying the overdose control. This allows an overdose control that is more strict – for example: “exclude any dose where the probability that the toxicity rate is above 0.6, is greater than 20%“. The lower bound for the unacceptable band can be set wherever desired, its only role is in defining this band for overdose control. It is also possible to specify that the limit changes over the course of the trial, allowing the overdose control to become stricter as more information becomes available. For example, one could reduce the permitted probability of a dose having a toxicity rate in the unacceptable band from 50% to 25% in steps of 2.5% after every cohort.", + "objectID": "documentation/v71/userguides/core.html#evaluation-of-bayesian-posterior-estimates", + "href": "documentation/v71/userguides/core.html#evaluation-of-bayesian-posterior-estimates", + "title": "FACTS Core User Guide", + "section": "6.1 Evaluation of Bayesian Posterior Estimates", + "text": "6.1 Evaluation of Bayesian Posterior Estimates\nThe Bayesian model fitted to the data at each update contains a dose response model and usually a longitudinal model. In the absence of a longitudinal model, the posterior is calculated as:\n\\[p(\\omega|Y) \\propto \\prod\\_{i = 1}^{n}{p(y\\_{i}|\\phi)p(\\phi)}\\]\nwhere ϕ is the set of parameters of the selected response model, p(ϕ) is the prior for those parameters, yi is the final response for each subject and n is the number of subjects.\nWith a longitudinal model, this becomes:\n\\[p(\\omega|Y) \\propto \\prod\\_{i = 1}^{n}{p(y\\_{i}|\\phi)p(\\phi)\\prod\\_{i = 1}^{n}{\\prod\\_{j = 1}^{L}{p(y\\_{ij}|\\psi)p(\\psi)}}}\\]\nwhere ψ is the set of parameters of the selected longitudinal model, p(ψ) is the prior for those parameters, y*i**j* is the response for each subject at each visit and L is the number of visits.\nThe posterior is evaluated using MCMC with individual parameters updated by Metropolis Hastings (or Gibbs sampling where possible), using only the yi and y*i**j* data available at the time of the update.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#dose-escalation-rules", - "href": "documentation/v71/userguides/crm.html#dose-escalation-rules", - "title": "FACTS Dose Escalation CRM", - "section": "3.2 Dose Escalation Rules", - "text": "3.2 Dose Escalation Rules\nThe dose escalation could be solely controlled by the overdose control (as originally proposed in (Neuenschwander, Branson, and Gsponer 2008)), however this means that the escalation behavior is very dependent on the interplay between the prior and the observed data. Usually, teams prefer to have a fixed set of rules in place ensuring the escalation behavior is sufficiently cautious. FACTS has an option to just use overdose control or to use a combination of overdose control and a set of fixed escalation rules. In the latter case, the following rules can be set in the Design > Allocation Rule > Allocation tab:\n\n\n\n\n\n\nFigure 2: Dose escalation rules\n\n\n\nWe introduce the notion of whether a dose has been “cleared”. A dose is cleared once we have sufficient data on it (usually, but not necessarily, the results of one cohort, but if the cohort size is small, for example 2 subjects, perhaps more than one cohort will be required). This can be supplemented by a rule that if the observed raw toxicity rate at the dose exceeds a certain limit, then the dose is not counted as cleared (this rule is usually unnecessary if overdose control limits have been set). Once a dose has been cleared, it stays cleared, meaning there is “maximum cleared dose”. The number of dose increments or the factor of dose strength above the current cleared dose that can be allocated to is then specified. For example, with doses of 12.5, 25, 50, 100, 150, 200, 250, we might allow escalation at two dose increments a time. In the figure below, you see the combination of settings used to achieve this behaviour alongside the “Fastest Possible Dose Escalation” plot on the right:\n\n\n\n\n\n\nFigure 3: Escalation by number of dose increments\n\n\n\nAlternatively, we can specify the permitted escalation as a ratio, for example we might allow the dose strength to be at most tripled at each escalation, which, with the example dose strengths, makes the initial escalation more cautious:\n\n\n\n\n\n\nFigure 4: Escalation by dose strength factor\n\n\n\nThe escalation rules can be adjusted so that instead of a single increment rule, there are different increments depending on the dose, or depending on the number of observed toxicities. To modify our earlier example, we can allow escalation by 2 dose levels while no toxicities have been observed, but limit it to only one dose level once one or more toxicities have been observed:\n\n\n\n\n\n\nFigure 5: Escalation increment varying by number of toxicities\n\n\n\nLastly escalation can be relative to the highest cleared dose, or relative to the last dose allocated.\nTo summarize the allocation procedure:\n\nThe current maximum cleared dose is identified.\nThe current data is analyzed using the Bayesian Logistic Regression model.\nThe overdose rules are evaluated and all doses exceeding the overdose control limit are excluded from this escalation selection.\nFrom the remaining doses, the dose best meeting the target MTD or target toxicity interval objective based on the model is selected as the “target dose” (TD).\nIf the TD is at or below the current maximum cleared dose, the next cohort is allocated to the TD.\nIf the TD is within the escalation rules of the current maximum cleared dose, the next cohort is allocated to the TD.\nOtherwise, the next cohort is allocated to the highest dose above the current maximum cleared dose as allowed by the escalation rules.", + "objectID": "documentation/v71/userguides/core.html#continuous-dichotomous-and-log-odds", + "href": "documentation/v71/userguides/core.html#continuous-dichotomous-and-log-odds", + "title": "FACTS Core User Guide", + "section": "7.1 Continuous, Dichotomous and Log-Odds", + "text": "7.1 Continuous, Dichotomous and Log-Odds\nWith the exception of two dose response models specific to a dichotomous endpoint, the same dose response modeling facilities are available for all endpoints.\nLet there be D total doses including the control arm if it exists. For any endpoint, the estimate of dose response model is called θd for a dose d ∈ {1, …, D}.\n\nIn the continuous case the individual response/change from baseline (if it exists) Yi of the i*t**h subject allocated to dose di is modeled: Yi ∼ N(θdi, σ2). The variance σ*2 has an inverse-gamma prior.\nIn the dichotomous case the final endpoint of the i*th subject who has been allocated to dose di is modeled: Yi ∼ Bernoull**i(Pdi) where Pdi is the probability of response for a subject on dose di. The probability Pd is modelled on the logit scale, so \\(P\\_{d} = \\frac{e^{\\theta\\_{d}}}{1 + e^{\\theta\\_{d}}}\\), and thus θd* is the log-odds ratio: \\(\\theta\\_{d} = ln\\left( \\frac{P\\_{d}}{1 - P\\_{d}} \\right)\\),\nIn the time-to-event case the time to a subject’s response, Yi is modeled as piece-wise exponentially distributed with hazard rates, λs for pieces s ∈ {1, …S}. So, Yi ∼ PWExp({λ1, …, λS}) for a subject on the control arm, and Yi ∼ PWExp({λ1eθd, …, λSeθd}) for non-control doses. Then, θd is the log-hazard ratio \\(\\left( \\ln\\left( \\frac{\\lambda\\_{s}e^{\\theta\\_{d}}}{\\lambda\\_{s}} \\right) = \\ln\\left( e^{\\theta\\_{d}} \\right) = \\theta\\_{d} \\right)\\) averaged over the observation time segments. This formulation implies a proportional treatment effect across the pieces of the piece-wise exponential.\n\nEach dose response model is parameterized in terms of θd, but each endpoint models this parameter on a different scale. The dichotomous dose response models are on the log-odds scale, and the time-to-event endpoint models are on the log hazard ratio. When specifying a prior distribution for a continuous endpoint dose response model the expected data mean and variance determine which priors should be considered non-informative. When estimating a probability in the dichotomous case, using a prior with standard deviation above, say, 10 leads to a diffuse distribution on the log-odds scale, but results in a prior distribution on the probability scale that is heavily peaked at 0 and 1. This can lead to undesirable model results and decisions being made in small sample size situations, and numerical instability in extreme cases. Similarly on the time-to-event scale, the prior put on the log-hazard ratio θd is exponentiated before being multiplied by the hazard rate, so diffuse priors on the log-hazard can have unexpected modelled results. Again, time-to-event θd priors that have standard deviations less than about 10 are generally acceptably diffuse for most situations while avoiding edge case curiosities.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#initial-run-in", - "href": "documentation/v71/userguides/crm.html#initial-run-in", - "title": "FACTS Dose Escalation CRM", - "section": "3.3 Initial Run-in", - "text": "3.3 Initial Run-in\nThe purpose of defining a run-in is to define a fixed allocation behavior to be followed up to the first toxicity being observed. The specified number of subjects to allocate to each dose in the run-in and which doses to test are specified. This scheme is followed until a toxicity is observed or we reach the end of this fixed scheme.\nThree forms of run-in specification are available:\n\nSimple: allocates a small cohort to every defined dose in ascending order (unless fine grain doses - see this section – have been specified, in which case the escalation rules are followed).\nCustom: allocates a defined number of subjects (possibly varying by dose) to selected doses in ascending order.\nSmall cohort pre-escalation: allocates a small cohort, but follows the escalation rules assuming just a single small cohort is required to clear a dose.\n\nAll run-in schemes can be modified in a number of ways:\n\nSpecifying a maximum dose at which the run-in stops if no toxicities are observed until that dose.\nIf ordinal toxicities are being simulated, the run-in may should at the first observed category 2 toxicity (rather than a category 3 toxicity)\nWhether the subjects used in the run-in should be counted towards the trial sample size or not.\nWhen a toxicity is observed the standard behavior is to allocate to the minimum of: the last dose tested in the run-in, the current TD or the highest dose that can be allocated to by the overdose rules. This can be replaced by expanding the allocation on the current dose to make it a full cohort as specified in Study > Study Info tab (this option is particularly useful in conjunction with stopping for a category 2 toxicity).", + "objectID": "documentation/v71/userguides/core.html#descriptions-of-dose-response-models", + "href": "documentation/v71/userguides/core.html#descriptions-of-dose-response-models", + "title": "FACTS Core User Guide", + "section": "7.2 Descriptions of Dose Response Models", + "text": "7.2 Descriptions of Dose Response Models\nThe Dose Response section of the Design tab allows the user to specify how to analyze the relationship between dose/treatment arm and the final response and hence estimate the values θd. The interpretation of θd depends on the nature of the endpoint:\n\nWhere the response is continuous, θd is the estimate of the mean response/change from baseline on treatment arm d, and the common inter-subject variance of the response σ2, is also estimated.\nWhere the response is dichotomous, θd is the estimate of the log-odds of the probability of observing a response on the treatment arm d.\nWhere the response is time-to-event, θd is the estimate of the log hazard ratio compared to the control arm on the treatment arm d.\n\nExcept where the endpoint is time to event, the response on the control arm, θ0, is estimated and can be included in the dose response model or modeled separately. When the endpoint is time-to-event, the response rate on the control arm, λ is estimated and θd for d ∈ {1, 2, …, D} is the log hazard of the response rate of each treatment arm compared to the control arm, so θ0 ≡ 0.\nSome, but not all, of the dose response models use the effective dose strength, νd, to model the dose response θd. The effective dose strength is specified on the Study > Treatment Arms tab. It is always fixed at 0 for the control arm (ν0 = 0).\n\n7.2.1 Independent Dose Model\nThe “Independent Dose Model” providing a simple pair-wise comparison between the study drug arms and the control arm and/or the active comparator arm. The doses are modelled as independent and normally distributed with a prior of:\nθd ∼ N(μd, νd2)\nWhere μd and vd2 are specified in FACTS and can be the same or vary across arms.\nThis model is useful:\n\nWhen there is only one or two experimental arms\nWhen the study drug arms don’t differ by dose but in other ways, so there is no ordered sequence of treatments – e.g. each arm is the study drug in combination with a different additional drug.\nFor simulating simple trial designs\nFor simulating a ‘conventional’ or ‘strawman’ design to compare more complex designs against\n\nOtherwise for trials with multiple related arms that differ by dose, it is usually more efficient to use a dose-response model.\n\n\n7.2.2 Independent Beta-Binomial Model (Dichotomous Only)\nThis is a “no model” option similar to the above, but only available for the Dichotomous endpoint. Unlike any other dose response model, this model uses the beta distribution to model the probability of response directly rather than fitting a model to the log-odds of the probability.\nThe final endpoint response Yi is modeled as:\nYi ∼ Bernoulli(Pd)\nwhere Pd is the probability that a patient is a response at the final endpoint for subjects randomized to dose d. With posterior\nPd ∼ Beta(αd + respondersd,   βd + non_*responder**sd*)\nWhere αd, βd are the priors for the arm d, respondersd is the number of responders on arm d and non_respondersd is the number of non-responders on arm d.\nThis model has the advantages of an easier to understand prior, and better estimation of Pd when the number of responders and non-responders is small (either is < 5) compared to the log-odds model. As it’s an independent model it is well suited to analyzing single arm, two arm or three arm trials, or trials where the experimental arms are unrelated, and so there is no basis on which to borrow information between them. With trials with multiple arms of the same treatment at different doses it is usually more advantageous to fit a dose response model.\n\n\n7.2.3 Simple NDLM\nThe Normal Dynamic Linear Model (NDLM) estimates the final endpoint as a smoothed curve across doses included in the model. Doses are tied directly to their nearest neighbor, and the prior expectation for a dose is that it is equal to its neighboring doses, tending to a constant dose response across doses in the absence of data. The model is defined as follows:\nLet doses d = d′, …, D be doses in the dose response model and θd be the estimated dose response for dose d. The initial dose d′ = 1 if there is no control or control is included in the dose response model, and d′ = 2 if the control arm is modelled separately.\nThe dose response of the first dose, d′, has a prior of:\nθd′ ∼ N(μd′, τd′2)\nwhere μd′ and τd′2 are specified directly in FACTS. Subsequent dose response estimates θd′ + 1, …, θD have priors centered at the previous dose response with variances based on the distance between the dose d strength and the dose d − 1 strength. Specifically,\nθd ∼ N(θd − 1, τd − 12) for d = d′ + 1, …, D\nwhere for dose strengths vd and vd − 1, td − 12 is defined as\nτd − 12 = τ2(vd − vd − 1)\nThe prior distribution for the “drift” parameter, which controls the amount of smoothing is:\n\\[\\tau^{2}\\sim IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nwhere τμ and τn are specified in the Dose Response tab in FACTS under Model Parameters.\nIn the continuous case the residual error around the estimated dose response is\n\\[\\sigma^{2}\\sim IG\\left( \\frac{\\sigma\\_{n}}{2},\\frac{\\sigma\\_{\\mu}^{2}\\sigma\\_{n}}{2} \\right)\\]\nwhere σμ and σn are specified on the Dose Response tab in FACTS under Error Parameters.\nThe Simple NDLM is generally a good model to use when the shape of the likely dose response is unknown, but we would like to borrow information between a dose and its neighboring doses. No monotonicity or pre-determined shape is enforced by the Simple NDLM. The variance in dose response from dose to dose is updated based on the observed data, but as the number of doses in a trial is typically small, a moderately informative prior is often used.\nIn a ‘null’ scenario where the response on all the doses is the same as control, the simple NDLM reduces type-1 error. The estimate of τ2 tends towards zero and the estimate of the dose response tends to a flat line. The smoothing of the estimates of the response reduces the random fluctuations in the estimates from dose to dose and is a very effective counter to the problem of type-1 error inflation due to the multiplicity of doses being tested. A small prior for the mean value of τ will accentuate this effect. The price to be paid for this benefit is a tendency to underestimate large changes in response or where there is a peak in the response. This over-smoothing can reduce power. A prior for the mean of τ centered at large values will minimize over-smoothing, and a very large prior would simply remove any smoothing effect at all. A standard prior for the mean of τ would be the expected average change in response from dose to dose, scaled to take into account the differences in the specified effective dose strengths.\nUsually, the choice of prior for τ2 is tuned based on simulation results, trading off reducing type-1 error in the null case against loss of power and reduced estimate of maximum response in the effective scenario with the largest jump in response or steepest peak.\nAside: When using the NDLM model or any of its alternatives (2nd order or Monotonic NDLM), and including doses in a design that receive no subject allocation (ie. Allocation ratio set to 0), some important characteristics of the model should be considered in the interpretation of results. First, the NDLM model “borrows” information from neighbouring doses, and therefore including unallocated intermediate doses will increase uncertainty in the fitted response. Information must “pass through” these intermediate doses, and uncertainty should be expected to increase as the number of intermediate unallocated doses between two allocated doses increases. Secondly, the NDLM model estimates the response at unallocated doses, but without subject data at these doses the uncertainty in the estimate can be considerably larger than doses with subject data. This high degree of uncertainty can lead to a vestigial probability that an unallocated dose is the target dose (Pr(EDx), Pr(MED), Pr(Max)) even though the mean response estimate and probabilities at neighbouring doses with subject data would not suggest this to be the case.\n\n\n7.2.4 Monotonic NDLM\nThe Monotonic NDLM endpoint model is similar to the NDLM in the sense that it smooths dose response estimates using neighboring doses, but is constrained to be either monotonically increasing or monotonically decreasing across doses. The direction of monotonicity depends on the value specified in the “Monotonic:” selection in the Model Parameters section of the Monotonic NDLM Dose Response page.\nThe use of this model is generally limited to endpoints where a strong presumption of increasing/decreasing response with dose is reasonable – such as a biomarker or a toxicity endpoint.\nLet doses d = d′, …, D be doses in the dose response model and θd be the estimated dose response for dose d. The initial dose d′ = 1 if there is no control or control is included in the dose response model, and d′ = 2 if the control arm is modelled separately. The following model is the monotonically positive NDLM:\nθd′ ∼ N(μd′, τd′2)\nand\nθd ∼ N+(θd − 1, τd − 12) for d = d′, …, D,\nWhere τd − 12 is defined as in the NDLM, and X ∼ N+(μ, σ2) refers to a positive truncated normal distribution with density function:\n\\(f\\_{X}(x) = \\frac{1 - \\Phi\\left( - \\frac{\\mu}{\\sigma} \\right)}{\\sqrt{2\\pi}\\sigma}\\exp\\left\\\\ - \\frac{1}{2\\sigma^{2}}(x - \\mu)^{2} \\right\\\\\\) for x > 0.\nThe result of this dose-response model is that the curve is monotonically increasing, in that θd > θd − 1.\nThe monotonically decreasing NDLM is similar except:\nθd ∼ N−(θd − 1, τd − 12) for d = d′, …, D,\nWhere X ∼ N−(μ, σ2) refers to a negative truncated normal distribution:\n\\(f\\_{X}(x) = \\frac{\\Phi\\left( - \\frac{\\mu}{\\sigma} \\right)}{\\sqrt{2\\pi}\\sigma}\\exp\\left\\\\ - \\frac{1}{2\\sigma^{2}}(x - \\mu)^{2} \\right\\\\\\) for x < 0.\nThe result of this dose-response model is that the curve is monotonically decreasing, in that θd < θd − 1.\n\n\n7.2.5 Second Order NDLM\nThe second order NDLM described in this section is the version utilized in FACTSTM version 4.0 and later. The model labelled “Second Order NDLM” versions before 4.0 is now maintained as the model labelled “Legacy 2nd Order NDLM.” The second order NDLM serves as a “smoother” similar to the NDLM, however it tends to smooth toward a linear fit with a slope (the NDLM itself tends to shrink each dose’s fit toward its neighbours, while the second order NDLM prefers any trend in the neighbours).\nLet doses d = d′, …, D be doses in the dose response model and θd be the estimated dose response for dose d. The initial dose d′ = 1 if there is no control arm or control is included in the dose response model, and d′ = 2 if the control arm is modelled separately. The initial dose d′ is modelled:\nθd′ ∼ N(μ0, τ02)\nWhere μ0 and τ02 are specified directly in FACTS.\nIn the case of TTE, the initial dose d′ is the control arm, and has a θd′ = 0 by definition, so no prior distribution is needed.\nThe prior distribution for the dose response for the dose directly after the initial dose is specified on the difference between the d′ and d′ + 1 level doses:\nθd′ + 1 − θd′ ∼ N(μ1, τ12)\nSuccessive doses are then modelled based on differences in slope between the dose and the two doses below them. Let:\n\\[\\theta\\_{d} = \\theta\\_{d - 1} + \\Delta\\_{d}\\zeta\\_{d} + \\frac{\\Delta\\_{d}}{\\Delta\\_{d - 1}}\\left( \\theta\\_{d - 1} - \\theta\\_{d - 2} \\right)\\]\nfor doses d = d′ + 2, …, D, where Δd = νd − νd − 1 and Δd − 1 = νd − 1 − νd − 2. The priors for the dose response smoothing terms ζd are:\nζd ∼ N(0, τ22)\nThe smoothing is determined by the parameter τ2. Small values of τ2 lead to more smoothing, while large values of τ2 lead to little information sharing between doses (above dose 1). Note that “small” and “large” is dependent on the scale of the doses. The prior on the smoothing parameter is:\n\\[\\tau\\_{2}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nwhere τμ is a central value for τ2, and τn is the prior weight.\nNote that that in this formulation, τ22 can be thought of as the deviation from linearity. The linear scaling of deviations thus leads to a conditional variance that scales as the square of the dose difference:\nVar[θd|θd − 1, θd − 2]= τ22•(νd − νd − 1)2\nThe Second Order NDLM, like the Simple NDLM, is generally a good model to use when the shape of the likely dose response is unknown, but we would like to borrow information between a dose and its neighboring doses. No monotonicity or pre-determined shape is enforced by the Second Order NDLM. The variance in dose response from dose to dose is updated based on the observed data, but as the number of doses in a trial is typically small, a moderately informative prior is often used.\nIn a ‘null’ scenario where the response on all the doses is the same as control, like the simple NDLM, the second order NDLM reduces type-1 error. As the estimate of τ2 tends to zero and the estimate of the dose response tends to a line (with non-zero slope if appropriate).\nThe second order NDLM has more power than the Simple NDLM when the dose response is smooth, but will tend to underestimate by more than the Simple NDLM if there are marked peaks or steps in the response. Because it borrows from two doses, it is better at estimating a response for a dose where there is no data than the simple NDLM can, and can be used with burn-in’s where not all doses have been allocated to, but doesn’t cope well if there are consecutive doses where there is no data.\nHowever, unlike the simple NDLMs where the variance structure is preserved if doses are added to or dropped from the design, this is not true for the 2nd order NLDM. Thus, if using the 2nd order NDLM, and the doses that are available to the model are changed, then the parameters for the prior for τ22 may need to be re-visited.\nThe simple NDLM is likely to be preferred where there are fewer doses (4-5), and the second order NDLM is often preferred when there are 7 or more (it will depend on the expected smoothness of the response – the smoother it is the more useful the second order NDLM will be).\nAs with the simple NDLM, the choice of prior for τ2 can be tuned based on simulation results: balancing having a smaller prior that limits type-1 error in the null case, against having a larger prior that yields more power and better estimate of maximum response in the effective scenarios with the large jumps in response or pronounced peaks.\n\n\n7.2.6 3-Parameter Logistic\nThe 3-parameter logistic dose response model estimates efficacy as a smooth curve using an intuitive parameterization. The dose response for a dose d with effective dose strength vd is:\n\\[\\theta\\_{d} = a\\_{1} + \\frac{a\\_{2}v\\_{d}}{v\\_{d} + a\\_{3}}\\]\nWhere the a parameters have the following description:\na1 is the estimated dose response for a dose of strength 0\n\na2 is the estimated change in dose response for a dose with strength ∞ when compared to a dose of strength 0.\na3 is the estimated ED50, the dose that has 50% of the dose response maximum (a2)\n\nThe shape of the 3-parameter logistic curve can vary wildly based on the parameter values, but always starts at a1 at dose strength 0 and monotonically increases to a1 + a2 as the effective dose strength goes to infinity.\nThe following independent prior distributions are assumed:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\nIn the continuous case, the prior distribution for the error term in the 3-Parameter Logistic is Inverse Gamma:\n\\[\\sigma^{2}\\sim IG\\left( \\frac{\\sigma\\_{n}}{2},\\frac{\\sigma\\_{\\mu}^{2}\\sigma\\_{n}}{2} \\right)\\]\nAn advantage of the 3-Parameter Logistic model is that it is has a small number of parameters that have defined, intuitive interpretations. Since there are few parameters it’s generally easy to estimate the parameters even on small amounts of data. Because of the limited flexibility of the logistic curve, the 3-parameter logistic model should only be used when there is evidence that it is appropriate. See the Hierarchical Logistic and Sigmoid (Emax) models for dose response models with a similar pattern, but slightly more flexibility in shape.\n\n\n7.2.7 Hierarchical Logistic\nThe hierarchical logistic model is an extension of the 3-parameter logistic with the form:\n\\[\\theta\\_{d} = a\\_{1} + \\frac{a\\_{2}v\\_{d}}{v\\_{d} + a\\_{3}} + \\zeta\\_{d}\\]\nwhere ζd is a random intercept term that modifies a1 differently for each dose under the constraint that all ζd must sum to 0.\nThe additional term ζd is a per dose ‘off-curve’ effect. It allows for a secondary non-parametric dose effect over and above the logistic model. It has been used in circumstances in which there is actually some falling away of effect at the highest dose. This is an example mean fit from 100 simulations. The model fit and error bars are in green, and the true dose responses are shown by the black line.\n\nζd is modelled as:\nζd ∼ N(0, a42)\nconditioned that\n\\[\\sum\\_{d}^{}\\zeta\\_{d} = 0\\]\nAnd a42 has an inverse gamma prior:\n\\[a\\_{4}^{2}\\sim IG\\left( \\frac{\\Lambda\\_{n}}{2},\\frac{\\Lambda\\_{\\mu}^{2}\\Lambda\\_{n}}{2} \\right)\\]\nThe following independent prior distributions are assumed:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\nA typical recommended value for the center of the prior distribution of α4 is the largest expected likely deviation in true response from the underlying logistic with a weight of 1. The effect of this prior is then checked through simulation of a range of plausible dose response profiles, with a range of designs to check the sensitivity of the final estimate of response to this prior.\nIn this model, compared to the ‘plain’ 3-parameter logistic above, it is important that the true ED50 lies within the expected dose range, and that the prior for the ED50, a3, has the majority of its probability mass in the available dose range, for example if the range of the effective dose strengths is from 0 to νD, then a typical ‘weakly informative’ prior for a3 would be:\n\\[a\\_{3}\\\\\\sim\\\\N^{+}\\left( \\frac{\\nu\\_{D}}{2},\\left( \\frac{\\nu\\_{D}}{2} \\right)^{2} \\right)\\]\nUsing a weaker prior, such as: N+(νD, (νD)2), leads to a more linear fit, for instance with just this change to the prior for a3 the average of the estimated of the mean response change from the graph above, to:\n\n\n\n7.2.8 Sigmoid Model\nA sigmoid model (Emax model) provides a coherent parameterization of the dose response trend similar to the 3-parameter logistic, but with one extra shape parameter, a4.\nThe model formula is:\n\\[\\theta\\_{d} = a\\_{1} + \\frac{(a\\_{2} - a\\_{1})v\\_{d}^{a\\_{4}}}{{a\\_{3}}^{a\\_{4}} + v\\_{d}^{a\\_{4}}}\\]\nThe interpretation of the four parameters is:\na1 is the estimated dose response for a dose of strength 0\n\na2 is the estimated dose response for a dose of strength ∞ (slight difference from Logistic models)\na3 is the estimated ED50, the dose that has 50% of the dose response maximum attainable effect (a2 − a1)\na4 controls the slope of the dose response model at the ED50. A larger value of a4 corresponds to a steeper slope. A value of a4 = 1 makes the Sigmoid model equivalent to a Three Parameter Logistic model with a2 equal to a1 + a2 from the Sigmoid model. A value of a4 approaching 0 corresponds to a dose response model that is nearly flat at \\(\\frac{a\\_{1} + a\\_{2}}{2}\\). By differentiation, it can be seen that the slope where the effective dose νd = a3 is \\((a\\_{2} - a\\_{1})\\frac{a\\_{4}}{4a\\_{3}}\\).\n\nThe following independent prior distributions are assumed:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\na4 ∼ N+(Λ4, λ42)\nThe advantage of the model is that it is considerably more flexible than the logistic, but still more efficient to estimate than an NDLM. This model (if applicable) is ideal if the target is an Effective Dose (ED) such as an ED90. Estimating an ED requires estimating the response on control, the maximum response, and the gradient which is requires a lot of data to do well if using no model or a smoothing model such as one of the NDLMs. With the 4-parameter sigmoid model (or 3-parameter logistic – but that has a more limited applicability due to being significantly less flexible in shape), it’s usually not an issue to estimate the EDx well.\nThe caveats to using this model are:\n\nWhilst being much more flexible than the logistic, it still has model assumptions, in particular monotonicity, that must be met for this to be a reasonable model to be used.\nThe curve is only well estimated if the true ED50 lies within the doses tested.\nLike the hierarchical logistic model above, the prior for a3 should be weakly informative, with the majority of its probability mass in the available dose range. So similarly, if the range of the effective dose strengths is from 0 to νD then a typical ‘weakly informative’ prior for α3 would be:\n\n\n\\[a\\_{3}\\\\\\sim\\\\N^{+}\\left( \\frac{\\nu\\_{D}}{2},\\left( \\frac{\\nu\\_{D}}{2} \\right)^{2} \\right)\\]\n\n\n\n\n7.2.9 U-Shaped Model\nThe U-shaped model when the allows for an initial increase (decrease) in the dose response with dose, followed by a levelling out of the mean, then a decrease (increase). Whether the U-Shaped model increases then decreases or decreases then increases is specified by the user on the Dose Response tab. An example curve for this model is given in the figure below.\nThe dose-response curve can be characterized in four different regions of doses. For the first region, which contains the lowest doses, 0 < νd < pmin, the dose-response curve is increasing (decreasing):\n\\[\\theta\\_{d} = \\theta\\_{0} + S \\bullet \\delta \\bullet \\left( \\frac{\\nu\\_{d}}{p\\_{\\min}} \\right)^{\\alpha}\\]\nThe next region is the plateau, where the dose-response curve is constant. For pmin < νd < pmin + pwidth:\nθd = θ0 + S • δ\nFor the third region, the dose-response curve is decreasing (increasing). For pmin + pwidth < νd < pmin + pwidth + wwidth,\n\\[\\theta\\_{d} = \\theta\\_{0} + S \\bullet \\delta \\bullet \\left( 1 - \\frac{\\nu\\_{d} - \\left( p\\_{\\min} + p\\_{width} \\right)}{w\\_{width}} \\right)^{\\beta}\\]\nFor the final region, the dose-response curve is again constant, at the same level as the zero-dose. For νd > pmin + pwidth + wwidth,\nθd = θ0\nThe parameters of the model are described below:\n\nS is 1 or -1, as determined by the Model is increasing/decreasing radio buttons. S=1 if Model is Increasing is selected, indicating that the model starts increasing at low doses.\nθ0 represents the zero-strength dose response:\n\n\nθ0 ∼ N(μ0, σ02)\n\n\nδ represents the maximal change in response from the zero-strength dose. It is restricted to be positive:\n\n\nδ ∼ N+(μδ, σδ2)\n\n\npmin represents the lowest dose at which the maximal change in response from the zero-strength is achieved. It is restricted to be positive:\n\n\npmin ∼ N+(μmin, σmin2)\n\n\npwidth represents the width of the plateau – the region where all doses achieve maximal change in response from the zero-strength dose. It is restricted to be positive:\n\n\npwidth ∼ N+(μwidth, σwidth2)\n\n\nwwidth represents the width of the region for doses beyond the plateau, where response is returning to the zero-strength dose level. It is restricted to be positive:\n\n\nwwidth ∼ N+(μw, σw2)\n\n\nα determines the rate of change of the dose response curve for doses below the plateau. Values less than 1 indicate a rapid initial change from baseline, with slower change as the plateau is reached. Values greater than 1 indicate a slow initial change from baseline, with more rapid change as the plateau is reached. To help avoid identifiability issues, α is restricted to be between 10-1 and 101.\n\n\nα ∼ *L**N*(μα, σα*2)\n\nwhere *L**N** represents the lognormal distribution, with the truncation constraints at 10-1 and 101.\n\nβ determines the rate of change of the dose response curve for doses beyond the plateau. Values less than 1 indicate a slow initial change from the plateau level, with more rapid change subsequently. Values greater than 1 indicate a rapid initial change from the plateau level, with slower change subsequently. To help avoid identifiability issues, β is restricted to be between 10-1 and 101:\n\n\nβ ∼ *L**N*(μβ, σβ*2)\n\nThe U-shaped model has seven free parameters, and thus it is inadvisable to use such a model for dose-finding trial designs that contain only a few dose levels. When a small number of doses are available, it may help to constrain the values of α and β by utilizing small standard deviations in the priors.\n\n\n\n7.2.10 Plateau Model\nThe plateau model is a special case of the U-shaped model, in which pwidth = ∞. That is, there is no return to baseline for high doses. This model thus eliminates three parameters, since pwidth, wwidth, and β are not used. See the figure below to see an example dose response model for the plateau model that mimics the beginning of the U-Shaped model above.\n\n\n\n7.2.11 3 Parameter Exp Logistic (Dichotomous Only)\nThe 3-parameter exponential logistic model has the following structure:\nθd = a1 + a2 * νda3\nWhere νd is the effective dose strength of dose d. This is a logistic model for the dichotomous endpoint because θd is the log odds ratio of the probability of the response, Pd at dose d.\nThe exponent parameter α3 allows the change in slope at the lower end of the curve to be asymmetric in comparison to the change in curve at the upper end of the curve.\nThe priors for the parameters are:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\nThe interpretations of the parameters defining this model are:\na1 is the dose response for a dose with strength 0\na2 is the slope associated with the exponentiated dose strength\na3 is a shape parameter modifying the effective dose strength through exponentiation.\nThe figure below shows an example of two different exp3-paramtere exponential logistic model fits. Notably, the fit showing in green has an a3 parameter greater than 1, which leads to faster increases of the sigmoid model as the effective dose strength increases.\n\n\n\n7.2.12 Hierarchical Model\nLike the Independent Dose Model, the hierarchical model treats the arms as if they are an unordered set of treatments, but unlike the Independent Dose Model the Hierarchical Model shares information between doses included in the model. The hierarchical model is a way of encouraging the estimates of arm responses to be similar, and the degree of this encouragement can be controlled using parameters of the prior distribution. The hierarchical model assumes that the arm parameters are drawn from the same normal distribution:\nθd ∼ N(μ, τ2)\nWhere d is the set of doses included in the model. The prior distributions for μ and τ2 are\nμ ∼ N(Λμ, λμ2)\nand\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nwhere τμ is a central value for τ, and τn is the prior weight. τ2 governs the amount of information sharing between doses in the model. The estimates of the dose parameters can be encouraged to be close together by choosing a small value for τμ and a large value for τn.\nThe control arm can be included in the hierarchical model, if it is desired to encourage the experimental arms to be similar to the control arm, or excluded from it, if the experimental arms are encouraged to be similar to each other but not necessarily to the control arm. The exception is with time-to-event data, when the control arm must be excluded from the hierarchical model.\n\n\n7.2.13 Linear Model\nThe linear model uses a strong assumption of exact linearity between the responses and the dose strengths. (For dichotomous models, the linearity is on the log-odds scale, and the linearity is on the log hazard ratio scale for TTE models.) The model is\nθd = α + *β**νd*\nfor all doses d in the model. Both α and β are given normal prior distributions:\nα ∼ N(Λα, λα2)\nβ ∼ N(Λβ, λβ2)\nThe linear model is appropriate when there is strong scientific knowledge that the shape of the response curve should be linear as a function of dose strength. Note that if an arm has a dose strength between two other arms in the model, its response will always be estimated to be between the responses of those two arms. As a result, the linear model may not be appropriate in combination with certain decision quantities such as Pr(Max), because some doses are guaranteed to have probability zero of being the best arm. If the control arm is included in the linear model and it has the smallest dose value, then all experimental arms will always have exactly the same probability of being better than control.\nWe recommend creating scenarios where the true parameters deviate from linearity and simulating them to test the robustness of a design based on the linear model.\nFor dichotomous models, the linear model replaces the 2-parameter logistic model available in FACTS versions before 6.4. The two models are identical.\n\n\n7.2.14 Hierarchical Linear Model\nA more flexible version of the linear model is the hierarchical linear model. This model encourages the arm responses to have a linear-like shape, but also includes a term allowing parameters to deviate from linearity when appropriate. The arm parameters satisfy the relationship\nθd = α + *β**νd + ζd*\nwhere the α and β parameters are as in the linear model, with prior distributions\nα ∼ N(Λα, λα2)\nβ ∼ N(Λβ, λβ2),\nand the ζd parameters are the deviations from linearity. These deviations are assumed to have a normal distribution constrained so that their average value is zero:\nζd ∼ N(0, τ2) with ∑ζd = 0.\nThe prior distribution for τ2 is\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nIf τ2 is small, which can be encouraged by choosing τμ to be small and τn to be large, then the dose parameter estimates will lie close to a line.\nThe hierarchical linear model is a good choice when, for example, one expects a linear relationship between the dose strengths and the response but one is not prepared to assume exact linearity. It can also be a good way of encouraging, but not requiring, monotonicity in the response.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#two-groups", - "href": "documentation/v71/userguides/crm.html#two-groups", - "title": "FACTS Dose Escalation CRM", - "section": "3.4 Two Groups", - "text": "3.4 Two Groups\nFACTS has the option to model the subjects in the trial as belonging to two different groups, these can be either:\n\nTwo groups distinguished by a baseline property of the subjects, for example adults and paediatrics.\nTwo groups separated by a difference in treatment (and selected randomly), for example the study drug alone or in combination with an additional drug.\n\nThere are options for when group 2 starts enrolling:\n\nThey can be recruited sequentially – group 1 then group 2.\nThey can be recruited in parallel\nThe second group can be started when the allocation to the first group reaches a particular dose\nThe second group can be started when the number of subjects allocated to group 1 reaches a particular threshold.\n\nA joint model is fitted to the two groups.\nThe first group is modeled:\n\\[\nlogit(p_{1j}) = \\alpha + \\beta \\hat{x}_j\n\\]\nThe second group is modeled:\n\\[\nlogit(p_{2j}) = (\\alpha + a) + (\\beta + b) \\hat{x}_j\n\\] With separate priors and some optional constraints on \\(a\\) and \\(b\\). Dose escalation and stopping are judged independently for the two groups.", + "objectID": "documentation/v71/userguides/core.html#d-treatment-dose-response-models", + "href": "documentation/v71/userguides/core.html#d-treatment-dose-response-models", + "title": "FACTS Core User Guide", + "section": "7.3 2D Treatment Dose Response Models", + "text": "7.3 2D Treatment Dose Response Models\nIf on the Study > Treatment Arms tab, the “Use 2D treatment arm model” option has been checked, the user may either use any of the 1D Dose Response options described above, or may use a dose response model specifically modelling the two dosing dimensions.\nIf using one of the 1D dose response models, the effective dose strength νd is as specified by the user on the “Select doses to be used in the trial” tab. These calculated dose levels are forced to be distinct values, and this results in a 1D ordering of the combinations.\nThere are also three 2D Dose Response models that can be used:\n\n2D Continuous Factorial Model\n2D Discrete Factorial model\n2D NDLM\n\nThese are described in the next sections.\nThe 2D dose response models work with a slightly different notation to accommodate that treatments are defined as the combination of two factors. Rather than θi being the estimated mean of the dose response estimate for dose i, the estimated dose response for the treatment created from row factor level r and column factor level c is denoted θrc. Yrc denotes the mean of the observed data in the cell.\nIn the continuous case, the likelihood for the data is,\nYrc ∼ N(θrc, σ2)\n\\[\\sigma^{2}\\\\\\sim\\\\IG\\left( \\frac{\\sigma\\_{n}}{2},\\frac{\\sigma\\_{\\mu}^{2}\\sigma\\_{n}}{2} \\right)\\]\nWhere the form of θ*r**c* varies based on dose response model selection.\nSimilarly, in the dichotomous case,\nYrc ∼ Bernoulli(Prc)\n\\[P\\_{rc} = \\\\\\frac{e^{\\theta\\_{rc}}}{1 + e^{\\theta\\_{rc}}}\\]\n\n7.3.1 2D Continuous Factorial Model\nThe 2D Continuous Factorial Model fits a regression on the dose response that uses the numeric dose strength as a continuous valued covariate. The dose response (with ηr and ζc denoting dose strength of the row level and column level, respectively) is modelled as:\nθ*r**c = α0 + α1ζc + α2ηr + α3ζcηr*\nWith priors\nα0 ∼ N(μ0, σ02)\nα1 ∼ N(μ1, σ12)\nα2 ∼ N(μ2, σ22)\nα3 ∼ N(μ3, σ32)\nThus α0 is the response at the control combination, α1 is the linear coefficient of the response to the column factor strengths ζc, and α2 is the linear coefficient of the response to the row factor strengths ηr.\nThe user has the option to simplify the model and exclude the interaction term α3, which is the coefficient of the product of the two factor strengths.\nNote that despite being called “continuous” this dose response model applies to all endpoints. It’s called continuous because the coefficients act on the dose strengths as continuous measures of strength.\n\n\n\n7.3.2 2D Discrete Factorial Model\nThe 2D Discrete Factorial Model fits a regression on the dose response that uses the dose strength as a factor covariate rather than a numeric dose strength. Each dose is an independent level within each row or column factor, so any dose is equidistant from all other doses\nθ*r**c = α + γr + βc*\nWith priors\nα ∼ N(μα, σα2)\nβc ∼ N(μβc, σβc2)\nγr ∼ N(μγr, σγr2)\nThe parameters associated with lowest level of each factor, γ0 and β0, are constrained to be 0.\n\n\n\n7.3.3 2D NDLM\nThe 2-D NDLM Model takes the idea of smoothing across doses that was used in the standard NDLM model, but smooths across row factors and column factors separately.\n\n7.3.3.1 The Base Model, with Control Included\nThe treatment effect for the combination of level r in the row factor and level c in the column factor is denoted as θrc, and Yrc is the observed data in that cell. The borrowing parameters are denoted as ϕ for the row factor smoothing, and τ for the column factor smoothing. The dose strengths are denoted as vr for the row factors, and ωc for the column factors. Let Δνr = νr − νr − 1 and Δωc = ωc − ωc − 1 (for r > 0 and c > 0). For notational convenience at the grid edge, let θ−1, c = 0, θr, −1 = 0, Δν0 ≡ ∞, and Δω0 ≡ ∞.\nThe 2-D NDLM Model with control included in the model can then be specified as:\nθ0, 0 ∼ N(μ0, τ02)\nθrc ∼ N(μrc, τ*r**c*2)\nwhere\n\\[\\tau\\_{rc}^{2} = \\\\\\left( \\frac{1}{\\mathrm{\\Delta}\\nu\\_{r}\\phi^{2}} + \\frac{1}{\\mathrm{\\Delta}\\omega\\_{c}\\tau^{2}} \\right)^{- 1}\\]\n\\[\\mu\\_{rc} = \\\\\\tau\\_{rc}^{2}\\left( \\frac{\\theta\\_{r - 1,c}}{\\mathrm{\\Delta}\\nu\\_{r}\\phi^{2}} + \\frac{\\theta\\_{r,c - 1}}{\\mathrm{\\Delta}\\omega\\_{c}\\tau^{2}} \\right)\\]\nwith priors\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\n\\[\\phi^{2}\\\\\\sim\\\\IG\\left( \\frac{\\phi\\_{n}}{2},\\frac{\\phi\\_{\\mu}^{2}\\phi\\_{n}}{2} \\right)\\]\nNote: that not all combinations of r and c will have data associated with them. However, FACTS will still evaluate the prior at all combinations. Thus, in the situation depicted below where the grayed-out point indicates a treatment combination with no allocation, θ1, 2 is not modeled conditionally only on θ1, 1; θ0, 1 also informs on θ1, 2 via θ0, 2.\n\n\n\n7.3.3.2 Fix smoothing ratio for row factor and column factor\nOptionally, the user might want to specify the row factor borrowing as a function of the column factor borrowing:\nϕ ≡ k • τ\nwhere k is a user-specified constant. This can be performed by selecting “Fixed smoothing ratio” in the ϕ2 prior specification area.\n\n\n7.3.3.3 Control not in model, no zero-level doses\nIf neither treatment arm allows zero-level doses (e.g. like one would expect if the column factor represented doses and the row factor represented frequency), then a prior for the lowest dose would instead be needed as input from the GUI:\nθ1, 1 ∼ N(μ1, τ12)", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-concepts-efficacy", - "href": "documentation/v71/userguides/crm.html#sec-concepts-efficacy", - "title": "FACTS Dose Escalation CRM", - "section": "3.5 Efficacy", - "text": "3.5 Efficacy\nFACTS has the option to additionally model an efficacy endpoint. There are currently two limitations in simulation:\n\nOnly a binary efficacy endpoint can be simulated\nThe efficacy endpoint is assumed to be available at the same time as the toxicity endpoint.\n\nThe efficacy and toxicity endpoints are modelled separately. There are options to specify early stopping rules for finding the MTD, and to specify a cap on the sample size that can be spent finding the MTD. Once these rules are met, then allocation is towards the Minimum Efficacious Dose (MED) – if this is below the MTD. If the estimated MED lies at or above the estimated MTD, the allocation is at the estimated MTD.\nIf while allocating to the estimated MED further toxicity results change the estimate of the MTD, and if there is now insufficient information on the MTD as specified by the early stopping rules for finding the MTD, allocation switches back to allocating to the estimated MTD, if the sample size cap for finding the MTD allows.", + "objectID": "documentation/v71/userguides/core.html#baseline-adjusted-model-continuous-only", + "href": "documentation/v71/userguides/core.html#baseline-adjusted-model-continuous-only", + "title": "FACTS Core User Guide", + "section": "7.4 Baseline Adjusted Model (Continuous Only)", + "text": "7.4 Baseline Adjusted Model (Continuous Only)\nIf a baseline endpoint is simulated, the user has the option of adding a linear covariate effect to the dose response model. Thus, if the chosen dose response model states that for dose d,\nE[Yd] = g(d)\nThen the baseline adjusted model will fit a model of the form\nE[Yd|Z] = g(d)+ *β**Z*\nwhere β is a parameter estimated alongside the dose response parameters, and Z is the standardized baseline value (take each baseline value, subtract the observed mean, and divide by the observed standard deviation, for a given dataset this creates a set of fixed known constants). The model uses a normal prior for β for which the user enters a mean and standard deviation.\nNote that the VSR based simulation of baseline is more general than the model description (this is to allow baseline to be incorporated in a number of different ways). This means that the parameters entered in the VSR (for example the β parameter) need not match its estimated value. As a simple example, suppose we enter into the VSR response Y ∼ N(μY, σY), baseline X ∼ N(μX, σX), and use the baseline adjustment so the actual simulated Y is \\(Y^{'} = Y + \\beta\\_{VSR}\\frac{X - c}{s}\\).\nThe baseline adjusted value works for Z (standardized value of X). For a sufficiently large sample, this should be approximately \\(Z = \\\\\\frac{X - \\mu\\_{X}\\\\}{\\sigma\\_{X}}\\) and thus X is approximately *Z**σX + μX*. Thus, the actual simulated response is\n\\[Y^{'} = Y + \\beta\\_{VSR}\\left( \\frac{Z\\sigma\\_{X} + \\mu\\_{X} - c}{s} \\right)\\]\nThe model is fit under the assumption the Z values are fixed constants (identical to any simple linear regression). Thus, for a simple dose response (no model assumed, just fitting a separate mean for each dose\n\\[E\\left\\lbrack Y^{'} \\right\\rbrack = \\mu\\_{Y} + \\beta\\_{VSR}\\left( \\frac{Z\\sigma\\_{X} + \\mu\\_{X} - c}{s} \\right) = \\left\\lbrack \\mu\\_{Y} + \\beta\\_{VSR}\\left( \\frac{\\mu\\_{X} - c}{s} \\right) \\right\\rbrack + \\left\\lbrack \\beta\\_{VSR}\\frac{\\sigma\\_{X}}{s} \\right\\rbrack Z\\]\nThus, the fitted β from the model may not match the β used in the VSR, unless the values are also standardized in the VSR. Note the variances will always be inflated by using a baseline adjustment, so the estimated standard deviation of the responses from the model will tend to be greater than the standard deviation entered in the dose response tab of the VSR.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-concepts-fgd", - "href": "documentation/v71/userguides/crm.html#sec-concepts-fgd", - "title": "FACTS Dose Escalation CRM", - "section": "3.6 Fine Grain Dosing", - "text": "3.6 Fine Grain Dosing\nIn some settings, e.g. when the drug is delivered in solution by IV or when manufacturing allows any dose in a range from say 100mg to 400mg in steps of 10mg, dose strengths need not be restricted to just a small number of pre-defined levels. FACTS has a feature that allows this to be simulated, not with a continuous range of doses, but with “fine grain” dosing.\nFACTS supports the specification of a range of doses from a minimum to a maximum with doses either equally spaced or spaced with equal ratio. Using dose ratio makes most sense it you want to use the dose strength whilst believing the effect will be roughly log-dose. Using dose ratios, it’s necessary to accept FACTS reporting dose strengths only close to those desired. As an example, if the main doses followed a dose doubling scheme: 12.5, 25, 50, etc., one might use fine grain dosing with dose space ratios of approximately the 4th root of 2 (1.1892). The resulting doses are 12.5, 14.865, 17.677, 21.022, 24.999, 29.729, 35.354, 42.043, 49.998, etc., which means there are three dose levels between each of the original doses.\nThere are two alternatives:\n\nUse nominal dose strengths 1, 2, 3, 4, … (i.e. assuming the dose spacing is linear in expected effect) and label the doses according to their actual strength.\nUse a fixed dose interval (e.g. 12.5 resulting in doses of 12.5, 25, 37.5, 50, 62.5, etc.) so the lower doses (of the original scheme) have fewer (or no) intermediate doses and the higher doses have many more. The dose escalation rules can be specified in terms of dose strength ratio to achieve the required escalation, for example allowing dose escalation with a dose strength ratio of 2 will result in the initial escalation using doses 12.5, 25, 50, 100, etc.\n\nAs well as possibly adjusting the dose escalation step size to accommodate the new dose levels on the Design > Allocation Rule tab, there are two other rules that may need modification:\n\nTo count a dose as “cleared”, we might now count cohorts on nearby doses to count towards the required clearing total. This is specified as the “Max ratio of dose strengths considered as near” (if dose allocation rules apply to ratio of dose strength) or “Delta in dose strength considered as near” (if dose allocation rules apply to dose strength) on the Design > Allocation Rule tab.\n\nFor example, if we have doses at roughly 4th root of 2 intervals, we might count any dose within a ratio of 1.2 as “near” so that any cohorts allocated to immediate neighbor doses count towards clearing a dose.\nAlternatively, if we have doses every 12.5mg from 12.5 to 400, counting any dose within a ratio of 1.1 will mean that from dose 125 and above, immediate neighbor doses (within 12.5) count towards clearing a dose, and from dose 250 and above, doses within 25mg (two immediate neighbor doses) count towards clearing a dose.\n\nThe concept of “near doses” in fine grained dosing allows us to skip certain doses in the escalation phase, which might make sense if there is reason to believe that doses of similar dose strengths behave similarly and don’t provide enough additional information to justify assigning more cohorts to.\n\n\n\n\n\n\nFigure 6: Doses from 12.5 to 400mg, with fixed spacing of 12.5. Showing dose escalation by dose doubling.\n\n\n\nWhen requiring a certain number of cohorts to have been allocated to the estimated MTD before the trial can stop / to allow the trial to stop, we might now count cohorts on doses near the estimated MTD as counting towards that total. This is set on the Design > Stopping Criteria tab. In considering which doses are near, the same logic as on the Design > Allocation Rule tab regarding Dose Strength or Ratio of Dose Strength will be used.\n\nIf Dose Strength is used, then on the Design > Stopping Criteria tab, we can include cohorts on nearby doses to count towards the required number of cohorts on the estimated MTD by specifying “nearby” in terms of dose strength. For example, by +/- 12.5 mg:\n\n\n\n\n\n\nFigure 7\n\n\n\nIf ratio of Dose Strength is used then on the Design > Stopping Criteria tab, we can include cohorts on nearby doses to count towards the required number of cohorts on the estimated MTD by specifying “nearby” in terms of dose strength ratio. For example, by +/- 10%:\n\n\n\n\n\n\nFigure 8\n\n\n\n\n\nNote that with Fine Grain dosing, if a band is specified for a dose to count as cleared, then the maximum cleared dose will be the maximum dose within that band, and if incrementing relative to the Maximum cleared dose, then the maximum permitted increment will be relative to the maximum dose within the cleared band.", + "objectID": "documentation/v71/userguides/core.html#control-and-comparator-priors", + "href": "documentation/v71/userguides/core.html#control-and-comparator-priors", + "title": "FACTS Core User Guide", + "section": "7.5 Control and Comparator Priors", + "text": "7.5 Control and Comparator Priors\nThe control arm may be modelled as part of the dose response model or separately. If it is modelled separately, it may have a simple user specified Normal prior or a “historical” prior. A historical prior in FACTS is a hierarchical prior that models the response on control as coming from a distribution that also contains some historical response rates.\n\nThe active comparator is always modelled separately, and as with a control arm modelled separately, it can be modelled with a user specified Normal prior or a “historical” prior.\nWhen a user specified Normal prior is used the user specifies the mean and standard deviation of the prior normal distribution for θ0. This is useful if the control response is not thought to be consistent with the model being used to model the study doses – for instance if using an NDLM and there might be a sharp step in response from control to the lowest dose.\nIf “historical” prior is selected for either the control arm or an Active Comparator arm, an “Augmented Priors” tab is created.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-concepts-oe", - "href": "documentation/v71/userguides/crm.html#sec-concepts-oe", - "title": "FACTS Dose Escalation CRM", - "section": "3.7 Open Enrollment", - "text": "3.7 Open Enrollment\nOpen enrollment (Broglio et al. 2015) can be used instead of cohort enrollment. Cohort enrolment enrolls a fixed number of subjects to a given dose, then waits until their treatment and follow up is complete (so their final status – whether they suffered a DLT (Dose Limiting Toxicity) or not – is known) before deciding on the next dose to allocate to and then recruiting the next cohort. This likely means that subjects become available for inclusion in the trial, but have to be turned away as the trial waits for the current cohort to complete. Open enrollment attempts to address this by allowing subjects to be enrolled whilst the current “cohort” is completing. However, this may come with some risk – more than a cohort’s worth of subjects may now be exposed to a new dose before we have any estimate of its DLT rate. To allow this risk to be managed, open enrollment introduces two new concepts:\n\nWhen allocating to an uncleared dose, a cap can be set on the number of subjects that can be allocated to that dose who have not yet got their final results (“OE cap 1”). For example, if this number is set to 3 (to be the same as a common cohort size), after 3 subjects have been recruited and allocated to the current dose, no more subjects will be allocated to this dose until at least one of these subjects has completed. Until then, potential subjects that become available will be turned away unless backfilling is enabled (see next point below). But unlike cohort enrolment, as soon as the first of the subjects on the dose completes, a subject that comes available could now be allocated to the dose, depending on further rules explained below (frontfilling) – unless of course that subject’s result has changed the estimated MTD. Note that the trial won’t escalate beyond the current dose until the required number of subjects to clear the dose have completed. By default, the trial won’t allocate more than the number of subjects required to clear the dose until the dose is cleared, meaning if 3 subjects are required to clear a dose and 3 subjects have been allocated to this dose, even when 1 or 2 of these subjects have their final results and a new subjects is enrolled, they won’t be allocated to this dose. If this is regarded as over cautious, it can be modified by enabling frontfilling, allowing 3 subjects without final results simultaneously. In the above example, this would mean we could place a fourth subject on the dose when the result of the first subject has come in and a fifth subject as soon as the result of the second subject has come in.\nWhen the cap on the number of subjects without final results on an uncleared dose has been reached (“OE cap 1”) new potential subjects will be turned away, unless backfilling is enabled. Enabling backfilling allows these subjects to instead be included, allocating them to a lower dose that has already been cleared. Whilst such an allocation may not contribute as much to identifying the MTD as allocating to the current dose would, it can still contribute by:\n\nIncreasing the information on the next lower dose can inform the estimate of toxicity on the current dose through the Bayesian logistic model.\nProviding additional information on a dose that it may be necessary to de-escalate too if the current dose turns out to be too toxic.\n\nIt can also contribute information on other endpoints (such as efficacy). Once backfilling has been enabled, it is also possible to enable frontfilling. For more information on backfilling and frontfilling, see this section.\n\nAssume at a given point in time we want to allocate a subject to a specific dose, denoted by “candidate dose”. FACTS allows 3 different caps to be specified on how many subjects who have not yet got their final results (i.e. are not yet complete) can be allocated to this candidate dose:\n\n\n\n\n\n\nFigure 9\n\n\n\n\nMaximum subjects without final results if dose is uncleared: As described early in this section, we encounter this cap during escalation when the candidate dose is not yet cleared. This cap takes into account subjects not yet complete on the candidate dose and any higher dose (“OE cap 1”).\nMax subjects without final results if dose is cleared and below MTD: We encounter this cap when the candidate dose is cleared and below the estimated MTD (which can happen if the estimated MTD is beyond the range of available doses, when backfilling, or when allocating during the efficacy phase of a toxicity plus efficacy trial). This cap takes into account subject not yet complete on the candidate dose and any lower doses (“OE cap 2”).\nMax subjects without final results if dose is cleared and at MTD: We encounter this cap when the candidate dose is cleared and the current model estimated MTD (which can happen when after clearing a dose we decide not to escalate, or after de-escalating) (“OE cap 3”).", + "objectID": "documentation/v71/userguides/core.html#inverse-gamma-priors", + "href": "documentation/v71/userguides/core.html#inverse-gamma-priors", + "title": "FACTS Core User Guide", + "section": "7.6 Inverse-gamma priors", + "text": "7.6 Inverse-gamma priors\nFACTS uses inverse-gamma priors for parameters of variance – these are conjugate and allow efficient computation and avoid problems of convergence. Andrew Gelman’s 2006 paper[7] however notes a potential problem with this model, the problem is specifically\n\nWhen updating the estimate of the variance of a hierarchical model parameter there will be typically relative few actual data observations (e.g. relatively few historic studies for estimating the variance of the hyper parameter in a BAC (Bayesian Augmented Control) model for the response on a control arm, and relatively few observations of the change in response from one dose to the next when using an NDLM dose-response model).\nThe conventional ‘non-informative’ gamma-prior of IG(0.001, 0.001) has an effect when the observed variance is small, of over-shrinking the posterior estimate of variance.\n\nIn FACTS this possibility arises in the dose response models in the context of priors for ‘tau’ τ parameter for the NDLM models and α4 parameter for the hierarchical logistic dose response model, where the number of observations is the number of doses or dose intervals. [It also arises in the context of Bayesian Augmented Control and the hierarchical modeling or responses in different groups in ED].\nTo avoid the problem reported by Gelman we recommend using a weakly informative prior. Using the settings that control how the inverse-gamma distribution is parameterized (Settings > Options > Gamma Distribution Parameters), use the ‘mean and weight’ options and use a weight of 1, with a ‘reasonable’ expectation for the upper limit difference in the values being modeled entered as the prior mean for the SD. Strictly the distribution is the prior of the variance, so the parameter being specified is more correctly the prior mean of the square root of the mean of the variance.\nThis ‘reasonable’ upper limit for the difference is a value that a clinical team will usually have an intuition about: for the largest change in mean response from one dose to another for instance, it is often[8] reasonable to assume that the upper limit for the expected change in response from one dose to the next is the ‘expected difference in effect size’ that might have been used to power the trial in a conventional setting.\nIn this setting we are typically less concerned with the final estimate of the parameters of the hierarchical model and more concerned with the estimates of the values in the model (the dose –response) and thus less concerned to have a non-informative prior for it. The purpose of the trial is usually to estimate the dose response, and the hierarchical models are a means to an end, not an end in themselves.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-concepts-bf", - "href": "documentation/v71/userguides/crm.html#sec-concepts-bf", - "title": "FACTS Dose Escalation CRM", - "section": "3.8 Backfilling and Frontfilling", - "text": "3.8 Backfilling and Frontfilling\nAs described in the preceding section, Backfilling is the allocation of subjects to a lower dose when, due to restrictions, it is not possible to allocate a subject who comes available to the current dose (Dehbi, O’Quigley, and Iasonos 2021). FACTS provides a number of options to configure how backfilling behaves. Backfilling can be enabled in the Study > Study Info tab. The total sample size can be divided between the subjects allocated as part of conventional dose escalation and those allocated using backfill. When backfill is enabled, it is important to increase the total sample size and then limit the number that can be allocated using backfill, as subjects allocated using backfilling will not contribute to the escalation and the confirmation of the MTD and it’s usually important to retain sufficient sample size to achieve this aim.\n\n\n\n\n\n\nFigure 10\n\n\n\nWhen enabling backfilling, several options can be specified in the Design > Backfill Allocation tab.\n\n\n\n\n\n\nFigure 11\n\n\n\n\nTwo maximum caps can be specified on the number of subjects that are assigned in the process of backfilling to a given dose:\n\nan overall cap on subjects per dose that cannot be exceeded by backfill, counting also subjects that were assigned to that dose through regular allocation\na cap on the number of subjects per dose that were allocated by backfill, counting only subjects that were assigned to that dose using backfilling.\n\nHow many dose levels below the current dose can be allocated to when backfilling. Backfilling will always be to the highest dose possible (which might be the current dose if frontfilling is enabled, otherwise it will be below the current dose). Allocation to the next highest dose might be limited either by an open enrolment cap if there are already subjects allocated to that dose who have not yet completed, or it might be limited by the backfill caps described above. If allocation to the dose below the current dose is not possible, backfilling will by default look at the dose below that (two levels below the current dose) and so on. Using this option can ensure no backfilling happens to doses that are too far below the current dose.\nThe lowest dose that can be allocated to when backfilling. This option is particularly useful when there is reason to believe doses below a certain level will not be effective.\nWhether frontfilling is allowed – frontfilling allows allocating more subjects to uncleared doses than the number required to clear that dose (see this section).", + "objectID": "documentation/v71/userguides/core.html#handling-missing-data", + "href": "documentation/v71/userguides/core.html#handling-missing-data", + "title": "FACTS Core User Guide", + "section": "7.7 Handling Missing Data", + "text": "7.7 Handling Missing Data\nFACTS allows a “preprocessing” step to occur in handling missing data due to dropouts. If a subject has incomplete data due to a dropout, the user may specify all dropouts have their unknown final endpoint treated as known with the following options\n\nBOCF (continuous only, requires baseline be simulated) – All dropouts are assumed to have a final endpoint equal to their observed baseline value.\nLOCF (continuous or dichotomous, requires longitudinal data be present) – All dropouts are assumed to have a final endpoint equal to their last observed visit value. If no post-baseline visits are available, but the subject has a baseline visit value, then the baseline values is carried forward to their final endpoint.\nMissing is failure (dichotomous only) – All dropouts are assumed to be failures (which may be coded as 0 or 1 depending on whether a response is considered a success).\n\nSubjects who are imputed in this preprocessing step have final endpoint values known and used for the purposes of estimating the dose response curve. However, these preprocessed final endpoint values are not used in the updating on the longitudinal model, which is based only on observed visit data.\nIf the user does not specify one of the dropout imputation methods specified above, the dropout subjects and incomplete subjects (subjects who have not reached their final endpoint but are still continuing in the study) will have their final endpoints multiply imputed using Bayesian Multiple Imputation, described in the longitudinal modeling section.\nGenerally, patients with “no data” do not affect the posterior distribution, and thus are omitted from the analysis. However, one must take into account a subject can have no visit data but still have “data” based on these dropout imputation methods. For example, if one selects “missing as failure” and a patient drops out before any visit data is recorded, then the subject still supplies information through the dropout imputation (similarly for BOCF). However, if LOCF is selected and no visit data is available, there remains no information on the subject to be used for the LOCF dropout imputation, and thus these subjects are omitted from the analysis as well. Thus, all subjects are included which either 1) have some visit data available, or 2) are dropouts before visit 1 with sufficient information to impute their final endpoint with this preprocessing step.\n\n7.7.1 Time-to-Event Missingness\nFor a time-to-event endpoint, as is the convention in this endpoint, subjects are observed up to the time they have an event (or the end of follow up), so no subject drops out after having had an event; subjects that do drop-out are included in the analysis as not having had an event up to the last observation of the subject.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#open-enrollment-backfilling-and-fine-grain-dosing", - "href": "documentation/v71/userguides/crm.html#open-enrollment-backfilling-and-fine-grain-dosing", - "title": "FACTS Dose Escalation CRM", - "section": "3.9 Open Enrollment, Backfilling and Fine Grain Dosing", - "text": "3.9 Open Enrollment, Backfilling and Fine Grain Dosing\nWhen using open enrolment and fine grain dosing, the interval defined on the Design > Allocation Rule tab “Delta in dose strength considered as near +/-“, or “Max ratio of dose strengths considered as near” is crucial: it is used to define the range of doses where subjects allocated to any of them count towards clearing a dose.\n\nIf dose allocation rules are selected to apply to “Dose strength”, the interval is defined “Delta in dose strength considered as near +/-“. Thus, for example, if this is set to 2, then subjects complete on doses with strength in the range 4-8 will contribute to the dose of strength 6 being cleared. At the same time, clearing the dose of strength 6 will automatically clear the dose of strength 8.\nIf dose allocation rules are selected to apply to “Ratio of strength”, the interval is defined “Max ratio of dose strengths considered as near“. Thus, for example if this is set to 1.5, then subjects complete on doses with strength in the range 4-9 will contribute to the dose of strength 6 being cleared. At the same time, clearing the dose of strength 6 will automatically clear the dose of strength 9. These ranges also apply when assessing “OE cap 1-3”, and how many subjects have been allocated overall, or via backfilling. In backfilling, FACTS checks each dose strength and the doses in its “near” interval range, at (if frontfilling) or below the current dose, until the first dose strength is found where backfilling can take place.", + "objectID": "documentation/v71/userguides/core.html#bayesian-baseline-adjusted-model", + "href": "documentation/v71/userguides/core.html#bayesian-baseline-adjusted-model", + "title": "FACTS Core User Guide", + "section": "7.8 Bayesian Baseline Adjusted Model", + "text": "7.8 Bayesian Baseline Adjusted Model\nFor a continuous endpoint, if Baseline has been included in the simulation, it is possible to include modeling a linear covariate effect to the dose response model. The model for response changes from:\nY ∼ N(θd, σ2)\nto:\nY ∼ N(θd + *β**Z, σ*2)\nwhere β is the estimated parameter and Z is the standardized baseline value.\n\\[Z = \\frac{\\left( X - \\overline{X} \\right)}{s\\_{x}}\\]\nNote that the estimate of β will only correspond to the β used on the VSR tab to simulate the baseline adjustment if the centering and scaling values are the mean and the standard deviation of the baseline values.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#the-file-menu", - "href": "documentation/v71/userguides/crm.html#the-file-menu", - "title": "FACTS Dose Escalation CRM", - "section": "6.1 The “File” Menu", - "text": "6.1 The “File” Menu\nFACTS has a File menu with commands similar to those found in most Windows applications, but also some unique to FACTS. The commands can be found in Table 2.\n\n\n\nTable 2: List of commands in the CRM file menu\n\n\n\n\n\n\n\n\n\nCommand\nDefinition\n\n\n\n\nNew\nAllows the user to select a trial design type and start a new design; if there are unsaved changes in the current design the user is prompted to save them first.\n\n\nOpen\nAllows the user to select an existing FACTS file and open it; if there are unsaved changes in the current design the user is prompted to save them first.\n\n\nSave\nSaves the current changes in the design to the currently open FACTS file.\n\n\nSave As\nAllows the current version of the design to be saved to a new FATCS file; this file is then the “currently open” FACTS file going forward.\n\n\nExport Project\nCreates a “Zip” archive containing the current FACTS file and all the simulation results, so these can be easily archived, emailed, saved, etc.\n\n\nRecent Projects\nContains entries for the last ten FACTS files opened: selecting one re-opens it.\n\n\nRecent Folders\nContains entries for the folders that contain the last ten FACTS files opened: selecting one opens a file browser window on that folder allowing a ‘.facts’ file in that folder to be selected (or allowing the user to navigate to some different folder and select a ‘.facts’ file there).\n\n\nExamples\nContains example projects for the different design engines: selecting one opens it.\n\n\nClose\nCloses the current FACTS file, returning the user to the FACTS introduction screen.\n\n\nExit\nCloses FACTS altogether.", + "objectID": "documentation/v71/userguides/core.html#continuous-endpoints", + "href": "documentation/v71/userguides/core.html#continuous-endpoints", + "title": "FACTS Core User Guide", + "section": "8.1 Continuous Endpoints", + "text": "8.1 Continuous Endpoints\nThe model used for incorporating data from previous trials is as follows:\nθ0t ∼ N(μ0, τ02) for t = 0, 1, 2, …, T\nwhere θ0t is the mean for the control arm in trial t (t = 0 for the current trial; t = 1, 2, …, T for previous trials). User needs to specify appropriate priors for the hyper-parameters:\nμ0 ∼ N(m0, σ02)\nτ02 ∼ *I**G(a0, b*0)", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#facts-settings-menu", - "href": "documentation/v71/userguides/crm.html#facts-settings-menu", - "title": "FACTS Dose Escalation CRM", - "section": "6.2 FACTS Settings Menu", - "text": "6.2 FACTS Settings Menu\nThe “Settings” command menu allows the user to do 2 things:\n\nSet various FACTS options to local settings – see below for details.\nReset the options based on the stored configuration file. This file, “config.xml”, will initially be installed during the FACTS installation process and is stored in the Windows “Program Files” folder, in the sub-folder where FACTS get installed.\nChange the stored configuration file. This command allows you to select a new configuration file and have FACTS copy it to the sub-folder within the Windows “Program Files” folder, where FACTS get installed so it becomes the new stored configuration file. This allows IT support to easily disseminate configuration changes.\nEnter a new or changed license key.\n\n\n6.2.1 Set Options\nThe FACTS Options dialog allows the user to:\n\nSet and Test the connection parameters to access a compute grid for running simulations.\nConfigure the version and location of R or R Studio that can be launched from within FACTS\nSelect how gamma distributions are parameterized.\n\n\n6.2.1.1 Grid Configuration\nA grid compute facility for running simulations will only be available if your local IT services have set one up. If they have done so, they\n\nMay have already set the appropriate parameters In the FACTS configuration file included with the FACTS installation files.\nInform you of the parameters to be set manually via this dialog\nSend a new configuration file that can be installed using the “Load Options” menu command.\n\nIf modifying the grid options manually, select the “Options” menu command and enter the values on the “Grid Configuration” tab of the displayed dialog window.\n\n\n\n\n\n\nFigure 16: Webservice Configuration\n\n\n\nFirst select the type of interface to the grid to be used, this is either:\n\nVia a network shared drive (with a “sweeper script” running on a client machine to transfer jobs to the grid management system and return results from it).\nVia a web service system using a webserver and database to communicate to a grid management system. The IT group supporting the grid should be able to tell you which interface they have implemented, if any. If access to the grid is via a Network Share it is necessary to specify:\nThe location of the network share folder, usually in the form \\<server name>\\<folder name\\>.\nWhether the grid client is running Windows or Linux (so end-of-line characters can be corrected)\nThe listener delay – this is the interval between “looks” when FACTS is waiting for simulation results to be complete\n\nOnce specified it is possible to use the “Test” button to check that the Network Shared folder is accessible and writeable.\nIf access to the grid is via a web service:\n\nThe location of the web service endpoint.\n\nClicking on “Test Configuration” and will cause FACTS will attempt to connect to the FACTS grid controller. The control will show which components of the connection are working.\nSee the FACTS Installation Guide and FACTS Simple Grid Interface Guide for more details of setting up a grid.\n\n\n6.2.1.2 R Configuration\nIn FACTS on the Simulation tab there are two controls that launch R – “Open in R” and “ Design Report” (in FACTS 6.2.0 the latter only available for FACTS Core designs).\nTo enable these to work the user must specify where the R or RStudio executable is installed and (if there is more than one version of R installed) which version of R to use.\n\n\n\n\n\n\nFigure 17: The R Configuration Dialog\n\n\n\nThe dialog allows the user to Add, Edit, Test and Remove links to versions of R.\n\n\n\n\n\n\nFigure 18: Adding a link to R\n\n\n\nClicking on “Add” opens a normal Windows directory browser window, the user must navigate to the location of an R installation (for example “C:\\Program Files\\R\\R-2.15.2\\bin”, select the file R.exe, and click “Open”. This adds a new entry on the R configuration dialog.\nClicking on “Edit” operates similarly to “Add” above, except the selected location replaces that currently selected entry on the R configuration dialog rather than adding a new one.\nClicking on “Test” checks whether the currently selected entry on the R configuration dialog is available, if it is not an error dialog is displayed:\n\n\n\n\n\n\nFigure 19: Example of R Configuration error\n\n\n\nClicking on “Remove” removes the currently selected location on the R configuration dialog.\nThe version of R to use by default is selected by clicking on the ‘Active’ check box of the version to use.\n\n\n6.2.1.3 Gamma Distribution Parameters\nIn FACTS a number of parameters require inverse gamma distributions to be specified as priors for the parameter value. There are two different parameterization of the inverse gamma provided so that the user can select the form they find the most intuitive.\n\n\n\n\n\n\nFigure 20: The parameterisation of Inverse Gamma Distributions\n\n\n\nThe first form uses parameters that are the mean of the distribution and the equivalent weight in terms of the equivalent number of observations. The second form uses an ‘Alpha’ and ‘Beta’ parameterization that some statisticians are familiar with and will find natural to use.\n\n\n\n6.2.2 Enter a license key\nIf a new license key is required, this command can be used to enter one. There are two ways of entering a new license:\n\n\n\n\n\n\nFigure 21: Enter FACTS License Key\n\n\n\nThe key can be entered directly, along with the associated Organization name, or by selecting a supplied license file.", + "objectID": "documentation/v71/userguides/core.html#dichotomous-endpoints", + "href": "documentation/v71/userguides/core.html#dichotomous-endpoints", + "title": "FACTS Core User Guide", + "section": "8.2 Dichotomous Endpoints", + "text": "8.2 Dichotomous Endpoints\nThe model used for incorporating data from previous trials is as follows:\nθ0t ∼ N(μ0, τ02) for t = 0, 1, 2, …, T\nwhere θ0t is the log-odds for the control arm in trial t (t = 0 for the current trial; t = 1, 2, …, T for previous trials). User needs to specify appropriate priors for the hyper-parameters:\nμ0 ∼ N(m0, σ02)\nτ02 ∼ *I**G(a0, b*0)\nThe prior distributions for the hyper-parameters of the hierarchical model. The hyper-parameters are the mean and standard deviation of Normal distribution for the log hazard ratios of the event rates of the historical studies and the current study.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#the-help-menu", - "href": "documentation/v71/userguides/crm.html#the-help-menu", - "title": "FACTS Dose Escalation CRM", - "section": "6.3 The Help Menu", - "text": "6.3 The Help Menu\nFACTS has a Help menu with commands to assist you with the use of FACTS, providing links to users guides, tutorial and training videos. The commands are:\n\n\n\nTable 3: List of commands in the CRM help menu\n\n\n\n\n\n\n\n\n\nCommand\nDefinition\n\n\n\n\nUser Guides\nProvides access to documents such as this one, with (mainly) one user guide to each design type within FACTS. Exceptions to this simple structure are: 1. Core Design User Guide: A guide to the options under the ’Design” tab for FACTS Core for all endpoints. 2. Staged Design User Guide: As the staged design allows the design of one FACTS Core stage followed by a second, most of the interface is common to the basic FACTS Core. This guide describes the differences and additional aspects for all endpoints. 3. Dose Escalation User Guide: This covers all the Dose Escalation engines except for N-CRM and 2D-CRM that have their own. It thus covers the 3+3, mTPI, CRM(Toxicity), CRM(Ordinal), CRM(Efficacy) and bCRM engines.\n\n\nTutorials\nProvides access to all the tutorial documents, which describes detailed examples of use of all the engines in FACTS and many of their options. The examples under the File > Examples menu option largely correspond to the different tutorials described here.\n\n\nDesign Specifications\nThese are technical documents that describe the mathematical models implemented in FACTS in detail.\n\n\nExecution Guides\nThe FACTS GUI can be run in command line mode so simulations can be run/re-run from scripts. With the simulation command line flag, and passed a directory rather than a file, FACTS will run simulations for every “.facts” file in that directory – and recurse into any sub-directories and simulate any “.facts” files there too. A full guide to command line mode can be found here. The FACTS simulation engines are also available in “command line executable” form. There are guides here that document their command line parameters and how to use them to analyse a data set – e.g. to perform an interim analysis whilst executing a trial designed with FACTS.\n\n\nFACTS file XML Specs\nThese guides describe the parameters in the “.facts” files, which are text files in XML format. For expert users understanding this format allows them to use scripts to generate versions of an initial “.facts” file with slight variations in the parameters such as stopping thresholds or priors. Modification of “.facts” files outside of FACTS needs to be done with care, errors may render the file unusable by FACTS.\n\n\nVideos\nProvides access to links to the introductory, training and webinar videos that Berry Consultants has recorded and makes available over the internet to FACTS users.\n\n\nView log…\nIf an error has occurred in FACTS, often the FACTS log file can shed light on what is going wrong. The log file is hidden away in some unfashionable and hard to locate Windows folder; this command option provides easy access to it. Allowing you to email facts support with a description of what occurred, attaching a copy of this log file having saved it somewhere convenient such as your desktop.\n\n\nSupport\nLaunch a simple editor for sending an email to our support account: facts@berryconsultants.net\n\n\nAbout\nDisplays a simple “about box” that includes the detailed version number of FACTS.", + "objectID": "documentation/v71/userguides/core.html#time-to-event-endpoints", + "href": "documentation/v71/userguides/core.html#time-to-event-endpoints", + "title": "FACTS Core User Guide", + "section": "8.3 Time-to-Event Endpoints", + "text": "8.3 Time-to-Event Endpoints\nThe model used for incorporating data from previous trials is as follows:\nλ*s**t= λsexp (γt) for t = 0, 1, 2, …, T*\nwhere λ*s**t is the hazard rate for the control arm in segment s* (s = 1, 2, …, S) for previous trial t (t = 1, 2, …, T) and λs0 is the hazard rate for the current control arm in segment s; λs is a base hazard for segment s; and γt is the log hazard ratio between that base rate and the λ*s**t* values.\nThe following hierarchical model is used\nγt ∼ N(μγ, τγ2) for t = 0, 1, 2, …, T\nUsers specify priors for the hyper-parameters:\nμγ ∼ N(mγ, tγ2)\nand\nτ2 ∼ *I**G(aγ, bγ*)\nThe formulation above is not identifiable as changes in λs can be compensated for by changes in the γt values (thus, one can use different combination of λs and γt but acquire the same set of values λ*s**t and thus the same likelihood. To avoid this difficulty, we use the above formulation but fix γ0 = 0. In addition to preserving the identifiability of the structure, this constraint allows λs to have the interpretation of being the hazard rate for the current control arm, and thus the prior on λs from the main dose response may be used as the prior for λs*.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#study-info", - "href": "documentation/v71/userguides/crm.html#study-info", - "title": "FACTS Dose Escalation CRM", - "section": "7.1 Study Info", - "text": "7.1 Study Info\nThe Study Info sub-tab provides parameters for specifying:\n\nWhether the trial has an Efficacy endpoint as well as a Toxicity one.\nWhether recruitment is in Cohorts or uses Open Enrolment,\nWhether the trial data is being analyzed as a single population (single group) or two groups (which could be 2 different patient types, or 2 different treatment types).\nThe option to specify that the trial should include an expansion cohort once the MTD has been identified.\nThe option (if using open enrolment) to specify the use of backfill.\n\nIncluding an efficacy endpoint – this allows the trial to include a binary efficacy outcome that is observed at the same time as the toxicity endpoint. Once the MTD has been sufficiently determined further cohorts are allocated to determine the MED (Minimum Effective Dose) as long as that is below the MTD, until the maximum sample size or MED stopping rules have been reached.\nCohort versus Open enrolment: cohort enrolment is the standard way of running a phase 1 trial, a cohort of subjects of pre-determined size are treated at the current dose and the trial pauses until all the subjects in the cohort are complete, then the dose for the next cohort is determined. A phase 1 trial using Open Enrolment recruits ‘all comers’ with a cap on the number of subjects who can be treated but have not yet had a final result. Subjects that arrive whilst this cap has been reached are deemed to be ‘lost’ to the study.\nIf Open Enrolment and Efficacy Endpoint options are being used together, then subjects who arrive who cannot be allocated to the MTD (because the cap number of subjects awaiting a final result has been reached), can be allocated to the MED (as long as that is below the MTD).\nIf the trial is analyzing 2 Groups then a joint statistical model is used with options to constrain the group 2 difference in the intercept term to be +ve or -ve, and options as to whether a common or separate estimates of the slope term are used.\nIf an expansion cohort is included, the this is a single cohort (or one per group, if 2 groups is being used) typically much larger than used during the dose escalation, that is assigned at the end of the study to the target dose. FACTS simulates the results that arise from this cohort and a final analysis.\nIf open enrolment is being used, the further option to use backfill becomes available. The parameters on this tab for backfill, are to specify the maximum number of subjects that can be allocated for escalation, and the maximum that can be allocated in backfill. These two maximums should not total less than the overall “Max subjects” that can be enrolled. If adding backfill to a trial, usually the previous “Max subjects” becomes the “Max study allocation for escalation”, and an additional sample is allowed for backfill and added to the overall Max subjects.\nIf the trial has two groups the backfill maximums are the sum of the subjects in the two groups.\nFor Cohort enrolment, the parameters are:\n\nMaximum Study Size, in cohorts: the maximum number of cohorts the trial can use, though designs can include conditions that cause them to stop earlier.\nIf the trial has two groups, the maximum number of cohorts of the second group.\nCohort size: The number of subjects in each cohort. The maximum sample size for the trial is simply: Max Trial Size (cohorts) * Cohort Size.\nCohort information delay: Normally left at zero, this allows for the trial to be simulated with cohorts recruited more quickly than if waiting for the last cohort to complete before treating the next cohort. This allows the trial to complete in shorter time, but is likely to lead to a larger incidence of toxicities. If the delay is set to 1, the second cohort will be recruited before the results for the first cohort are available, the third cohort will be recruited after the results of the first cohort are available but before the results for the second cohort are available, and so on.\nExecution rate: the time taken to recruit, treat and complete the observation of each cohort (in weeks). The value of this parameter does not affect the behavior of the simulations, but it allows a nominal “duration” of each simulation to be calculated. Unlike other FACTS simulations, this duration is not simulated stochastically, it is simply the number of cohorts * this duration. Its purpose is to give a figure to compare with open enrolment designs of the same trial.\n\n\n\n\n\n\n\nFigure 22: Study Info - Cohort Enrolment\n\n\n\n\n\n\n\n\n\nFigure 23\n\n\n\nIf rather than Cohorts, subjects are recruited using open enrolment, the parameters are:\n\nMax subjects: the maximum number of subjects who can be recruited into the study.\nTime unit – this is a text string that will change the “units” label for time on graphs. This allows data to be more easily entered when the natural time unit is not “weeks”, but “days” or “months”.\nMean recruitment rate: for simulation purposes this is the average number of subjects who will be expected to be available for recruitment during each time period. Recruitment is simulated using a standard Poisson process.\nTime until final result: the time for each subject for their final result to become available. This is simulated as a fixed length of time that is the same for all subjects.\nMaximum subjects without a final result: the cap on the number of subjects on the current dose or a backfill dose (if backfill is enabled) who can be recruited but not yet completed. This is also known as the ‘maximum queue length’. Subjects arriving and available for recruitment while the number of subjects on this dose who have been treated but have not yet completed is at this maximum, are dropped and assumed no longer available for recruitment. Once the current subjects complete the study has to await further new subjects to become available. There are three caps:\n\nMaximum subjects without final results if the dose is uncleared. This allows the design to be cautious when a new dose is used for the first time.\nMaximum subjects without final results if dose is cleared and below MTD. This allows a larger number of subjects without final results to be recruited at backfill doses or at the current escalation dose if backfill to the current escalation dose (“frontfilling”) is enabled, or at the MED in the efficacy phase of a trial that includes an efficacy endpoint.\nMaximum subjects without final results if dose is cleared and at MTD. This allows us to be more cautious if the model thinks all doses are toxic or if we are allocating at the model MTD and don’t want to expose too many subjects.\n\nBackfill – this can be enabled. Backfilling is the allocation of subjects to a dose below the current target dose, if the number of subjects allocated to the current target dose without final results has reached the maximum. Further parameters for backfill are set on the “Backfill” tab under the “Design” tab. On this tab, if backfill is enabled, two sub-maximums can optionally be specified:\n\nthe maximum number of subjects who can be allocated as part of usual allocation for escalation and MTD determination (and MED if efficacy is included in the trial),\nand the maximum number of subjects who can be allocated as part of “backfill”.\n\n\n\n\n\n\n\n\nFigure 24: Study Info - Open Enrolment\n\n\n\nGroups: a trial can be analyzed as a “single group” or as “two groups”. If analyzed as a single group, then all subjects are assumed to be the same and treated the same (except for the difference in the dose strength). If analyzed as two groups this allows either:\n\nThe subjects can be simulated as coming from two similar but distinct groups such as: adults and children, first line or recurrent, having some concomitant treatment or not. The separation into the two groups is based on some property of the subject.\nOr the subjects can be simulated as having been allocated (possibly randomized) to one of two versions of the treatment, with the same rang of dose strengths and differing in some other way such as dosing schedule, treatment duration or combination with an additional treatment. The separation of the subjects into the two groups is under the control of the protocol.\n\nIn either case the same analysis options are available (hence we use the generic term “groups” to describe this feature).\nIf enrolment is by cohort, the there are two separate “maximum study sizes” in cohorts – one for each group.\nThe Group 2 recruitment, while it overlaps in time with the Group 1 recruitment, is simulated as being in lock-step and the recruitment of the cohort in each group is concurrent and analyzed when both are complete. In the ‘cohorts.csv’ files that are output, the cohort numbers indicates which cohorts were concurrent. The options are:\n\nTo recruit group 1 first then recruit group 2 only when group 1 is complete.\nTo start recruiting both groups in parallel from the outset.\nTo start recruiting group 2 once group 1 has reached a specified dose. The first group 2 cohort is recruited in parallel with the next group 1 cohort after the first group1 cohort has been allocated the specified dose (if cohorts can be accrued before the cohort before has completed, the group 2 is accrued too – it does not wait until the group 1 cohort completes unless the next group 1 also waits).\nTo start recruiting group 2 once group 1 has recruited a specified number of subjects. The first group 2 cohort is recruited in parallel with the next group 1 cohort after the specified number of subjects had been recruited into group 1.\n\nIf enrolment is open then there are options similar to the cohort enrolment to control when enrolment into group 2 starts:\n\nTo recruit group 1 first then recruit group 2 only when group 1 is complete.\nTo start recruiting both groups in parallel from the outset.\nTo start recruiting group 2 once group 1 has reached a specified dose. The first group 2 subject can be recruited after the first group1 subject has been allocated the specified dose.\nTo start recruiting group 2 once group 1 has recruited a specified number of subjects. The first group 2 subject can recruited after the specified number of subjects had been recruited into group 1.\n\nBut in addition the user specifies the maximum number of subjects in Group 2 and how the recruitment is to be simulated:\n\nWith the group membership a property of the subject – along with a mean recruitment rate for group 2.\nWith subjects randomized between the two groups (the randomization is fixed at 1:1).\n\nThe user specifies the three “Maximum subjects without final results …” for the second group.\nIf backfill is enabled, the backfill totals apply to the total of the subjects on both groups.\n\n\n\n\n\n\nFigure 25: Study info - 2 group options with open enrolment\n\n\n\nEnable Final Expansion Cohort: if this is enabled a final cohort of specified size will be allocated the dose selected as MTD at the end of the N-CRM phase of the study:\n\nIf the study includes a control arm, the number of subjects in this expansion cohort to be allocated to control is also specified.\nIf the study has two groups, two separate expansion cohorts will be allocated, their sizes are set separately.\nIf the study includes observing efficacy then the target dose can be changed from MTD to MED or OSD.\n\n\n\n\n\n\n\nFigure 26\n\n\n\nSimulating an additional efficacy outcome is simply specified by checking the “include efficacy” checkbox.\n\n\n\n\n\n\nFigure 27: Study tab with “Include efficacy” checked\n\n\n\nSimulating an efficacy endpoint can be combined with all the other features (two groups, open enrolment, backfilling) already discussed, as well as with ordinal toxicity and fine grain dosing that are described below.\nCurrently there are two significant limitations to the simulation of an efficacy endpoint:\n\nThe endpoint is assumed to be dichotomous.\nThe endpoint is assumed to be observable at the same time as toxicity.\n\nWe hope to lift these restrictions in a later version of FACTS.", + "objectID": "documentation/v71/userguides/core.html#setting-priors-for-hierarchical-model-hyper-parameters", + "href": "documentation/v71/userguides/core.html#setting-priors-for-hierarchical-model-hyper-parameters", + "title": "FACTS Core User Guide", + "section": "8.4 Setting Priors for Hierarchical Model Hyper Parameters", + "text": "8.4 Setting Priors for Hierarchical Model Hyper Parameters\n\n\n\nFigure 8‑2 Execution > Accrual tab, with deterministic accrual\n\n\n\n\n\n\n\n\n\nUnless the intent is to add information that is not included in the historic studies, the hyper parameters can and should be set so that they are ‘weak’ priors, centered on the expected values.\n\n\nIn this case the following would be reasonable:\n\n\n\n\nSet the prior mean value for Mu as the mean of the mean responses on the control arm in the historic studies\n\n\n\n\nSet the prior SD for Mu equal to the average SD of response divided by the square root of the number of studies.\n\n\n\n\nSet the mean for tau to the same value as the prior SD for Mu.\n\n\n\n\nSet the weight for tau to be < 1.\n\n\n\n\nOne can traverse the spectrum from ‘complete pooling of data’ to ‘completely separate analyses’ through the prior for tau. If the weight of the prior for tau is small (relative to the number of studies), then (unless set to a very extreme value) the mean of the prior for tau will have little impact and the degree of borrowing will depend on the observed data.\n\n\nTo give some prior preference towards pooling or separate analysis the weight for tau has to be large (relative to the number of historic studies) – to have a design that is like pooling all the historic studies the mean for tau needs to be small (say 10% or less of the value suggested above). For there to be no borrowing from the historic studies the value for tau needs to be large (say 10x or more the value suggested above).\n\n\nThe best way to understand the impact of the priors is try different values and run simulations.\n\n\n\n\n\n\n\nFigure 8‑2 Execution > Accrual tab, with deterministic accrual", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#toxicity", - "href": "documentation/v71/userguides/crm.html#toxicity", - "title": "FACTS Dose Escalation CRM", - "section": "7.2 Toxicity", - "text": "7.2 Toxicity\nThe Toxicity sub-tab provides parameters for specifying:\n\nWhether toxicity should be simulated as dichotomous or ordinal. If simulated as Ordinal, toxicity can be simulated as a 1-3 scale or 1-4 scale. In both cases ‘1’ is “no-toxicity”, 2 is “mild toxicity” and 3 is the toxicity of interest (from the point of view of defining the MTD, target toxicity band and Overdose Control. If a four category scale is selected, 4 is “sever toxicity” or death. Choosing whether to model the ordinal response is a separate option and is present on the Design > Toxicity Response tab.\nType of target: this allows the user to specify whether the dose selection targets “the dose who’s estimated toxicity rate is closest to a specified target rate” or “the dose with the highest posterior probability of having a toxicity rate in a target band”. The former is the target rule used in the original CRM papers ((O’Quigley, Shen, and Gamst 1999), (deMoor et al. 1996), and the latter rule was introduced in (Neuenschwander, Branson, and Gsponer 2008).\nToxicity target (only displayed if the type of target is “a single dose”): this allows the target toxicity rate to be specified and whether the target dose is the one nearest, the one nearest but with a lower rate or the one nearest but with a higher rate.\nTarget: this panel allows the target toxicity bands to be specified along with overdose control limits. The panel is displayed and enabled even if the target type is “a single dose” to allow overdose control limits to be specified.\nType of Target: controls the selection of the dose for the next cohort – this can be to target a single dose (to replicate the original CRM behavior, see this section) or to target the dose with the highest probability that its toxicity rate lies in a target band.\n\n\n\n\n\n\n\nFigure 28: Toxicity tab targeting a toxicity band\n\n\n\n\n7.2.1 Targeting a Toxicity Interval\nTargeting a toxicity band or interval is an innovation introduced with the N-CRM design, unlike other CRM designs that select the dose that is expected to have a toxicity response closest to the desired tolerated limit, the N-CRM selects the dose that has the highest posterior probability of having a toxicity rate in a target toxicity band. This has the advantage of a) having a clearer probability statement and b) having in addition probability statements about the probability of under and overdosing (the toxicity rate being below or above the target toxicity band).\n\nThe uncertainty in the estimate of toxicity at each dose is expressed by calculating the posterior distribution of the estimate of the rate of toxicity at each dose and calculating the proportion of that distribution that falls in to each of 4 bands of toxicity: ‘Under-dosing’ (toxicity so low that it is likely that a higher dose could be used), ‘Target’ toxicity (we want to select doses whose toxicity rate is most likely to be in this band), ‘Excess’ toxicity (toxicity higher than desired) and ‘Unacceptable’ toxicity.\n\nUnder-dosing: this band always starts at 0.0; the user specifies the upper bound.\nTarget band: this band always starts at the upper-bound of the under-dosing band; the user specifies the upper bound.\nExcess toxicity: this band always starts at the upper-bound of the target band; the user specifies the upper bound.\nUnacceptable toxicity: this band always starts at the upper-bound of the target band, with an upper bound of 1.0. The graph shows the width of the different bands using a simple, fixed, example posterior probability distribution of a toxicity rate.\n\nIntervals are relative to control: if a control arm is included in the study, then toxicity bands can be defined as the difference in toxicity rate relative to control. Negative differences (a lower toxicity rate than control) are always treated as under-dosing. To enable this option it is necessary to first go to the Study > Treatment Arms tab and select Include Control.\nLimit max excess/unacceptable toxicity: the ‘overdose control’ in terms of a maximum allowed posterior probability that a dose’s toxicity rate lies in either the ‘Excess’ or the ‘Unacceptable’ toxicity bands. Any dose with a posterior probability of having a toxicity rate in either of these two bands that is higher than the specified limit, cannot be selected for allocation to the next cohort, nor selected as MTD at the end of the study (this gives rise to slightly different results compared to those in (Neuenschwander, Branson, and Gsponer 2008) where the overdose control was not applied to final selection).\n\nIt is possible to have the overdose control limit vary with the number of cohorts allocated. In particular this can be used to reduce the overdose limit as the number of cohorts (and the amount of information) grows. For example for a particular prior and final level of overdose control, it may be that initial escalation is excessively constrained, one way to allow early escalation in this setting is to use these parameters to allow an higher initial overdose control limit and gradually reduce it over time to the final desired limit. Tuning the parameters will require some iteration and simulation. A varying limit is specified by the specifying amount to change the limit by per cohort and the final limit. The amount to change by is always entered as a number in the range (0,1), whether this is an increment or decrement depends on whether the target limit is greater or less than the initial limit. Leaving the change in limit at its default of 0 means the limit does not vary.\nLimit max unacceptable toxicity: as for the previous parameter, but here the overdose control is only in terms of the posterior probability that a dose’s toxicity rate lies in the ‘Unacceptable’ toxicity band.\nAs or the limit on excess/unacceptable toxicity it is possible to have the overdose control limit vary with the number of cohorts, see the description above.\n\n\n\n7.2.2 Targeting a single dose\nIt is possible to use the N-CRM design engine with a conventional CRM allocation strategy - to “allocate to the nearest / highest dose below the maximum tolerated toxicity”; this allows conventional CRM design to be simulated with some of the additional features of N-CRM:\n\nOverdose control\nEstimate both parameters of the 2 parameter logistic\nThe “Recommender” to analyze a specific data set.\n\nThe target is calculated by:\n\nIn the MCMC sampling loop finding the dose that meets the target criteria, a doses probability of being the target is then the proportion of times that dose meets the target criteria across the MCMC sampling.\nRather than selecting the dose with the highest probability, the dose at the 50% quantile is used. The cumulative probability of being the target is calculated over the doses in ascending dose strength, and the dose when the cumulative probability passes 50% is selected. This addresses some problems that can arise when very little data is available: that the dose with the highest probability is at one end of the dose range, but that probability is not that high, or that doses are not evenly spaced and a dose close to both its immediate neighbors may never have greater probability than both of them.\n\nSetting the Type of Target option to Target a single dose, modifies the tab thus:\n\n\n\n\n\n\nFigure 29: N-CRM, targeting a single dose, not a toxicity band\n\n\n\nWhen targeting a single dose FACTS allows the user to specify:\n\nThe target toxicity rate\nWhether to allocate to the dose with the mean estimate of its toxicity rate nearest the target, highest dose with a mean estimate of its toxicity rate below the target or lowest dose with a mean estimate of its toxicity rate above the target.\nAn option to use the toxicity rate relative to control, rather than the default of the absolute toxicity rate. To enable this option it is necessary to first go to the Study > Treatment Arms tab and select Include Control.\n\nThe definition of the boundaries of the toxicity bands is still included in order to allow the specification of overdose control limits. These are calculated and applied in exactly the same way as when targeting a toxicity interval.", + "objectID": "documentation/v71/userguides/core.html#bac-example", + "href": "documentation/v71/userguides/core.html#bac-example", + "title": "FACTS Core User Guide", + "section": "8.5 BAC Example:", + "text": "8.5 BAC Example:\nIt is easiest to study the impact of BAC in a simplified version of the trial being designed, for example use a 2 arm fixed design with ‘no model’, no adaptation, no longitudinal modeling, etc.\nFor instance in a continuous setting with an expected sample size of 50 on control, a mean response of 5 and an SD in the response of 2, looking at the effect of having 4 prior, similarly sized studies:\n\n\n\nFigure 8‑4 Deterministic accrual tab\n\n\n\n\n\n\n\n\n\n\n\n\n\nNumber of subjects\n\n\nMean Response\n\n\nSD of Response\n\n\n\n\n\n\nStudy 1\n\n\n50\n\n\n4.76\n\n\n2\n\n\n\n\nStudy 2\n\n\n50\n\n\n4.93\n\n\n2\n\n\n\n\nStudy 3\n\n\n50\n\n\n5.07\n\n\n2\n\n\n\n\nStudy 4\n\n\n50\n\n\n5.24\n\n\n2\n\n\n\n\nFigure 8‑4 Deterministic accrual tab\nFor simplicity we have just varied the means of the studies – they are all consistent with a normally distributed estimate, with mean of 5 and a standard error of \\(\\frac{2}{\\sqrt{50}}\\).\nBy simulating a fixed trial with a sample size of 100 and fixed 1:1 allocation between control and a study arm we can easily observe the effects of a BAC on the control arm. Creating 6 VSR profiles with sigma = 2, and the same mean response for control and the study arm in each profile of: 4.53, 4.76, 5.07, 5.24 and 5.47 we can look at the bias of the final estimate and the shrinkage in the SD of the estimate that could be brought about by using BAC:\n\n\n\nFigure 3‑1 Quantities of Interest tab\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nTrue Mean\n\n\nRaw mean\n\n\nRaw SD\n\n\nEstimate inc BAC\n\n\nSD inc BAC\n\n\nBias\n\n\nEffective additional Subjects\n\n\n\n\n\n\n4.53\n\n\n4.55\n\n\n0.28\n\n\n4.64\n\n\n0.255\n\n\n2.1%\n\n\n11.1\n\n\n\n\n4.76\n\n\n4.78\n\n\n0.28\n\n\n4.83\n\n\n0.250\n\n\n1.0%\n\n\n13.5\n\n\n\n\n4.93\n\n\n4.95\n\n\n0.28\n\n\n4.96\n\n\n0.248\n\n\n0.2%\n\n\n14.3\n\n\n\n\n5.07\n\n\n5.09\n\n\n0.28\n\n\n5.07\n\n\n0.248\n\n\n-0.4%\n\n\n14.2\n\n\n\n\n5.24\n\n\n5.26\n\n\n0.28\n\n\n5.20\n\n\n0.250\n\n\n-1.1%\n\n\n13.2\n\n\n\n\n5.46\n\n\n5.49\n\n\n0.28\n\n\n5.38\n\n\n0.255\n\n\n-1.9%\n\n\n10.7\n\n\n\n\nFigure 3‑1 Quantities of Interest tab\nNote it is important to use the column “SD Mean resp 1” from the simulations file to see the SD of the estimate and not use the SD of the estimates in the summary table.\nThe small shrinkage in the SD is more impressive when viewed in terms of how many additional subjects would have to be recruited to achieve the same shrinkage in the raw estimate. These are useful savings for small additional bias.\nThe “effective additional subjects” was calculated:\n\\(\\left( \\frac{True\\\\sigma}{AVG(SD\\\\Mean\\\\resp)} \\right)^{2} - \\left( \\frac{True\\\\sigma}{AVG(SE\\\\Mean\\\\Raw\\\\Response)} \\right)^{2}\\)where in this example True Sigma was 2.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#efficacy", - "href": "documentation/v71/userguides/crm.html#efficacy", - "title": "FACTS Dose Escalation CRM", - "section": "7.3 Efficacy", - "text": "7.3 Efficacy\nIf include efficacy has been checked on the Study Info tab, a simple additional input page is included:\n\n\n\n\n\n\nFigure 30: The Efficacy tab\n\n\n\nIf simulating and modelling an efficacy endpoint is included there are two items to be specified on this tab:\n\nWhether a subject experiencing a toxicity can also count towards efficacy or not. If unchecked patients outcomes are simply sampled separately and a patient can both have a toxicity and an efficacy response. If checked, a patient’s toxicity outcome is sampled first, and only if there is no toxicity is an efficacy outcome sampled.\nThe efficacy target – this consists of:\n\nThe target efficacy rate required for the Minimum Efficacy Dose (MED).\nWhether the target dose is the nearest dose to the MED rate, the lowest dose above the MED rate or the highest dose below the MED rate.\nIf a control arm has been included, whether the target rate is absolute or relative to the observed rate on the control arm.", + "objectID": "documentation/v71/userguides/core.html#continuous-endpoints-1", + "href": "documentation/v71/userguides/core.html#continuous-endpoints-1", + "title": "FACTS Core User Guide", + "section": "9.1 Continuous Endpoints", + "text": "9.1 Continuous Endpoints\nAt the end of each simulated trial the following frequentist values will be calculated using LOCF for missing data:\n\nUsing unadjusted dose-placebo comparisons based on a two-sample t-test calculate the:\n\ntest statistic,\np-value[9],\nconfidence interval for the mean difference,\nfor each dose its marginal probabilities of significance (the number of times it was significantly separated from placebo independent of whether any other doses were) .\n\nusing Dunnett-adjusted[10] dose-placebo comparisons based on a two-sample t-test calculate the:\n\ntest statistic,\np-value,\nconfidence interval for the mean difference\nfor each dose its marginal probabilities of significance (the number of times it was significantly separated from placebo independent of whether any other doses were) .\n\nUsing the general trend test calculate the t-test statistic and p-value using user supplied contrast coefficients.\n\n(If neither placebo or active comparator are specified, difference from 0 is assessed for each dose arm and Dunnett-adjusted calculations are not carried out.)\nP-values are calculated using a one-sided t-test testing H0: μT < μC against H1: μT ≥ μC, with subscript T referring to the treatment arm and subscript C referring to the control arm (if high values are good; otherwise, the opposite hypotheses are being tested).\nLast observation carried forward (LOCF), baseline observation carried forward (BOCF), and Per-protocol (Ignore) are available as ways to handle missingness in continuous frequentist calculations.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#treatment-arms", - "href": "documentation/v71/userguides/crm.html#treatment-arms", - "title": "FACTS Dose Escalation CRM", - "section": "7.4 Treatment Arms", - "text": "7.4 Treatment Arms\nOn this tab the number of treatment arms (doses) available to the study is specified. The user can either define a set of specific doses that can be used or a continuous dose range with some granularity.\nSelecting Explicit Doses allows the user to specify the specific doses that can be used on the trial:\n\nA single new dose or multiple doses can be added either by clicking “Add” or “Generate”. Initially each dose is defined by a simple integer name and level. The dose levels and dose names can then be edited on by clicking on them and entering the desired value. The dose level can also be set later on in the Design > Toxicity Response tab.\nThere is also the option to include a control arm. Including a control arm allows the toxicity rate to be relative to the control arm.\n\n\n\n\n\n\n\nFigure 31: The Treatment Arms tab specifying explicit doses\n\n\n\n\n7.4.1 Finely Spaced Doses\nSelecting Finely Spaced Doses allows the user to specify the dose range that can be used on the trial:\n\nThe minimum and maximum dose strength to be used\nThe ‘granularity’ of the actual dose used, either as a fixed delta (Fixed spacing) or a dose ratio (the ratio specified must be greater than 1) (Ratio spacing).\nThe number of ‘bins’ or ‘doses for which to report’ – this is because FACTS will still produce summary statistics in columns, many with a “column per dose” – it is possible to use more doses than it is practical to report on (and a limit in MS Windows of 32K pixels for the width of a table means that the GUI can only display simulation results for a maximum of ~40 doses). However this limitation is only for reporting summary statistics; the dose strengths modeled and allocated in the simulations are unaffected.\n\nSelecting ‘Finely Spaced Doses’ will also affect how some of the other parameters are specified in the FACTS GUI.\n\n\n\n\n\n\nFigure 32: The Treatment Arms tab, specifying a finely spaced dose range", + "objectID": "documentation/v71/userguides/core.html#dichotomous-endpoints-1", + "href": "documentation/v71/userguides/core.html#dichotomous-endpoints-1", + "title": "FACTS Core User Guide", + "section": "9.2 Dichotomous Endpoints", + "text": "9.2 Dichotomous Endpoints\nAt the end of each simulated trial the following frequentist values will be calculated using LOCF for missing data:\n\nUsing the methodology described by Agresti[11], Mee[12] and Nurminem[13] for comparing the difference of proportions:\n\ntest statistic,\np-value,\n95% confidence interval for the difference in proportions,\nmarginal probabilities of significance.\n\nusing Dunnett-adjusted dose-placebo comparisons for comparing the difference of proportions:\n\ntest statistic,\np-value,\n95% confidence interval for the difference in proportions,\nmarginal probabilities of significance.\n\nUsing the general trend test calculate the t-test statistic and p-value using user supplied contrast coefficients.\n\nP-values are calculated by user choice either using a normal approximation (see previous section on p-value calculations for continuous endpoints) or a Fisher’s exact test, which is a conservative test to test the null hypothesis that the outcome is independent of the treatment assignment. For the normality approximation to have good asymptotic coverage, the expected number of successes and failures under the null hypothesis should be greater or equal to 5 for both groups. In cases where this is not guaranteed, Fisher’s exact test is recommended when strict type 1 error control is required.\nIf neither placebo or active comparator are specified, difference from 0 is assessed for each dose arm and Dunnett-adjusted calculations are not carried out.\nLast observation carried forward (LOCF), Per-protocol (Ignore), and missing data considered failure are available as ways to handle missingness in dichotomous frequentist calculations.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#variants", - "href": "documentation/v71/userguides/crm.html#variants", - "title": "FACTS Dose Escalation CRM", - "section": "7.5 Variants", - "text": "7.5 Variants\nOn this tab the user can specify that a number of design variants should be created. Currently the only design feature that can be changed is the sample size (maximum number of cohorts).\nIf “multiple variants” is checked then the user can specify that simulations setups should be created for each simulation scenario with versions of the design with different maximum numbers of cohorts.\nThe user enters the number of variants they wish to create. Then in the resulting table, enter different “Max Cohorts” for each variant.\nThese will then appear on the simulations tab.\nIf open enrolment is being used, then the enrolment cap is specified by the number of subjects.\nIf there are two groups then separate caps are specified for each group.\n\n\n\n\n\n\nFigure 33: The Variants tab, specifying 5 variants", + "objectID": "documentation/v71/userguides/core.html#time-to-event-frequentist-analysis", + "href": "documentation/v71/userguides/core.html#time-to-event-frequentist-analysis", + "title": "FACTS Core User Guide", + "section": "9.3 Time-to-Event Frequentist Analysis", + "text": "9.3 Time-to-Event Frequentist Analysis\nFor each simulated trial, the following frequentist analyses will be performed:\n\nDose-placebo comparisons based on log-rank test and the Cox proportional hazards model. Summaries include:\n\nThe log-rank and Wilcoxon test statistics and the corresponding p-values,\nEstimated hazard ratio and its confidence interval from Cox model,\nFor each dose its marginal probabilities of significance (the number of times it was significantly separated from placebo independent of whether any other doses were, based on the hazard ratio inference from the Cox model).\n\nMedian survival times based on the Kaplan-Meier method.\nFor the predictor, descriptive statistics are computes – a 7 number summary for a continuous predictor, percentages for the dichotomous predictor, and median time, average hazard, and a cox model with predictor as covariate are computed for a time to event predictor.\n\nThe following variations for adjusting the alpha level for multiple comparisons should be available using the user-specified 1-sided alpha: unadjusted, and Bonferonni adjusted.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#explicitly-defined", - "href": "documentation/v71/userguides/crm.html#explicitly-defined", - "title": "FACTS Dose Escalation CRM", - "section": "8.1 Explicitly Defined", - "text": "8.1 Explicitly Defined\nToxicity profiles may be added, deleted, and renamed using the table and corresponding buttons on the left hand side of the screen in Figure 35. The user enters the toxicity rate to simulate at each dose into the Probability of Toxicity column of the table, and the graphical representation of these toxicity values updates accordingly.\nThis form of toxicity profile is not available if the dose range is “finely spaced” – typically this means there are too many doses for it to be practicable to enter toxicity rates for all of them. When using “finely spaced” doses the toxicity rates to be simulated have to be specified using parametric models (see the next section).\n\n\n\n\n\n\nFigure 34: Explicitly defined toxicity - binary endpoint\n\n\n\nIf the design is using ordinal toxicity, the toxicity response rates can be specified either:\n\nOn the “Toxicity” tab by specifying the category 3 or greater toxicity rate at each dose and then two offsets – one for the category 2 or greater rate and one for the category 4 rate.\nOn the “Ordinal Toxicity” tab by separately specifying the toxicity rates for each category of toxicity at each dose.\n\nSpecifying offsets: to ensure that the specified category 3 rate plus the category 2 offset doesn’t sum to more than 1, or the category 3 rate plus the -ve category 4 offset sum to less than 0, the offsets are applied to the logit of the category 3 toxicity rate.\nThus for the category 2+ rate:\n\\[\nln(\\frac{p_{2+}}{1-p_{2+}}) = ln(\\frac{p_{3}}{1-p_{3}} + \\Delta_2)\n\\]\nwhere:\n\n\\(p_{2+}\\) is the probability of observing a category 2 or greater toxicity at a dose\n\\(p_3\\) is the probability of observing a category 3 or greater toxicity at a dose\n\\(\\Delta_2\\) is the difference in the log odds between the two probabilities\n\nThe offset is defined at the lowest dose and highest dose and then varied linearly with dose strength at the intermediate doses. The plot of the curve can either use Pr(Tox) or Log-odds(Tox) as the y-axis and dose strength or log(dose strength) as the x-axis. A graph is displayed of the toxicity rates that have been entered, and the category 2+ and category 4 toxicity rates if applicable. This graph, as with all graphs in the application, may be copied to the clipboard or to a file using the “right-click” menu.\n\n\n\n\n\n\nFigure 35: Virtual Subject Response – Explicitly-Defined – ordinal endpoint\n\n\n\n\n8.1.1 Explicitly defined – Ordinal Toxicity\nIf simulating ordinal toxicity an alternative option is to explicitly specify the rate at each toxicity level at each dose. This can be done under the Virtual Subject Response > Explicitly Defined > Ordinal Toxicity tab.\n\n\n\n\n\n\nFigure 36: Virtual Subject Response – Explicitly-Defined: Ordinal Toxicity tab\n\n\n\n\n\n8.1.2 Explicitly defined toxicity – when simulating 2 groups\nIf simulating toxicity as a binary outcome, when simulating 2 groups, the tab displays two Pr(Tox) columns, one for each group, and the user enters the toxicity rate to be simulated at each dose for each group.\n\n\n\n\n\n\nFigure 37: Explicitly defined toxicity - 2 groups\n\n\n\nIf simulating 2 groups and ordinal toxicity, then on the explicitly defined tab once again the tab displays two Pr(Tox) columns, one for each group, and the user enters the toxicity rate to be simulated at each dose for each group. As for a single group the Category 2 toxicity and Category 4 (if using) toxicity rates are defined by defining log odds offsets at the lowest and highest dose. Specification is limited to a single set of offsets that are applied to both groups.\n\n\n\n\n\n\nFigure 38: Explicitly defined toxicity - 2 groups and ordinal offsets\n\n\n\nAs in the single group case in addition to the Category 3 toxicity rates that are editable, columns showing the Pr(Tox 2+) and Pr(Tox 4) are shown, but these are not editable and derived from the Pr(Tox) rates and the offsets that have been specified. The ordinal toxicity rates are only shown for group 1.\n\n\n8.1.3 Explicitly defined – Ordinal Toxicity with 2 groups\nIf simulating ordinal toxicity an alternative option is to explicitly specify the rate at each toxicity level at each dose. This can be done under the Virtual Subject Response > Explicitly Defined > Ordinal Toxicity tab.\n\n\n\n\n\n\nFigure 39: Explicitly Defined, Ordinal Toxicity with 2 Groups\n\n\n\n\n\n8.1.4 Efficacy response profiles\nEntering efficacy response profiles is very similar to entering toxicity profiles. FACTS will construct scenarios to simulate of every combination of toxicity and efficacy response profiles.\n\n\n8.1.5 Explicitly Defined – Efficacy\nEfficacy profiles may be added, deleted, and renamed just like toxicity profiles. The user enters the efficacy rate to simulate at each dose into the Probability of Efficacy column of the table, and the graphical representation of these efficacy values updates accordingly.\nAs with toxicity this form of efficacy profile is not available if the dose range is “finely spaced” – typically this means there are too many doses for it to be practicable to enter efficacy rates for all of them. When using “finely spaced” doses the efficacy rates to be simulated have to be specified using parametric models (see the next section).\n\n\n\n\n\n\nFigure 40: Efficacy virtual subject response, explicitly defined\n\n\n\n\n\n8.1.6 Explicitly Defined – Efficacy with two groups\nIf the design included 2 groups, when explicitly defining an efficacy response profile, there is simply a second column of efficacy response rates to enter:\n\n\n\n\n\n\nFigure 41: Explicity defined efficacy response profile with 2 groups", + "objectID": "documentation/v71/userguides/core.html#imputation", + "href": "documentation/v71/userguides/core.html#imputation", + "title": "FACTS Core User Guide", + "section": "10.1 Imputation", + "text": "10.1 Imputation\nUnless a deterministic method is used such as LOCF or BOCF, longitudinal models inform the dose response estimates by using the longitudinal model to stochastically impute subjects’ final endpoint data when it’s not been directly observed.\nFirst, data from subjects with intermediate and final observations is used to estimate the parameters of the longitudinal models.\n\nSubjects with missing final data have final data sampled from the posterior probability distribution of the longitudinal model given the subjects most recent intermediate visit (or in some models, all their available intermediate visit data). Subjects with no final or intermediate data have final data sampled from the posterior probability distribution of the dose response model given the dose arm the subject was allocated to.\n\nThe dose response model is then re-estimated using all the data.\n\nThis process is then repeated on successive iterations of the MCMC sampling loop. Thus the imputed values are imputed with both the uncertainty in the longitudinal model and the uncertainty in the estimates of the parameters of that model.\nIt is actually better not to update both the longitudinal model parameters and the dose response model parameters every MCMC step, but allow the model parameters to converge slightly before imputing the missing data again. This can be done on the MCMC settings control on the Simulation tab and setting the “Samples per Imputation” parameter. As a rough guide, if it at some early interims > 5% of the data being analyzed will be imputed, a value in the range 2 to 10 is recommended to avoid underestimating the uncertainty. A higher number should be used the greater the proportion of imputed data.\nA similar procedure is used when imputing event times based on a predictor endpoint in FACTS Core Time-to-Event.\nNote: FACTS is not fitting a joint Bayesian model of the longitudinal and dose response models. This would require a full MCMC fit of one model for every MCMC step of the other. Thus, if taking 2,500 samples, we would require a total of 2,5002 samples. This would make running simulations with longitudinal model prohibitively expensive.[14] Rather in FACTS the LM is a “working mode” to improve our estimate of the dose response model.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#sec-parametric", - "href": "documentation/v71/userguides/crm.html#sec-parametric", - "title": "FACTS Dose Escalation CRM", - "section": "8.2 Parametric", - "text": "8.2 Parametric\nToxicity scenarios may be added, deleted, and renamed using the table and corresponding buttons on the left hand side of the screen. The user selects the model to use to determine the toxicity rate to simulate at each dose, and specifies the values of the model’s parameters. The graphical representation of these toxicity values updates accordingly.\nThe graph may be copied using the context menu functionality described in the previous section.\nFour models are available:\n\nLogistic: the probability of toxicity at dose x is given by: \\(P_x=\\frac{1}{1+e^{-s(x-x_{50})}}\\) with user specified parameters, \\(s\\) (slope) and \\(x_{50}\\) (the ED50 dose). Note this can be fitted exactly by the two parameter logistic with linear effective doses \\(\\hat{x}=x-x_{ref}\\) when \\(\\beta=s\\) and \\(\\alpha=\\beta*(x_{ref}-x_{50})\\)\nEmax: the probability of toxicity at dose \\(x\\) is given by: \\(P_x=\\frac{x}{x+x_{50}}\\) with user specified parameter \\(x_{50}\\).\nLog Logistic: the probability of toxicity at dose \\(x\\) is given by: \\(P_x=\\frac{1}{1+e^{-s(ln(x)-ln(x_{50}))}}\\) with user specified parameters, \\(s\\) (slope) and \\(x_{50}\\) (the ED50 dose). Note this can be fitted exactly by the two parameter logistic with log effective doses \\(\\hat{x}=ln(\\frac{x}{x_{ref}})\\) when \\(\\beta=s\\) and \\(\\alpha=\\beta*ln(\\frac{x_{ref}}{x_{50}})\\)\nPiecewise linear: with the probability of toxicity specified at a series of knots, with the probability linearly interpolated between knots.\n\n\n\n\n\n\n\nFigure 42: Virtual Subject Response - Parametric Toxicity tab\n\n\n\nIf Ordinal toxicity is being simulated then the category 2 and greater toxicity rates and category 4 toxicity rates are specified using the logit offset methods as on the Explicitly-Defined > Toxicity tab.\n\n\n\n\n\n\nFigure 43: Virtual Subject Response - Parametric Toxicity tab with Ordinal toxicity\n\n\n\nIf Ordinal Toxicity and 2 groups are being simulated then both the Cat 2+ and Cat 4 toxicities and the Group 2 toxicities are defined using the logit offset methods.\n\n\n\n\n\n\nFigure 44: Parametric definition of ordinal toxicity response with 2 groups\n\n\n\n\n8.2.1 Parametric efficacy response\nParametric efficacy response profiles function exactly like toxicity profiles, with the same parametric models to choose from and if 2 groups are present the response of the second group is again defined by 2 log-odds offsets, one at the lowest dose and one at the highest.\n\n\n\n\n\n\nFigure 45: Parametric efficacy response profile", + "objectID": "documentation/v71/userguides/core.html#how-many-longitudinal-models", + "href": "documentation/v71/userguides/core.html#how-many-longitudinal-models", + "title": "FACTS Core User Guide", + "section": "10.2 How many longitudinal models?", + "text": "10.2 How many longitudinal models?\nWhen specifying a longitudinal model in FACTS, the user must clarify whether the longitudinal model is shared across all doses, or if different arms are to estimate different functions connecting early endpoints to the final endpoint.\nThe options that may be selected for the number of model instances are:\n\n“Single model for all arms” – just one set of longitudinal parameters is estimated using all the subject data regardless of their treatment.\n“Model control separately” – two sets of longitudinal parameters are estimated, one using data from just those subjects on the control arm, and the other using all the subject data from all the other arms.\n“Model comparator separately” (only available if there is an active comparator arm) - two sets of longitudinal parameters are estimated, one using data from just those subjects on the active comparator arm, and the other using all the subject data from all the other arms (control and active treatments).\n“Model control and comparator separately” (only available if there is an active comparator arm) - three sets of longitudinal parameters are estimated, one using data from just those subjects on the active comparator arm, one using data from just those subjects on the control arm, and the third using all the subject data from all the other arms.\n“Model all arms separately” – a set of longitudinal parameters is independently estimated separately for each arm, each set estimated just using the data available from the subjects on that arm.\n\nThe fewer models used, the more data is pooled, the more precisely the model parameters can be estimated, and the more informative the intermediate data can be. Pooling data assumes that subjects in different groups have the same longitudinal profile, although they may still have different magnitude or probability of response (estimated by Dose Response Model).\nIf the response profile could be different on different treatment arms – for example, if subjects on control recover constantly over time, but those on an effective dose of the study drug recover very quickly early on, and more gradually later in their follow-up - a longitudinal model based on pooled data would tend to over-estimate the final endpoint of subjects on an effective dose of the study drug when only their early data was available. In a case like that, it would be better to use separate models. If the rapid early response was likely on all study drug treatment arms, then possibly use “model control separately.” If, however, the rapid response will only be seen on some study drug arms then use “model all arms separately”.\nIn addition to declaring how many longitudinal models should be estimated, when there is more than one model instance the user must declare if the prior distributions should be specified differently across each model instance or not. The options that may be selected for prior specification (for all LMs but linear regression) are:\n\nSame priors across all model instances\n\nEach instance of the model has identical prior distributions on its parameters. Estimation is still performed independently on each model instance.\n\nSpecify priors per model instance\n\nEach instance of the model has its own priors that may vary across instances.\n\n\nThe linear regression longitudinal model has a different parameter set estimated for each visit, so its prior specification rules are slightly different. See the linear regression section below for specifics about prior specification specific to this model.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#external", - "href": "documentation/v71/userguides/crm.html#external", - "title": "FACTS Dose Escalation CRM", - "section": "8.3 External", - "text": "8.3 External\nSubject response data may be simulated from a PK-PD model in place of, or in addition to, choosing a response model from FACTS. The importing of subject response data (which must be in the form specified in the System Requirements Document) may be done from the External Files sub-tab depicted below (Figure 46).\nThe supplied data should be in the following format: an ascii file with data in comma separated value format with the following columns:\n\nPatient id\nDose index (1, 2, 3,… if a Control is to be included it should be index 0) this is not the user settable dose name or dose level\nToxicity (0,1)\nEfficacy (0. 1) even if efficacy not being simulated this value must be present\nGroup (*1, 2) only required if groups are being simulated\n\nThe GUI requires that the file name has a “.dat” suffix.\nSimulated subjects will be drawn from this supplied list, with replacement, to provide the simulated response values.\nTo import an external file, the user must first add a scenario to the table. After adding a scenario, the user must click “Browse” to locate the externally simulated data via a standard file browser dialog.\n\n\n\n\n\n\nFigure 46: External Data", + "objectID": "documentation/v71/userguides/core.html#longitudinal-models-for-a-continuous-endpoint", + "href": "documentation/v71/userguides/core.html#longitudinal-models-for-a-continuous-endpoint", + "title": "FACTS Core User Guide", + "section": "10.3 Longitudinal Models for a Continuous Endpoint", + "text": "10.3 Longitudinal Models for a Continuous Endpoint\n\n10.3.1 LOCF (Last Observation Carried Forward)\nThe simplest possible longitudinal model. If {yit} is the set of observed responses from early visits, and yitm is the last observed value of y*i**t, then the LOCF model for the final endpoint Yi* is\nYi|{yit} = yitm\nIn the continuous engine tm can be any earlier observed visit including the baseline value.\n\n\n10.3.2 Linear Regression\nThe linear regression model fits a simple linear model from the data at each visit with the final visit\nYi|yit ∼ αt + βtyit + N(0, λt2)\nThe parameter αt is the intercept of the model for visit t, and the parameter βt is a multiplicative modifier (slope) of the response observed longitudinal at visit t to adjust the prediction of the final endpoint.\nImputation of the final endpoint value for a subject using the linear regression longitudinal model is based on only the latest observed visit’s endpoint value.\nThe default setting of “Same priors across all model instances and visits,” implies that each parameter α, β, and λ have the same prior for all t. Estimation of those parameters is still done independently for each model instance. The one prior across all model instance are formulated as:\nαt ∼ N(αμ, ασ2)\nβt ∼ N(βμ, βσ2)\n\\[\\lambda\\_{t}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n}}{2},\\frac{\\lambda\\_{\\mu}^{2}\\lambda\\_{n}}{2} \\right)\\]\nThe above prior formulation may not be desirable if specifying priors that are not extremely diffuse – especially on the β parameters. Instead, selecting “Specify priors per visit across all model instances,” will share the prior specification across all instances of the model, but allows for different priors to be put on the parameters associated with each visit. The user inputted prior parameters are now subscripted with t to denote the visit they correspond to. These priors apply to all model instances:\nαt ∼ N(αμt, ασt2)\nβt ∼ N(βμt, βσt2)\n\\[\\lambda\\_{t}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n\\_{t}}}{2},\\frac{\\lambda\\_{\\mu\\_{t}}^{2}\\lambda\\_{n\\_{t}}}{2} \\right)\\]\nIt is also possible to specify priors “Per model instance and visit,” in which every visit has separate priors, and those differing priors vary across model instances. This is the most flexible prior specification method. The user inputted prior parameters are now subscripted by both t for visit and i for model instance.\nαti ∼ N(αμti, ασ*t**i*2)\nβti ∼ N(βi, βσti2)\n\\[\\lambda\\_{ti}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n\\_{ti}}}{2},\\frac{\\lambda\\_{\\mu\\_{ti}}^{2}\\lambda\\_{n\\_{ti}}}{2} \\right)\\]\nA potential starting place for non-informative prior values would be\n\nα mean of 0, SD >= largest expected response\nβ mean of either 0 or (final visit time / early visit time), SD >= largest expected ratio of final visit to first visit\nλ mean of expected SD of the endpoint (‘sigma’), weight of 1. The variability of the prediction from the longitudinal model (based on an observed intermediate response) should be less than that based solely on the treatment allocation, thus this is a weakly pessimistic prior on the effectiveness of the longitudinal model that should be quickly overwhelmed by the data.\n\nThis model is easy to understand and can be used even if there is only one visit, but doesn’t get more powerful if there are more visits. Its power will depend on the degree of correlation between the intermediate visit response and the final response.\n\n\n10.3.3 Time Course Hierarchical\nThe Time Course Hierarchical models the relationship between subjects’ early responses and their final response. It incorporates a per-subject offset from the mean response and a scaling factor from each visit to the final endpoint, but with no model of the change from visit-to-visit.\nThe response at the tth visit for the ith subject, having been randomized to the d*t**h* dose is modeled as:\ny*i**t ∼ eαt(θd + δi) + N(0, λt*2)\nThe imputed final response (visit T) for the ith subject, having been randomized to the dth dose is modeled as:\nY*i**T ∼ θd + δi + N(0, λT*2)\n(i.e. αT is 0).\nThe model parameters can be interpreted as follows:\nθd is the estimated mean response at the final visit in dose d from the dose response model.\n\nδi is the estimated patient level random effect around the mean final response (θd) for the dose d that patient i is randomized to.\nαt is a scaling parameter that determines the proportion of the final response that is observable at visit t. A value of αt = 0 indicates that the expected value of early visit t is equal to the estimated final visit mean θd. A value of αt = −0.69315 indicates that the expected value of early visit t is 50% of the estimated final visit mean θd.\nλt2 is the variance of the endpoint around the estimated mean response at visit t.\n\nThe prior for αt is a normal distribution with a user specified the mean and standard deviation:\nαt ∼ N(αμ, ασ2),\nThe prior for the δi terms is a normal distribution with a mean of 0 and variance τ2.\nδi ∼ N(0, τ2)\nτ2 is estimated as part of the longitudinal model, and has an inverse gamma prior distribution with prior central value τμ and weight (in terms of “equivalent number of observations”) τn:\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\\\\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nThe prior for the λt2 terms is an inverse gamma distribution with prior central value λμ and weight (in terms of “equivalent number of observations”) λn:\n\\[\\lambda\\_{t}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n}}{2},\\frac{\\lambda\\_{\\mu}^{2}\\lambda\\_{n}}{2} \\right)\\]\nA reasonable starting place for prior values would be\n\nαt mean of -2, SD of 2, … so the prior ~70% interval for αt is between -4 and 0 (+/1 1 SD) and thus the prior 70% interval for eαt to be between 0.02 and 1.\nτ mean set to the expected SD of the endpoint (‘sigma’), with a weight of 1.\nλt mean set to the expected SD of the endpoint (‘sigma’), with weight of 1.\nWe would expect τ2 + λ2 ≈ σ2, thus to specify a prior mean of σ for each with a weight of 1 is a weakly pessimistic prior that should be quickly overwhelmed by the data.\n\nThis model is useful if there is thought to be a significant per-subject component to the response that should be manifest at the intermediate visits, and sufficient visits for the per-subject component to be estimated.\n\n\n10.3.4 Kernel Density\nThe Kernel Density Model longitudinal model is a non-parametric re-sampling approach that is ideal for circumstances where the relationship between the interim time and the final endpoint is not known or not canonical.\nThe procedure is as follows. Assume an interim value for patient i at time t, Y*i**t. Patient i* does not have an observed final endpoint at time T, so one is to be imputed. Let (X1t, X1T), …, (Xnt, XnT) be the set of values for the previous subjects for whom there exists an interim value X*t and final value X*T.\nTo impute a value of YiT given Yit, a pair (Xkt, XkT) is selected with probability based on the pair’s time t visit response’s proximity to the observed Y*i**t*:\n\\[\\Pr\\left( Selecting\\\\\\left( X\\_{kt},\\\\X\\_{kT} \\right) \\right) = \\frac{\\exp\\left( - \\frac{1}{2h\\_{X\\_{t}}^{2}}\\left( Y\\_{it} - X\\_{kt} \\right)^{2} \\right)}{\\sum\\_{k = 1}^{n}{\\exp\\left( - \\frac{1}{2h\\_{X\\_{t}}^{2}}\\left( Y\\_{it} - X\\_{kt} \\right)^{2} \\right)}}\\]\nThen, a value of YiT is imputed from the following distribution, which uses the selected pair’s final endpoint response XkT:\nYiT ∼ N(XkT, hXT2)\nThe bandwidths hXt and hXT are selected based on the criterion given by Scott (1992). That is,\n\\[h\\_{X\\_{j}} = \\sigma\\_{X\\_{j}}\\\\\\left( 1 - \\rho^{2} \\right)^{\\frac{5}{12}}\\\\\\left( 1 + \\\\\\frac{\\rho^{2}}{2} \\right)^{- \\frac{1}{6}}{\\\\n}^{- \\frac{1}{6}}\\\\\\\\\\\\\\\\\\\\\\\\for\\\\j = t\\\\and\\\\T\\]\nwhere σXj is the standard deviation of the observed responses at time j, n is the number of pairs (X*t, X*T) that were chosen between, and ρ is the correlation coefficient between Xt and XT in the pairs (X1t, X1T), …, (Xnt, XnT).\nThe Kernel Density model does not take prior distributions as input. So long as each early visit has more subjects with an observed early response and final response than the value entered in “Kernel minimum number of subjects:” then this algorithm runs without regard for user input.\nIf any visit has fewer subjects with early data and final data than the value of “Kernel minimum number of subjects:”, then instead of calculating the values of hXt or hXT the input values of Kernel bandwidth and standard deviation of prior mean are used.\nPossible starting values for these parameters are:\n\nhx and hy the expected SD of the endpoint (‘sigma’)\nThe minimum number of subjects completed: 6\n\nThe Kernel Density model is effective and flexible with no model assumptions, but its computational overhead is large. Simulations may take ~10 times longer to run, and having no prior model there has to be ‘in trial’ data before it can come into play.\n\n\n10.3.5 ITP\nThe ITP (Integrated Two-component Prediction) model fits an observation for patient i on dose d at visit t as:\n\\[y\\_{idt} = \\left( \\theta\\_{d} + s\\_{id} + \\epsilon\\_{idt} \\right)\\left( \\frac{1 - \\text{exp}\\left( kx\\_{idt} \\right)}{1 - \\text{exp}(kX)} \\right)\\]\nwhere ϵidt ∼ N(0, λ2)\ns*i**d ∼ N(0, τ*2)\nand θd is the mean estimate of the final endpoint for dose d using all complete and partial data and assuming an independent dose response model on the doses. s*i**d is a subject specific random effect, k* is a shape parameter, xidt is the time yidt is observed, X is the time to final endpoint, and each ϵidt is a residual error.\nThe ITP model is similar to the Time Course Hierarchical above in that both models estimate subject specific component of the response. The biggest difference between the two is that the ITP models the response change over time as a parametric function based on the parameter k, rather than having a separately estimated eαt for each visit.\nThe shape parameter k determines the rate at which the final endpoint’s eventual effect is observed during a subject’s follow-up. A value of k = 0 indicates that the proportion of effect observed moves linearly with time. A value of k < 0 means that the eventual final effect is observed earlier in follow-up and plateaus off as time moves towards the final endpoint. A value of k > 0 indicates that less of the total final endpoint effect is observed early in follow up, but as time approaches the final endpoint time the proportion of the effect observed increases rapidly. Values of k less than 0 tend to be more common than values of k greater than 0. See the figure below for a visualization of the different response-over-time curves that can be estimated with the ITP model.\n\nThe priors for the parameters in the ITP model are:\nk ∼ N(μk, σk)\nθd ∼ N(μθd, σθd2)\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\\\\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\n\\[\\lambda^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n}}{2},\\\\\\frac{\\lambda\\_{\\mu}^{2}\\lambda\\_{n}}{2} \\right)\\]\nA reasonable starting place for prior values would be:\n\nθd mean of the expected mean improvement from baseline on the Control arm, with SD greater than or equal to the expected treatment effect size.\nk a mean of 0 and SD of 2, if subject improvement is expected to be rapid and then diminishing, the prior mean might be -0.5 or -1, if subject improvement is expected to be initially slow or non-existent then increasing, the prior mean might be 0.5 or 1.\nτ mean set to the expected SD of the endpoint (“sigma”), with a weight of 1.\nλ mean set to the expected SD of the endpoint (“sigma”), with a weight of 1.\n\nThe ITP model implies that the variance of the observations shrinks towards 0 with the mean (so early visits have reduced expected responses and variances). The ITP model may result in biased estimates of θd and/or the variance terms τ2 and λ2 if the mean-variance relationship assumed by the ITP model is not present in the observed data. If the model assumptions are correct this can be a very effective longitudinal model.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#x-hats", - "href": "documentation/v71/userguides/crm.html#x-hats", - "title": "FACTS Dose Escalation CRM", - "section": "9.1 X-Hats", - "text": "9.1 X-Hats\nOn this tab the user specifies the reference dose \\(d^*\\) for use in calculating the adjusted dose value (the “x-hat” values). The default value to use is Median dose is reference, this uses the median of the dose range for the reference dose, minimizing the correlation in the sampled values of \\(\\alpha\\) and \\(\\beta\\). Note though that when allocation is restricted to explicit doses it is also recommended that the value of the reference dose is not the same as an actual dose that can be used (at this dose \\(\\hat{x}\\) will be 0 and the data on this dose can have undue weight on the estimate of \\(\\alpha\\)).\nDifferent reference doses can easily be used however – between the two doses thought most likely to be MTD, just below the lowest dose, just above the highest dose. The bi-variate Normal prior for \\((\\alpha, ln(\\beta))\\) will need to be recalibrated to take the change into account.\nX-Hats are log(dose strength) allows the user to select between:\n\nlinear effective dose \\(\\hat{x}_j = d_j - d^*\\)\n\\(log(\\hat{x}_j) = ln(\\frac{d_j}{d^*})\\)\n\nIf you have entered linear dose strengths for the doses (1, 2, 3, 4, … or 100, 150, 200, 250, …) then use the linear effective dose. If however the dose strengths that have been entered are non-linear (12.5, 25, 50, 100, …) but expected to be roughly linear in effect, then use the log of the dose ratio.\n\n\n\n\n\n\nFigure 47: Specifying the dose transformation - the “x-hats”.\n\n\n\n\n9.1.1 The Pro’s & Con’s of using the median dose as the reference dose\nThe reason the median dose is recommended as the reference is that this minimizes the correlation in the fit of \\(\\alpha\\) and \\(ln(\\beta)\\), the parameters of the BLRM, and it maximises the flexibility of the fit of the model over the dose range.\nHowever care needs to be taken that the prior on \\(\\alpha\\) is not more restrictive than that on \\(ln(\\beta)\\) in order to avoid a phenomena observed when preparing tutorials: observing “no toxicities” below the reference dose resulted in a model with increased probability of toxicity above the reference dose compared to observing a toxicity below the reference dose. For a given value of \\(\\alpha\\), higher values of \\(ln(\\beta)\\) correspond to lower toxicity below the reference dose – as the \\(\\hat{x}\\)̂ values are -ve below the reference dose. The fitted curve thus “pivots” about the value of \\(\\alpha\\) at the reference dose.\nThere are two solutions to this:\n\nmove the reference dose, which involves a choice between two options\n\nmoving it to the first dose or below (normally allowing a relatively constrained prior around a low value for \\(\\alpha\\)),\nor to the highest dose or above (with a relatively uninformative prior).\n\nWe have seen both solutions perform well against the chosen scenarios – but the choice needs checking and refining with a full range of scenarios that represent the full uncertainty in the true response.\nor modify the priors on \\(\\alpha\\) and \\(ln(\\beta)\\) making the prior on \\(\\alpha\\) less informative (in particular increase the probability of low values) and make the prior on \\(ln(\\beta)\\) more informative (in particular lower the probability of high values less). Because the prior distribution on \\(\\beta\\), is on \\(ln(\\beta)\\), it is easy to make large values of \\(\\beta\\) more probable than intended.", + "objectID": "documentation/v71/userguides/core.html#longitudinal-models-for-a-dichotomous-endpoint", + "href": "documentation/v71/userguides/core.html#longitudinal-models-for-a-dichotomous-endpoint", + "title": "FACTS Core User Guide", + "section": "10.4 Longitudinal Models for a Dichotomous Endpoint", + "text": "10.4 Longitudinal Models for a Dichotomous Endpoint\n\n10.4.1 LOCF (Last Observation Carried Forward)\nThe simplest possible longitudinal model. If {yit} is the set of observed responses from early visits, and yitm is the last observed value of y*i**t, then the LOCF model for the final endpoint Yi* is\nYi|{yit} = yitm\n\n\n10.4.2 Beta Binomial\nThe Beta Binomial longitudinal model imputes a patient’s final endpoint given their most recent observed response.\nThe final endpoint response Yi is modeled as:\nYi ∼ Bernoulli(πtyit)\nwhere πtyit is the probability that a patient is a response at the final endpoint given its early observed endpoint at time t is y*i**t*,\nπtyit = Pr (Yi = 1 | yit) ∼ Beta(αtyit, βtyit)\nWe use the set cardinality operator |…| to obtain the posterior distributions of αt* and βt* as:\nαt0 = αμ0 + |Yi = 1, y*i**t* = 0|\nβt0 = βμ0 + |Yi = 0, y*i**t* = 0|\nαt1 = αμ1 + |Yi = 1, y*i**t* = 1|\nβt1 = βμ1 + |Yi = 0, y*i**t* = 1|\ni.e. a prior value (αμ0, αμ1, βμ0, βμ1) plus the number of subjects for which the final response is known to be 1 for αtx (or 0 for βtx) and the response at time t is x.\nThe αtx and βtx parameters are independently estimated using only patients in their model instance, and may or not have identical priors αμ* and βμ* depending on the Model Priors selection in FACTS. A common non-informative prior for the πt0 and πt1 parameters is Beta(1,1).\n\n\n10.4.3 Logistic regression\nThe Logistic regression longitudinal model works similarly to the Beta Binomial imputation model. The difference is in the method of modeling the probability of a transition from an interim visit to the final visit Pr (Yi = 1|y*i**t*). Like the Beta Binomial model, the logistic regression model imputes a patient’s final endpoint given their most recent observed response.\nThe final endpoint response Yi is modeled as:\nYi ∼ Bernoulli(πtyit)\nwhere πtyit is the probability of a response at the final endpoint time given that its early observed endpoint at time t is y*i**t. Then, we define the parameter \\(\\theta\\_{ty\\_{it}} = logit\\left( \\pi\\_{ty\\_{it}} \\right) = \\log\\left( \\frac{\\pi\\_{ty\\_{it}}}{1 - \\pi\\_{ty\\_{it}}} \\right)\\). The priors on θt0 and θt*1 are:\nθt0 ∼ N(μ0, σ02)\nθt1 ∼ N(μ1, σ12)\nThe model computes the posterior distribution of θt0 and θt1 using all patients in arms belonging to the model instance that have observed endpoint values at time t and the final endpoint time T.\nThe priors on θt0 and θt1 may be shared across model instances and/or visits depending on the selection made in the Model Priors section of the FACTS Logistic regression Longitudinal model page.\nA possible starting place for non-informative priors in this model would be: μ = 0,  σ = 2. A weakly informative set of priors that an early response makes a final response more likely could be θt0 ∼ N(−.75, 1.252) and θt1 ∼ N(0.75, 1.252).\n\n\n10.4.4 Restricted Markov Model (Absorbing Markov Chain)\nThe Absorbing Markov Chain model assumes that at each visit a subject is in one of three states – responder (1), stable (S), or failure (0). The responder and failure states are absorbing, meaning that once a patient has entered one of those states they must remain in that state for the remainder of the visits. Patients in the stable state may move to a responder or a failure in subsequent visits.\nUnlike most other longitudinal models in FACTS, the Restricted Markov Model estimates the probability of a result at a visit based on the visit right before it, rather than predicting directly to the final endpoint from the early visit.\nPr (yit = n |yi, t − 1  = S) ∼ Dirichlet({α0t, α1t, αSt})   for t ≥ 2\nWhere n can be 0, 1, or S, denoting the probability of going to the Fail state, the Responder state, or the Stable state at visit t from the Stable state at visit t − 1. t must be greater than or equal to 2, because we do not impute the first visit – a subject missing visit 1 and all visits after does not contribute to the longitudinal model or dose response model.\nThe priors for the α parameters are specified in terms of the prior number of transitions from Stable at t − 1 to each different state at time t. For example, if the prior value for the parameter γ13 is 2, we are putting a priori information into the Dirichlet distribution suggesting that 2 patients transitioned from Stable at visit 2 to Responders at visit 3. Specified priors can either be common or different across model instances based on user specification.\nThe parameters defining the posterior distribution of the state probabilities are available in closed form as:\nα0t = γ0t + |y*i**t = 0, yi, t − 1 = S*|\nαSt = γSt + |y*i**t = S, yi, t − 1 = S*|\nα1t = γ1t + |y*i**t = 1, yi, t − 1 = S*|\nTo create a dichotomous endpoint, the user specifies in the Study > Study Info > Design Options section whether patients remaining in a stable state at the final visit should be dichotomized as responders or failures.\n\n\n10.4.5 Dichotomous Endpoint: Dichotomized Continuous Longitudinal Model\nThe user may select (on the study tab) to assume that the dichotomous final endpoint is generated by observed continuous longitudinal data and then dichotomizing the final endpoint. The user specifies the dichotomization thresholds and whether a response occurs for values above or below the threshold. If the user selects this option, then the user may select any of the continuous longitudinal models specified in the Continuous Longitudinal Models section above. The engine will impute incomplete subjects according to the continuous model, resulting in a continuous imputed final endpoint. The imputed dichotomous final endpoint is then simply the dichotomized version of the continuous imputation.\nAll priors and methods are identical to the continuous longitudinal models mentioned above.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/crm.html#toxicity-response", - "href": "documentation/v71/userguides/crm.html#toxicity-response", - "title": "FACTS Dose Escalation CRM", - "section": "9.2 Toxicity Response", - "text": "9.2 Toxicity Response\nThe parameters that can be specified on this page are:\n\nThe parameters of the bivariate Normal distribution for \\(\\alpha\\) and \\(ln(\\beta)\\). Specifying the mean and standard deviation of \\(\\alpha\\) \\((\\mu_{\\alpha}, \\sigma_{\\alpha})\\), and \\(ln(\\beta)\\) \\((\\mu_{ln(\\beta)},\\sigma_{ln(\\beta)})\\) and the correlation coefficient \\(\\rho\\).\n\nIf ordinal toxicity is being simulated, it is possible to model the ordinal toxicity, specifying the mean and standard deviation of \\(\\alpha_2\\) and \\(\\alpha_4\\). These priors are separate from the \\(\\alpha_3\\) and \\(ln(\\beta)\\) prior, there is no correlation term in the prior. There is the constraint in the model that \\(\\alpha_2 > \\alpha_3 > \\alpha_4\\).\nUse fixed Alpha: the value of Alpha can be fixed to allow the N-CRM model to behave like the traditional CRM models. [Where \\(\\alpha\\) was set to 3 and the reference dose is set above the top of the available dose range]\n\n\nRather than entering the priors directly, they can be derived based on indirect prior information or beliefs, see ‘Deriving the Prior’ below.\n\nThe Minimum and Maximum rates that the model is to be fitted too. The model fits the range \\((0,1)\\), asymptotically approaching each limit as the adjusted dose value tends to \\(-\\infty\\) or \\(+\\infty\\). By specifying an alternative minimum and maximum, inside the range \\((0,1)\\), the user can have the model scaled to fit data to fit event rates where the asymptotic rates are not \\(0\\) or \\(1\\). For instance if the event being observed has a non-zero background rate (probability of being observed in placebo treated subjects), then the model may fit better if the minimum is set to the lower limit of this expected rate. Similarly if, even at the most toxic dose the event being observed is only expected to effect a proportion of subjects, the model may fit better if the maximum is set to the upper limit of this expected rate.\nIf a control arm is present, the user can specify to have this modelled separately, and if so the user specifies the parameters for a prior Beta distribution – in terms of numbers of prior observations on control of subjects with and without a toxicity.\nGroup 2 priors: if a second ‘Group’ is being simulated – whether this is a subset of subjects, or a modified treatment that subjects can be randomized to, then the BLRM is jointly fitted to the responses for both groups, with group 2 having offsets \\(a\\) and \\(b\\) from the first group’s \\(\\alpha\\) and \\(\\beta\\). The priors for \\(a\\) and \\(b\\) can be full bivariate Normal or can use constraints such as \\(b = 1\\), or \\(a > 0\\) or \\(a < 0\\).\n\n\n\n\n\n\n\nFigure 48\n\n\n\n\n9.2.1 Deriving the prior\nThe priors of \\(\\alpha\\) and \\(ln(\\beta)\\), can be specified directly or derived in one of four ways. When entered explicitly, the user specifies the parameters of the prior bivariate-normal distribution for \\(\\alpha\\) and \\(ln(\\beta)\\): the means, standard deviations and the correlation term \\(\\rho\\).\nAlternatively, the user may click the ‘derive prior’ button and select from:\n\nQuantiles at the lowest and highest dose: (based on the “uninformative prior” given in the paper (Neuenschwander, Branson, and Gsponer 2008), for details see this section) - the user specifies the probability of an unacceptable toxicity at the lowest dose, and the probability of under-dosing at the highest dose (0.1 for both is the default, and 0.05 for both is the value used in the paper). Optionally the probability that toxicity is less than the mid-point of the target toxicity band at the median dose can be specified. (Prior to FACTS 6.5 this third data point was not optional and constrained to be at the reference dose, but this had problems if the reference dose was not the media dose – it might also be the lowest dose for example).\nNote this method does not work so well if the reference dose is outside the dose range.\n\n\n\n\n\n\nFigure 49\n\n\n\nScenarios: the model is fitted to each of the toxicity response scenarios (MLE), the parameters of the bivariate normal are then calculated from resulting set of pairs of values for \\(\\alpha\\) and \\(ln(\\beta)\\).\n\n\n\n\n\n\nFigure 50\n\n\n\nSpecific quantiles: The user selects which doses and toxicity rates to provide an expectation – a prior probability that the toxicity rate on the dose will be the specified rate or less. At least 3 such expectations using at least 2 different doses strengths must be supplied. If a large number of specific quantiles are specified (e.g. reproducing the all quantiles method) the large number of different beta distributions sampled from, with the monotonicity constraint applied, results in losing too much variability. So this should only be used quantiles specified at 2-4 doses.\n\n\n\n\n\n\n\nFigure 51\n\n\n\n\nAll quantiles: the user specifies the prior expected toxicity rate at the 2.5%, 50% and 97% quantiles for each dose. (Only available when using explicitly defined doses, not a continuous dose range). Note that using Create Prior with this option will require the facts file to be saved and for there to be at least one virtual subject response profile.\n\n\n\n\n\n\n\nFigure 52\n\n\n\nIn all cases once prior values have been derived they are displayed along with a graph of 100 sampled curves from the prior. The user can accept the values, change derivation method, or cancel the derivation.\nThe plot of the samples can either be viewed as Pr(Tox) or Log-odds(Tox) vs relative dose (“x-hat”).\n\n\n9.2.2 Derivation of the Prior from Quantiles\nDerivation of the parameters of the bivariate Normal prior for \\(\\alpha\\) and \\(ln(\\beta)\\)) in the Quantiles at lowest and highest dose, Specific quantiles and All quantiles cases:\n\nMinimally informative unimodal Beta distributions are fitted for each of the doses where a prior expectation of a toxicity has been specified. For doses where no prior expectation has been specified, the median expected toxicity rate are derived by assuming that the median expected toxicity is linear in log dose on the logit scale, and again a minimally informative unimodal Beta distribution is fitted with the same median.\nPreviously and following (Neuenschwander, Branson, and Gsponer 2008), the parameters of the bivariate Normal distribution were found using a stochastic fit to the prior expectations of toxicity, minimizing the error in the prior toxicity rates at the 2.5%, 50% and 97.5% quantiles. This is still used in the All quantiles and Legacy prior cases. However experience with this method with the standard priors (previously called “uninformative”) showed that it yielded priors with too little uncertainty in the \\(ln(\\beta)\\)) and too high a value for the correlation parameter for many cases and certainly for the prior to be called “uninformative”.\nConsequently, in the Quantiles at lowest and highest dose and Specific quantiles cases, the prior is now derived by sampling from the minimally informative unimodal Beta distributions, and fitting the model to each set of sampled toxicity rates. The parameters of the bivariate normal are then calculated from resulting set of pairs of values for \\(\\alpha\\) and \\(ln(\\beta)\\).\n\nIf a control arm has been included, it may be included in the model, or modelled separately using a beta-binomial model, the user specifies the prior values for the Beta distribution.", + "objectID": "documentation/v71/userguides/core.html#time-to-event-predictor-models", + "href": "documentation/v71/userguides/core.html#time-to-event-predictor-models", + "title": "FACTS Core User Guide", + "section": "10.5 Time-to-Event Predictor Models", + "text": "10.5 Time-to-Event Predictor Models\nFor all predictors (Z) for time to event endpoints, the engine estimates both a marginal distribution (normal mean and variance for continuous, probability of response for dichotomous, and a piecewise exponential hazard model for time to event predictors) and a working model relating the predictor to the final endpoint. The marginal distribution is used to impute predictors for subjects lacking an observed predictor value and may also be used for stopping (see section on stopping). The working model is used to impute final endpoints for subjects lacking a final endpoint. For subject missing both a predictor and final endpoint, the predictor is imputed first from its marginal distribution, and then the final endpoint is imputed conditionally on the predictor Z.\n\n10.5.0.1 Continuous Predictor\nWithin each dose (including control and active comparator), the marginal distribution of Z is a normal distribution with mean θZd and standard deviation σZ. The standard deviation is common across the doses, but the means θZd are allowed to vary across the same range of dose response models as the final endpoint (NDLM, Logistic, etc.). The prior specification for these predictor dose response models is identical in structure to the final endpoint, although the user selects a separate set of parameter values. The dose response for the predictor does not need to match the dose response for the final endpoint.\nThe working model assumes the final event time T is related to the predictor Z by assuming T|Z ∼ Exp(λde*βZ), where λd varies by dose and has separate priors λd ∼ Gamm**a(αd, βd) for each dose. The coefficient in the exponent β (no subscript) is constant across doses with prior β ∼ N(m, s*). \n\n\n10.5.0.2 Dichotomous Predictor\nA dichotomous predictor is handled similarly to a continuous predictor, with a marginal distribution having a predictor dose response model. However, in this case the predictor dose response relates the log-odds rather than the probability of response itself. The working model for dichotomous is identical to the working model for a continuous predictor, with T|Z ∼ Exp(λde*βZ). In this situation the working model is simpler to understand, as T|(Z = 0) ∼ Exp(λd) and T|(Z = 1) ∼ Ex**p(λdβ*)).\n\n\n10.5.0.3 Time to Event Predictor\nThe time to event predictor is qualitatively different than the continuous or dichotomous predictors. Instead of the predictor adjusting the hazard, the time to event predictor is viewed as an offset. The final endpoint is viewed as a sum of a predictor time Z1 and a post-predictor time Z2, where Z1 and Z2 are independent random variables and the final endpoint is thus Z1 + Z2.\nFor the working model, Z1 ∼ *PExp(λ1s * θ1d) and Z2 ∼ Exp(λ2d), with priors λ1s ∼ Gamma(α1s, β1s), λ2d ∼ Gamm**a(α2d, β2d) (with Z1’s control hazard model potentially being piecewise exponential). For imputation, a subject missing both the biomarker and final endpoint times has both Z1 and Z2 imputed, with the final endpoint imputed as the sum. For a subject with a predictor time but no final endpoint, Z*2 is imputed and added to the observed predictor time to impute the final endpoint.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Dose Escalation CRM" + "FACTS Core User Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#purpose-of-this-document", - "href": "documentation/v71/userguides/core.html#purpose-of-this-document", + "objectID": "documentation/v71/userguides/core.html#non-adaptive-designs", + "href": "documentation/v71/userguides/core.html#non-adaptive-designs", "title": "FACTS Core User Guide", - "section": "2.1 Purpose of this document", - "text": "2.1 Purpose of this document\nThis document describes how to use the ‘Quantities of Interest’ and ‘Design’ options that are common across the FACTS Core design engines. It is intended for all end users of the system.", + "section": "11.1 Non-adaptive designs", + "text": "11.1 Non-adaptive designs\nIf the design is non-adaptive, then on this tab the user simply specifies the fixed allocation ratio to use between all the treatment arms for the duration of the study. The allocation is implemented using a blocking scheme – the block size is the sum of the allocation ratios entered and each arm is given the number of slots in the block corresponding to its allocation ratio. Consequently, the values entered must be integers.", "crumbs": [ "Documentation", "Version 7.1", @@ -880,11 +917,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#scope-of-this-document", - "href": "documentation/v71/userguides/core.html#scope-of-this-document", + "objectID": "documentation/v71/userguides/core.html#fixed-allocation", + "href": "documentation/v71/userguides/core.html#fixed-allocation", "title": "FACTS Core User Guide", - "section": "2.2 Scope of this document", - "text": "2.2 Scope of this document\nThis document covers the design options that are common across the four FACTS Core Design Engines: Continuous, Dichotomous, Time-to-Event and Multiple Endpoint. Design elements that are unique to a particular engine (primarily data simulation and simulation output) are covered in the endpoint specific Core Engine User Guide.\nThis document does not address the use of FACTS Enrichment Designs, Dose Escalation, or Platform Trials, which have separate User Guides.\nThe screenshots provided are specific to a particular installation and may not reflect the exact layout of the information seen by any particular user. They were taken from FACTS V7 & V6[1] installed on Windows 10 or 11. If FACTS is installed on different versions of Windows, or with different Windows ‘themes’ there will be some differences in appearance introduced by Windows. The contents of each tab, however, will still be consistent with the screenshots in this document.", + "section": "11.2 Fixed Allocation", + "text": "11.2 Fixed Allocation\nIf allocation is to be fixed, then on this tab the fixed allocation ratios and block size are specified. For each arm in the study allocation ratios are entered as for fixed designs, and allocation uses a block size that is the sum of the ratios. Fixed allocation works identically to the non-adaptive design randomization. The difference is that this Fixed allocation can be performed concurrently with interim analyses being performed.", "crumbs": [ "Documentation", "Version 7.1", @@ -893,11 +930,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#context-of-this-issue", - "href": "documentation/v71/userguides/core.html#context-of-this-issue", + "objectID": "documentation/v71/userguides/core.html#arm-dropping", + "href": "documentation/v71/userguides/core.html#arm-dropping", "title": "FACTS Core User Guide", - "section": "2.3 Context of this Issue", - "text": "2.3 Context of this Issue\nThis is the version of the user guide for inclusion with the FACTS 7.1 release.", + "section": "11.3 Arm Dropping", + "text": "11.3 Arm Dropping\nAdaptive arm dropping trials allow accruing data to inform the adaptive design that an arm, or a set of arms, can be dropped, meaning they no longer have subjects randomized to them. FACTS Core supports designs in which some number of arms that are clearly ineffective can be dropped. Designs where at an interim one or more arms are selected to be continued and all other arms are dropped can be simulated using FACTS Staged Designs.\nFor each arm in the study, allocation ratios are entered as for fixed designs. There are options for specifying the arm dropping rules, evaluated at each interim:\n\nThe arm dropping criteria, the user may select any combination of Bayesian “Per Dose” QOIs: Posterior Probabilities or Predictive Probabilities, or a Target Dose QOI. For each criteria selected (at least one must be selected), the user supplies a direction of comparison and probability threshold. If at any interim, any arm meets the specified arm dropping criteria, then that arm becomes a candidate for dropping. After candidates are identified for dropping, the rest of the setup rules determine which, if any, of the candidates will be dropped.\n\n\n\nIn the “Setup” area a number of rules for arm dropping are specified:\n\nThe maximum number of arms that can be dropped – this can be set to from 0 to the number of active arms, the Control and Active Comparator are never dropped. This figure is the ‘maximum number of arms that can be dropped over the duration of the trial’. At any interim any number between 0 and the ’maximum number of arms can be dropped as long as this limit is not exceeded on the overall number of arms that would have been dropped.\n\n\n\nIf the maximum number of arms that can be dropped is set to the number of study drug arms, then if all arms are dropped this is recorded as an “early termination for futility”.\n\n\nArm dropping can be restricted to ‘pruning from the lowest dose’ and/or ‘pruning from the highest dose’. If ‘prune from the lowest dose’ is selected, then until the lowest dose meets the arm dropping criteria the second lowest dose cannot be dropped and so on. At an interim when the lowest dose does meet the arm dropping criteria, and the second dose does too, then the second dose can be dropped as well (and third and fourth …), it does not have to wait until the next interim.\nIf no pruning is selected or pruning from both ends is selected, then the user must select to prioritize the higher or lower dose to cover the instance when more doses are candidates for dropping than allowed by the maximum threshold. If “Prioritize dropping the lowest dose” is selected then when forced to choose between two or more doses to drop, the one with the lowest effective dose strength will be dropped.\n\n\nLastly the user specifies what is to be done with the unused subjects that would have been allocated to an arm that has been dropped. There are three options:\n\nMaintain study size, maintain combined block size of treatments: subjects that would have been allocated to arms that have been dropped are now randomized between all the remaining active treatment arms (excluding control and active comparator) using their original allocation ratios. For example, if the allocation ratio was 2:1:1:1 between Control and D1, D2 and D3, then after dropping D1 the block size remains size 5: 2 to Control and 1 to each of D2 and D3, with the 5th slot being allocated 1:1 between the remaining two study arms D2 & D3. Thus, the overall proportion of subjects on Control (and Active Comparator) is maintained.\nMaintain study size, reduce combined block size of treatments: subjects that would have been allocated to any arms that have been dropped are randomized between all remaining arms (including control) using a reduced total block size. Thus, if the allocation ratio was 2:1:1 between Control and D1 and D2, then after dropping D1 the block size drops to total size three: 2 to Control and 1 to D2.\nDecrease the study size, reduce combined block size of treatments: subjects that would have been allocated to any arms that have been dropped are no longer recruited and the total sample size of the study is reduced; the remaining subjects are recruited using a reduced block. If interims are specified by number of subjects recruited, these interim sizes are reduced proportionally. As an example of this, if an arm that gets 20% of the randomization is dropped when there are 100 subjects enrolled, then if the next interim is scheduled at 200 subjects enrolled, it will actually be performed at 180 subjects enrolled.", "crumbs": [ "Documentation", "Version 7.1", @@ -906,11 +943,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#citing-facts", - "href": "documentation/v71/userguides/core.html#citing-facts", + "objectID": "documentation/v71/userguides/core.html#adaptive-allocation", + "href": "documentation/v71/userguides/core.html#adaptive-allocation", "title": "FACTS Core User Guide", - "section": "2.4 Citing FACTS", - "text": "2.4 Citing FACTS\nIf writing in LaTex and using Bibtex, if you wish to cite FACTS (thank you!), can we suggest the following:\n(techreport?){FACTS71,\n  author = {{FACTS Development Team}},\n  title = {{FACTS}: Fixed and Adaptive Clinical Trial Simulator},\n  year  = {2024},\n  month = {03},\n  number = {Version 7.1},\n  type         = {Computer Software},\n  institution = {Berry Consultants LLC},\n  address = {Austin, TX},\n  note   = {https://www.berryconsultants.com/software/facts/}\n}\nThis will result in a reference that, for example in the APA style, will look like the following:\nFACTS Development Team (2024). FACTS: Fixed and adaptive clinical trial simulator. Computer Software Version 7.1, Berry Consultants LLC, Austin, TX. https://www.berryconsultants.com/software/facts/.", + "section": "11.4 Adaptive Allocation", + "text": "11.4 Adaptive Allocation\nIn adaptive allocation, the relative probabilities of assigning each of the doses to a subject may change throughout the trial. The adaptive allocation design that FACTS supports is one where the allocation ratio is modified at each interim to increase the allocation to doses that have the preferred characteristics.\nAn adaptive allocation design has two phases: the “burn-in” before any adaptation takes place and the “adaptive phase”. The burn-in lasts until the first interim occurs, and is defined on the Interims tab. The adaptive phase lasts until the early stopping criteria are met or the maximum sample size is reached.\nThe allocation of subjects in burn-in is specified by entering the allocation ratio to each arm for the burn-in period. Once the first interim is reached the allocation becomes adaptive.\n\nIt is possible to specify that specific treatment arms are not to be allocated to adaptively by specifying a fixed allocation for that arm.\nAdaptive and fixed allocation is combined within an overall blocking scheme, within which some slots are fixed and some are adaptive.\n\n\n\nThe arms to allocate to with a fixed probability are selected by clicking the “Fix Alloc” check box for that arm.\n\n\n\nThe overall block size is set by entering it in the ‘Block size’ field.\nThe number of ‘slots’ in the block to be given to the fixed arms are set by entering the number on the “Post Burn-in Alloc per Block” cell for the fixed arms.\nThe non-fixed arms will be allocated to adaptively and probabilistically in the slots not taken by the fixed allocation (so the Block size must exceed the number of fixed slots being used!)\n\nCommonly, the control arm and active comparator arms are allocated to in this way and the treatment arms are left to be allocated to adaptively. If the Control arm is not given a fixed allocation, it is allocated to with an adaptive probability that is an equal weight to the treatment arm with the highest weight.\nThere are options for specifying the adaptive allocation, evaluated at each interim:\n\n“Probability set to zero for values less than:” - specifies an allocation probability threshold, which if an arms probability of allocation falls below this value then it is set to 0 and the remaining allocation probabilities re-normalized.\nIn the “Adaptive Allocation Weights” the user selects which QOI to use to determine the adaptive allocation, and what relative weight to give them. The user also selects for each target whether the weight to use should be “probability” that the dose is the target or the “information” allocating to the dose would give about the target.\n\n\nAny Bayesian “Per Dose” QOI, or “Target Dose” QOI can be used to determine the adaptive allocation weights. In addition there is the option to use a static weighting – this is of course not adaptive! What it does do is allow an adaptive allocation to be combined with a “guaranteed minimum allocation” (see example discussion below). If a Static target is included, a small table is displayed the specification of the ratio of the division of the static weight between the study arms that are being adaptively allocated to.\n\n\nWhen weighting for probability, the weight is derived simply from the value of the QOI.\nWhen weighting for information, the weight uses the value of the QOI but adjusted by the current variance of the estimate and the number of subjects already allocated to the dose – an estimate of the additional information that would result from adding one more subject to that arm.\nWeighting for probability is ‘more aggressive’ in adapting in pursuit of the target. The risk with a probability-based weighting is never allocating again to an arm where the initial data is so poor that its initial probability of being the target is so low it is never allocated to again. So, it is appropriate when the available sample size is small (and risks must be taken), the number of study arms is small (so it is unlikely an arm will not be allocated to again), or the allocation during the burn-in is large and evenly distributed (so that having unrepresentative data is very unlikely).\nWeighing for information will tend to spread the allocation around the most likely target, reducing the risk of never learning that dose is better than its initial data. If a dose response model is being used, allocation to doses around the target dose will contribute to the accuracy of the estimate of response on the target dose, but compared to the probability weighting will tend to result in fewer subjects allocated to the actual target dose.\nWhichever weighing rule is selected the adaptation can be further ‘sharpened’ or ‘softened’ by adjusting the power to which the allocation probability is raised. Setting the power to 0.5 will significantly soften the allocation, setting it to 2 will significantly sharpen it.\n\n\n\n11.4.1 Weighting and Calculation of Adaptive Allocation Probabilities\nFor a QOI Pi, d that is specified as an Adaptive Allocation Target, if probability weighting is selected, the allocation target for dose d is:\nVd, i* = [Pd, i]γ\nwhere γ is the allocation probability power.\nIf information weighting is selected, then the allocation target for Pi, d is:\n\\[V\\_{d,i}^{\\*} = \\left\\lbrack \\sqrt{\\frac{P\\_{d,i}Var\\left( \\theta\\_{d} \\right)}{n\\_{d} + 1}} \\right\\rbrack^{\\gamma}\\]\nwhere γ is the allocation probability power, nd is the number of subjects on dose d, and θd is the dose-response model mean estimate for arm d.\nIf there are multiple allocation targets used for an adaptive randomization, then these allocation targets are combined to create a single allocation weight Wd. The allocation weight for a dose is the weighted average of the allocation targets for the dose.\n\\[W\\_{d} = \\sum\\_{i = 1}^{I}{w\\_{i}V\\_{d,i}}\\]\nwhere I is the number of allocation targets, wi is the weight of allocation target i, and Vd, i is the value of the allocation target for dose d on target i.\nIf there is only 1 allocation target, then the allocation weight Wd = Vd, 1.\nFinally, for the doses which are adaptively allocated (not fixed or within their burn-in period), these allocation weights are renormalized to sum to the probability remaining after all fixed doses have been allocated.\n\n11.4.1.1 Non-fixed Control Adaptive Allocation\nIf the control allocation ratio is not fixed when performing adaptive allocation, then the control arm gets a randomization ratio that targets matching the number of control subjects to the active arm with the most subjects.\nTo derive the control allocation rate, let Vd for d = 1, 2, …D be the allocation probabilities for each of the D non-control dose arms (these may be obtained by calculating based on the probability or information criteria as described above or the fixed allocation proportion with respect to the block size), and let nd for d = 1, 2, …D be the number of subjects allocated to those arms.\nThen, the allocation to the control arm V0 is:\n\\[V\\_{0} = \\min\\left\\\\ \\sum\\_{d = 1}^{D}{V\\_{d}\\frac{(n\\_{d} + 1)}{(n\\_{0} + 1)},\\\\\\\\max\\\\ V\\_{1},V\\_{2},\\ldots,\\\\V\\_{D}\\\\} \\right\\\\\\]\nFollowing fixing this control rate, the allocation probabilities for the non-fixed doses are renormalized to add up to the total non-fixed probability.\n\n\n11.4.1.2 Zero Out Allocation Probabilities\nIf, at the end of the adaptive allocation probability calculation, any adaptively allocated arms have a randomization probability smaller than the value provided for “Allocation probability set to zero for values less than:”, then the allocation probabilities are adjusted.\nTo adjust the probabilities, first the arm with the smallest randomization probability is given a fixed allocation rate of 0. Then, the remaining adaptively allocated arms have their allocation probabilities re-normalized to sum to the probability remaining after all fixed doses have been allocated. Then, if any doses remain below the zero-out threshold, then this process is repeated. Continue the repetition as necessary. If none of the allocation probabilities are below the threshold, then the allocation probabilities are set.\n\n\n\n11.4.2 Adaptive Allocation Calculation Examples\n\n11.4.2.1 Simple Response Adaptive Randomization Example\nSuppose you have a control and 3 active doses. The control arm is guaranteed 2/6 slots in every block and a fixed 20% probability must be placed on the first active dose (dose A). So, the control arm gets 33.3% of the total allocation probability and dose A gets 20% of the total allocation. Suppose the target QOIs Vd for the three active doses are 0.20, 0.50, and 0.30 and that we’re using probability weighting with weight 1. The second two doses are the only doses with unknown randomization probabilities, so they split the amount of non-fixed allocation probability proportionally based on their Vd.\nThe allocation probability of the second active dose is \\(\\left( 1 - (0.333 + 0.2) \\right)\\*\\left( \\frac{0.5}{0.5 + 0.3} \\right)\\) and the allocation probability of the third active dose is \\(\\left( 1 - (0.333 + 0.2) \\right)\\*\\left( \\frac{0.3}{0.5 + 0.3} \\right)\\).\nThus, the final allocation probabilities for the control and the three active doses are: (0.333, 0.2, 0.292, 0.175).\nIf any of the adaptively allocated probabilities are less than a user specified minimum (“Allocation probability set to zero for values less than….” in the GUI) then these probabilities would be set to zero and the resulting probability is reallocated among the non-fixed probability doses. If all non-fixed doses drop at this point, then the probability is reallocated to the fixed doses.\n\n\n11.4.2.2 Using Static Weighting Example: Ensuring a minimum allocation to all arms\nAs an example of using the static weight to allow adaptive randomization along with a guaranteed minimum allocation of 10% to each of 5 study arms. Let us say that we want the adaptive allocation to be evenly divided between targeting an EDq and MED target.\nAs there are 5 study arms, allocating 10% each amounts to 50% of the total. Thus we could specify weights of 1 to the MED target, 1 to the EDq target, and 2 to the Static target, so the Static target gets 50% of the total weighting.\nHowever, this ignores the possible allocation to a Control arm. What we have achieved above either allocates 10% to each study arm if there is no Control arm, or if there is a Control arm, allocates 10% of the subjects allocated to the study arms, not 10% of the overall.\nLet us say that in addition to the 5 study arms you have a Control that we want to have 20% allocation and we want each study arm to have at least 10% of the overall allocation. The simplest way to specify this is to set a “Post first interim block size” of 10 and that 2 slots are allocated to Control.\nThis leave 8 slots to be allocated across the treatment arms, to ensure a 10% allocation for each of the 5 treatment arms - that takes up 5 more slots in the block – but we don’t want to allocate 1 in the block to each using fixed allocation – because then that’s all they would get. We need to allow them to be allocated to adaptively and use the Static target to ensure they get a minimum of 10%. We can achieve this by giving the static allocation a weight of 5 and divide a weight of 3 between the MED and EDq targets, so they get a weight of 1.5 each.\n\n\n11.4.2.3 Using Static Weighting Example: Ensuring a minimum allocation to top dose\nImagine an early Phase II Proof-of-Concept study that wants to compare 3 doses of the study drug (low, medium and high) to Control, and adaptively allocate to the dose with the maximum response. The study team also wish to ensure a minimum allocation to the top dose as they have a strong prior that it will have the maximum effect. They want to minimize the risk that the adaptive allocation avoids the top dose because of randomly poor results on that dose early on in the trial.\nSolution 1 uses a fixed allocation to Control of 30%. The optimal allocation to control in a multi armed study is approximately √N:1:1:… where N is the number of study arms [Dunnett] and in √3:1:1:1 the proportion on control would be 37%. Here we’ve rounded down to 30% rather than up to 40% to reflect a typical clinical teams desire to get more data on their study drug rather than Control.\nAfter the first Interim, we specify allocation to be in blocks of 10 with the Control allocate 3 slots in each block, the weight on the Static target is 2 and the Weight on the Pr(Max) target is 5. So 50% of the allocation is adaptive targeting the dose with the Maximum response and 20% is fixed and allocated to the top dose by specifying that the static weighting is split 0:0:1.\n\nSolution 2 uses adaptive allocation to Control. Adaptive allocation to Control allocates to control with the same weight as the adaptive allocated arm with the highest weight. Under this scheme the top dose will receive its minimum allocation when there is an arm with close to 100% Pr(Max). If that arm is the top dose, then allocation will be close to 50% to Control and 50% to the top dose, so the 20% minimum allocation requirement is met. If it is a different arm with close to 100% Pr(Max) then, if the allocation to top dose is t and the allocation to Pr(Max) 100 - t, the allocation ratio is (100 – t) : (100 – t) : t, (Control : Best Dose : Top Dose).\nThe total allocation is (200 – t) and we want to select t so that t/(200 – t) ≅ 0.2. So t = 33.3. With the static weight allocated 0:0:1.", "crumbs": [ "Documentation", "Version 7.1", @@ -919,11 +956,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#definition-of-terms", - "href": "documentation/v71/userguides/core.html#definition-of-terms", + "objectID": "documentation/v71/userguides/core.html#deterministic-allocation", + "href": "documentation/v71/userguides/core.html#deterministic-allocation", "title": "FACTS Core User Guide", - "section": "2.5 Definition of Terms", - "text": "2.5 Definition of Terms\nThe following acronyms and abbreviations are used in this document.\nActive Comparator A treatment arm where subjects are treated with some existing therapy which the user either wishes to compare the novel treatment to (in addition to control), or wishes to use to check that the study has been properly designed to show a difference from control.\nBaseline The subject’s baseline is their endpoint value before treatment on the trial is started. In FACTS the subject’s baseline is measured at their first visit, any prior visits (e.g. for screening to see if the patient is eligible for the trial) are not included in the simulation.\nCap A limit on the number of subjects recruited. In FACTS users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) but through the use of early stopping rules the actual number recruited may be less, depending on the data observed.\nControl Is the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\nCore FACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\nCRM Continual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\nDE Dose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\nED Enrichment Designs: a mode of FACTS for designing trials where the same treatment is tested in different settings, for example different sub-populations or different but related indications.\nDose Response Model This is a model used in the statistical analysis of the final response as a function of the treatment dose. FACTS includes both parametric and non-parametric models including ‘no model’.\nEndpoint An endpoint is a measure of the subject’s health that is being analyzed in order to learn about the effects of the treatments being studied in the trial.\nFACTS Fixed and Adaptive Clinical Trial Simulator\nFinal Endpoint The final value, or state, of a subject’s endpoint.\nGroup The very neutral term ‘groups’ is used in ED, because the ED design could be used in a number of different settings. The groups could be for instance different patient sub-populations with the same disease, different disease sub-populations such as different sarcoma types, or even different but related diseases that the same treatment might be effective against (migraine, dental pain and post-operative pain for instance). The key characteristic is that there is a need to study each independently (with their own control) but also look across the different groups for some purpose – this might be for analysis where there is an expectation of commonality in response on control, or in the difference from control on the treatment arms; or operationally where there is limited budget, drug supply or time across the groups; or for the purposes of decision making – where the treatment has to be successful in more than one group to be worth considering for further development.\nGUI Graphical User Interface, the part of the FACTS application that the user interacts with.\nHistoric Control A ‘historic control’ is where no control arm is included in the study, and the response on the arms where the novel treatment administered is compared to data from control arms from other already complete studies.\nImputation When the Bayesian statistical models are fitted to the simulated data within FACTS, if longitudinal modeling has been included, then multiple imputation is used for missing subject final endpoint values, whether missing due to the subject having dropped out or their final visit simply not occurred yet. The value is separately sampled at each iteration of the MCMC, from the posterior distribution of the longitudinal model, given the subject’s interim endpoint values.\nInterim Visit A visit between the baseline visit and final visit, at which a subject’s endpoints are measured.\nIntermediate Endpoint The value of a subject’s endpoint at a visit after their baseline visit, but before their final visit. Intermediate endpoint values can be used to estimate, using a longitudinal model, what the subject’s final endpoint will be (or would have been) thus providing additional information for analysis. Multiple imputation is used ensure that these estimated responses are included in the analysis with the correct weighting.\nLongitudinal Model An analysis model that models the relationship between a subject’s interim endpoint values and their final endpoint value, that can be used to impute their final endpoint value when it is not available.\nMethod In the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\nModel In the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\nProfile A profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\nQOI\nQuantity of Interest (QOI) A value to be calculated because it is of interest. The quantity may be of interest because it is to be used in an interim decision, to adapt allocation, for final evaluation, or to ensure it is value is written out in the FACTS results files for analysis outside of FACTS.\nResponse The change in a subject’s endpoint compared to their baseline state.\nScenario A scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include:\n\nthe distribution of the final change from base line, or probability of response or rate of events in the different treatment groups,\nthe properties of subjects’ early responses and the correlation with their final outcome,\nthe rate at which subjects are recruited into the trial,\nthe rate at which subjects drop out of the trial.\n\nSPEC The Design Engine Specification describes the system algorithms, and meaning of parameters.\nSubject Someone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\nTreatment Arm Subjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\nUG The User Guide, describes how to use the system.", + "section": "11.5 Deterministic Allocation", + "text": "11.5 Deterministic Allocation\nThe deterministic allocation option allows for the treatment assignments of subjects accrued into the simulated trials to be assigned without randomness based on an uploaded file. The file providing the assignments should be a comma separated .dat file with 2 columns, but no column labels.\nThe first column should be an increasing, unique column of numbers from 1 to at least the maximum number of subjects that can be enrolled in the study. The second column should be the set of treatment assignments in order from 1 to the number of patient IDs. The treatment assignments are used in row order – they do not use the subject ID order. So, the first subject accrued in the study is given the assignment indicated by the first row, second column value, the second subject accrued in the study is given the assignment indicated by the second row, second column value, and so on.\nThe treatment assignments column in the .dat file should always have a minimum value of 1 and a maximum of the number of total arms in the study. If there is a control arm in the study, then treatment assignment 1 corresponds to a control arm randomization. If there is no control arm in the study, then treatment assignment 1 in the .dat file corresponds to a subject randomized to the lowest active dose.", "crumbs": [ "Documentation", "Version 7.1", @@ -932,11 +969,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#references", - "href": "documentation/v71/userguides/core.html#references", + "objectID": "documentation/v71/userguides/core.html#cohort-recruitment-fixed-allocation", + "href": "documentation/v71/userguides/core.html#cohort-recruitment-fixed-allocation", "title": "FACTS Core User Guide", - "section": "2.6 References:", - "text": "2.6 References:\n[Dunnett] Dunnett CW. A multiple comparison procedure for comparing several treatments with a control. Journal of the American Statistical Association 1955; 50: 1096–1121.", + "section": "11.6 Cohort recruitment – fixed allocation", + "text": "11.6 Cohort recruitment – fixed allocation\nIf allocation is to be fixed the “Early Stopping Only” option should be selected. Then on this tab the fixed allocation ratios and block size are specified – for the first cohort and then for all subsequent cohorts. In each case the user specifies the number of each arm to allocate in each cohort and the sum must equal the size of the cohort.", "crumbs": [ "Documentation", "Version 7.1", @@ -945,11 +982,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#facts-7.1-changes-to-facts-core", - "href": "documentation/v71/userguides/core.html#facts-7.1-changes-to-facts-core", + "objectID": "documentation/v71/userguides/core.html#cohort-recruitment-adaptive-allocation", + "href": "documentation/v71/userguides/core.html#cohort-recruitment-adaptive-allocation", "title": "FACTS Core User Guide", - "section": "3.1 FACTS 7.1 Changes to FACTS Core", - "text": "3.1 FACTS 7.1 Changes to FACTS Core\nIn FACTS 7.1 FACTS Core and FACTS Staged Design for all endpoints:\n\nThere is a new Quantity of Interest: a frequentist Conditional Power, that can be calculated for the current trial or a specified future trial.\n\nFor Dichotomous endpoints only:\n\nFor p-value QOIs, users can now choose whether they should be derived using a normal approximation (this is the default option and was used in all previous versions of FACTS) or a Fisher’s exact test.\nThere is new Bayesian analysis model for dichotomous endpoints: “Beta-Binomial”, this is only available as an independent dose model, it cannot be combined with any dose response models.", + "section": "11.7 Cohort recruitment – adaptive allocation", + "text": "11.7 Cohort recruitment – adaptive allocation\nIf allocation is to be adaptive the “Adaptive Allocation” option should be selected and then under “Subsequent Cohort Allocation” the “Allocate cohort by sampling from allocation vector” should be selected. Then on this tab\n\nThe fixed allocation ratios and block size are specified for the first cohort. The user specifies the number of each arm to allocate and the sum must equal the size of the cohort.\nThe user then specifies\n\nThe fixed allocation to control\nThe QOIs to be used to calculate the allocation ratios for the remaining subjects in the cohort as for adaptive allocation (see Adaptive Allocation above).", "crumbs": [ "Documentation", "Version 7.1", @@ -958,11 +995,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#facts-7.0-changes-to-facts-core", - "href": "documentation/v71/userguides/core.html#facts-7.0-changes-to-facts-core", + "objectID": "documentation/v71/userguides/core.html#cohort-recruitment-allocate-to-best-dose", + "href": "documentation/v71/userguides/core.html#cohort-recruitment-allocate-to-best-dose", "title": "FACTS Core User Guide", - "section": "3.2 FACTS 7.0 Changes to FACTS Core", - "text": "3.2 FACTS 7.0 Changes to FACTS Core\nIn FACTS 7.0 FACTS Core and FACTS Staged Design:\n\nFACTS Core Continuous, Dichotomous and Multiple Endpoint no longer hav a requirement that there at least two arms in a trial and can simulate single arm trials without requiring ‘fake’ control or second arms. Both Bayesian posterior probability and p-value QOI’s can be evaluated comparing against an absolute response.\nA change that breaks backwards compatibility: FACTS used to be inconsistent in the time units it used for the patient accrual date using days (rather than weeks, which is the time unit used everywhere else). FACTS now outputs the patient accrual date in weeks and expects it to be input in weeks (see the analysis tab and deterministic accrual option).", + "section": "11.8 Cohort recruitment – allocate to best dose", + "text": "11.8 Cohort recruitment – allocate to best dose\nIf allocation is to be adaptive, but at each cohort just Control and the “best dose” are to be allocated to, the “Adaptive Allocation” option should be selected and then under “Subsequent Cohort Allocation” the “Allocate cohort to single treatment (plus control)” should be selected. Then on this tab\n\nThe fixed allocation ratios and block size are specified for the first cohort. The user specifies the number of each arm to allocate and the sum must equal the size of the cohort.\nThe user then specifies\n\nThe fixed allocation to control\nThe QOIs to be used to calculate the allocation weighting to calculate for the non-Control arms, (see Adaptive Allocation above) and all the subjects not allocated to control will be allocated to this arm.", "crumbs": [ "Documentation", "Version 7.1", @@ -971,11 +1008,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#facts-6.5-changes-to-facts-core-design-options", - "href": "documentation/v71/userguides/core.html#facts-6.5-changes-to-facts-core-design-options", + "objectID": "documentation/v71/userguides/core.html#continuous-and-dichotomous-endpoints", + "href": "documentation/v71/userguides/core.html#continuous-and-dichotomous-endpoints", "title": "FACTS Core User Guide", - "section": "3.3 FACTS 6.5 Changes to FACTS Core Design options", - "text": "3.3 FACTS 6.5 Changes to FACTS Core Design options\nFACTS 6.5 Core:\n\nIn FACTS Core and Staged Continuous, Dichotomous and Multiple Endpoint there is a new option for p-value QOIs to be evaluated with a super-superiority or non-inferiority delta, and for current trial predictive probabilities the same delta is assumed for the prediction of success.\nIn FACTS Core and Staged Time-to-Event:\n\nWith a Time-to-Event predictor, the timing of interims can be governed by the number of predictor events observed.\nWith a Time-to-Event predictor the file termination can be governed by the number of predictor events observed.\nWith any predictor it is possible to disable the use of the predictor model to predict event times for those patients who have not yet observed an event. The Bayesian analysis of the two endpoints is thus completely de-coupled.", + "section": "12.1 Continuous and Dichotomous Endpoints", + "text": "12.1 Continuous and Dichotomous Endpoints\nInformation can be defined in terms of:\n\nnumber of subjects that have been recruited\nthe number of subjects who have actually completed a specified visit\nthe number of subjects who have had the opportunity to complete a specified visit (includes drop-outs)\ninterims can be by time with the first interim defined by information and time thereafter, or each information can be defined by the amount of information required to trigger the interim..\n\n \nIf defining interims by time, these are defined by frequency (number of weeks between interim) – fractions of weeks can be used for very frequent interims! The first interim is defined in terms of an information threshold, with the type of information selected above.\nIf the accrual completes before the first interim threshold is reached, and the first interim was defined in terms of the number of subjects enrolled, then the interims by time start at full accrual. If the first interim is defined in any other terms (by events, subjects complete or subjects with opportunity to complete) then interims only start when this is reached (which might be never).\nIf defiing interims by information, then each interim is defined individually, by number of patients/observations and iif information is interms of completers, then the week of the visit that is being used to define “complete”. Successive interims must be in terms of the same or more observations at the same or later visit and at least one needs to be “more” or “later”.\nIf interims are governed by time, completers or events there is the option as to whether interims should continue after full accrual, or discontinue.", "crumbs": [ "Documentation", "Version 7.1", @@ -984,11 +1021,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#facts-6.4-changes-to-facts-core-design-options", - "href": "documentation/v71/userguides/core.html#facts-6.4-changes-to-facts-core-design-options", + "objectID": "documentation/v71/userguides/core.html#time-to-event-endpoint", + "href": "documentation/v71/userguides/core.html#time-to-event-endpoint", "title": "FACTS Core User Guide", - "section": "3.4 FACTS 6.4 Changes to FACTS Core Design options", - "text": "3.4 FACTS 6.4 Changes to FACTS Core Design options\nFACTS 6.4 Core:\n\nintroduces three new models: the Hierarchical, Linear, and Hierarchical Linear models. The Linear model subsumes the 2-parameter logistic model for dichotomous data.\nAdds options to dichotomous and time-to-event endpoints to allow posterior probability QOIs to be evaluated on the comparison of log-odds or hazard rate (as an alternative to pre-existing comparison of rates or hazard ratio)", + "section": "12.2 Time-to-Event Endpoint", + "text": "12.2 Time-to-Event Endpoint\nInformation can be defined in terms of:\n\nnumber of subjects that have been recruited\nthe number of subjects who have observed their predictor endpoint\nthe number of subjects who have had the opportunity to observe their predictor endpoint (includes drop-outs)\nspecified numbers of events have observed (time to event trials only). With early stopping only, or arm dropping designs, the occurrence of the first interim is also specified, with an adaptive allocation design, the first interim is at the end of the burn-in.", "crumbs": [ "Documentation", "Version 7.1", @@ -997,11 +1034,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#facts-6.3-changes-to-facts-core-design-options", - "href": "documentation/v71/userguides/core.html#facts-6.3-changes-to-facts-core-design-options", + "objectID": "documentation/v71/userguides/core.html#follow-up", + "href": "documentation/v71/userguides/core.html#follow-up", "title": "FACTS Core User Guide", - "section": "3.5 FACTS 6.3 Changes to FACTS Core Design options", - "text": "3.5 FACTS 6.3 Changes to FACTS Core Design options\nIn FACTS 6.3 FACTS Core there are 3 new 2D dose response models – 2 factorial models and a 2D-NDLM response model.", + "section": "12.3 Follow-up", + "text": "12.3 Follow-up\nRegardless of endpoint, the Interims tab contains options that control the behaviour should a trial stop at an interim. The option allows the user to specify whether or not to complete the follow-up of subjects who have been accrued, but have not had time to observe their final endpoint.\nThe default options available for Subject Follow-Up are:\n\nContinue follow-up if study stopped for success\n\n\n\nContinue follow-up if study stopped for futility\n\nIf the check box corresponding to an interim decision is checked, then at the time of an interim analysis decision accrual will be stopped, all subjects currently enrolled will be followed-up until they have had the opportunity to observe their final endpoint, and then the final analysis will be performed.\nIf the check box corresponding to an interim decision is not checked, then at the time of an interim analysis decision accrual is stopped, the data is locked, and no follow-up on randomized patients is collected. The interim dataset is the final dataset. The final analysis is then performed using the same data and model as was used for the interim analysis.\n\nIf the allocation method is selected as, “Arm Dropping” then an additional check box is provided in the Subject Follow-up Options box asking whether the user would like to “Continue follow-up if arm dropped.” If the box is checked, then subjects randomized to an arm that is dropped before they have the opportunity to complete their follow-up will have to opportunity to observe their final endpoint for subsequent analyses. If the box is not checked then incomplete subjects on an arm that is dropped will never have future endpoint values observed.", "crumbs": [ "Documentation", "Version 7.1", @@ -1010,11 +1047,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#facts-6.2-changes-to-facts-core-design-options", - "href": "documentation/v71/userguides/core.html#facts-6.2-changes-to-facts-core-design-options", + "objectID": "documentation/v71/userguides/core.html#interim-analysis-criteria", + "href": "documentation/v71/userguides/core.html#interim-analysis-criteria", "title": "FACTS Core User Guide", - "section": "3.6 FACTS 6.2 Changes to FACTS Core Design options", - "text": "3.6 FACTS 6.2 Changes to FACTS Core Design options\nThere were no changes to the Core Design options in DACTS 6.2.", + "section": "13.1 Interim Analysis Criteria", + "text": "13.1 Interim Analysis Criteria\nOn the success/futility criteria page the user can specify rules for judging the study for futility or success at an interim and at the final evaluation. If the trial has no interims there will be just a tab for the Final Evaluation criteria. If the trial has interim analyses, then there can be tabs that define different early success/futility criteria at the different interims.\nAt the top of the main tab is a control to allow tabs to be created for different interims. In a newly created adaptive design, FACTS will create a tab for interim 1.\nIf early success/futility criteria are specified for an interim, then they will be taken to apply to all subsequent interims until the next one for which criteria are supplied, then those criteria will apply until the next interim for which criteria are applied and so on.\nNote:\n\nEarly stopping for success/futility only occurs at interims.\nThere will be no stopping for success or futility until the first interim for which early stopping criteria have been defined.\nIt is left to the user to ensure that the early stopping criteria at any interim are mutually exclusive and it is not possible to stop for both success and futility at the same time. The FACTS design engines will stop the trial but the user should not rely on one or other outcome taking precedence. It is not considered good practice to have success and futility rules that could both be true, so FACTS does not guarantee a “tie break” rule.\nIn the output files there are columns labeled “Success <QOI>” and “Futile <QOI>” indicating whether any decision criteria became true, and “Success Combined” and “Futile Combined” indicating if all the criteria for a success or futility determination have been met. If both sets of criteria are met simultaneously, FACTS will only flag one of “Success Combined” and “Futile Combined” as being met, corresponding to how the outcome of the trial has been flagged.\n\n\nHaving created a tab to define the early success/futility criteria at an interim, the user has options to delete the tab or to copy criteria that have already been entered on another tab before editing them.\nThe user specifies:\n\nWhether early stopping for futility or success is to be allowed by selecting the “Futility criteria” or “Success criteria”\nThe stopping rules are specified, by selecting the QOI to be tested, the direction of the comparison and the threshold value for the criteria to be met.\nThe user can specify whether, if multiple criteria have been specified, they all need to be meet (Criteria combined using “AND”) or only any one of them needs to be met (Criteria combined using “OR”). These are specified independently for stopping for success and for futility.\nIf stopping is allowed, the user specifies what the minimum amount of information (using the information type specified on the Interims tab). This can be specified both in overall terms and information on specific doses. If multiple minimum-information criteria are specified they must all be met for the QOI criteria to be evaluated.\n\n\nNote that stopping is only assessed at interims, not immediately when these criteria are met.", "crumbs": [ "Documentation", "Version 7.1", @@ -1023,11 +1060,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#facts-6.1-changes-to-facts-core-design-options", - "href": "documentation/v71/userguides/core.html#facts-6.1-changes-to-facts-core-design-options", + "objectID": "documentation/v71/userguides/core.html#final-evaluation-criteria", + "href": "documentation/v71/userguides/core.html#final-evaluation-criteria", "title": "FACTS Core User Guide", - "section": "3.7 FACTS 6.1 Changes to FACTS Core Design options", - "text": "3.7 FACTS 6.1 Changes to FACTS Core Design options\nIn FACTS 6.1 FACTS Core has the new feature of ‘design variants’ that allow the user to easily simulate and evaluate FACTS Core design at different sample sizes. This change doesn’t alter the design options – but it does make it much easier to explore the effect of the change of sample size on a design.\nThere are two additional changes concern frequentist calculations:\n\nBetter control over which frequentist analyses are computed and output. There is now no longer a need to ‘enable’ frequentist analysis; the user can just select which ones are required.\nThe ability to use p-values for early stopping decisions at interims – if there is too little final data to compute a p-value the values of ‘1’ is returned.\n\nAnd there is one change that effects TTE QOIs (Quantities of Interest), it is now possible to specify Target QOIs that use the predictor endpoint in a TTE design.", + "section": "13.2 Final Evaluation Criteria", + "text": "13.2 Final Evaluation Criteria\nOn the Final Evaluation Criteria tab, the user can specify rules for judging the study for final futility or final success at its end. The tab layout is the same as an interim Success/Futility tab except there are no minimum information rules to be specified.\nThe Final Evaluation Criteria are always applied at the time of the final analysis, even if the study stops early for success or futility, and whether or not “Continue follow-up if study stopped for success” or “Continue follow-up if study stopped for futility” are selected. As a result, setting final analysis criteria that are easier to satisfy than interim analysis criteria may result in the labelling of trials that meet the interim analysis criteria but do not satisfy the final analysis criteria as flip-flops.", "crumbs": [ "Documentation", "Version 7.1", @@ -1036,11 +1073,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#subject-responses", - "href": "documentation/v71/userguides/core.html#subject-responses", + "objectID": "documentation/v71/userguides/core.html#state-descriptions", + "href": "documentation/v71/userguides/core.html#state-descriptions", "title": "FACTS Core User Guide", - "section": "4.1 Subject Responses", - "text": "4.1 Subject Responses\nThe methods used to simulate subject responses vary by endpoint type. For each endpoint, the endpoint specific user guides provide information about simulating subject responses.\nFor simulating dichotomous responses see: FACTS Core Dichotomous User Guide\nFor simulating continuous responses see: FACTS Core Continuous User Guide\nFor simulating time to event responses see: FACTS Core Time-to-Event User Guide\nFor simulating multiple endpoint responses see the continuous or dichotomous user guide, depending on the type of endpoints used in the multiple endpoint study.", + "section": "14.1 State descriptions", + "text": "14.1 State descriptions\nFor the purposes of interims, the different states or stages of a trial are:\n\nIn Burn-in / before first analysis. In adaptive allocation designs, the burn-in denotes the initial group of subjects explicitly assigned to treatment arms before probabilistic allocation begins. FACTS prevents the burn-in requiring more subjects than the maximum number of subjects – but the numbers can be equal. Regardless of the interim schedule specified (e.g., frequency, number of subjects or number of events), a) no analyses are performed during this period of time, and b) the first analysis is performed at its conclusion. In arm dropping and early stopping designs the first analysis occurs at the explicitly specified initial interim. Interims are never performed in non-adaptive designs; rather, the first and only analysis occurs when the max subject’s final observation is taken. In all cases, it is possible to reach the maximum number of events prior to the first analysis, making the study complete.\nMid Trial. Interims are performed and all rules assessed. If arms have been dropped, the per-arm posterior probabilities are still calculated for the dropped arms but the drop decision for the arms is absorbing and not re-assessed.\nFully Accrued but not complete. All subjects have been recruited and being followed up. If interims are by subject or ‘interim analysis beyond full accrual’ is set to FALSE, then the only possible next event is ‘last subject final observation’.\nStopped Early but still following up. The study stopping rules are not evaluated, but arm dropping rules are. Interims may still occur.\nComplete. All possible data collected for every enrolled subject.", "crumbs": [ "Documentation", "Version 7.1", @@ -1049,11 +1086,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#accrual", - "href": "documentation/v71/userguides/core.html#accrual", + "objectID": "documentation/v71/userguides/core.html#analysis-trigger-events", + "href": "documentation/v71/userguides/core.html#analysis-trigger-events", "title": "FACTS Core User Guide", - "section": "4.2 Accrual", - "text": "4.2 Accrual\nThe Accrual sub-tab provides an interface for specifying accrual profiles; these define the mean recruitment rate week by week during the trial. During the simulation, the simulator uses a Poisson process to simulate the random arrival of subjects with the specified mean accrual rate.\nAccrual profiles are list on the left of the screen, as depicted below. These accrual profiles may be renamed by double-clicking on them, and typing a new profile name. After creating a profile, the user must create at least one recruitment region. Early in the trial design process, detailed simulation of the expected accrual pattern is typically not necessary and a single region with a simple mean accrual rate is sufficient.\nTo model more accurately the expected accrual rates over the trial, the user may specify multiple regions for each accrual profile and separately parameterize them. Regions are added via the table in the center of the screen (Figure 7‑1). Within this table, the user may modify:\n\nthe peak, mean weekly recruitment rate,\nthe start date (in weeks from the start of the trial) for this recruitment region,\nwhether the region will have a ramp up phase and if so when the ramp up will be complete (in weeks from the start of the trial).\nWhether the region will have a ramp down, and if so when the ramp down start and when the ramp down will complete (in weeks from the start of the trial).\n\nRamp up/ramp down define simple linear increase/decreases in mean recruitment rate from the start to the end of the ramp. Note that simulation of accrual is probabilistic but ramp downs are defined in terms of time, so even if ramp downs are planned so that at the average accrual rate they will occur as the trial reaches cap, there is a risk in simulations when accrual has been slower than average, that ramp downs occur before the full sample size is reached. It is advisable to have at least one region that doesn’t ramp down to prevent simulations being unable to complete.\nA graph of the recruitment rate of the highlighted region is shown as well. As the recruitment parameters are changed, the graph will update to show the time at which full accrual is reached. An accrual profile that does not reach full accrual is invalid and cannot be used to run simulations.\n\nIn the screenshot above you can see the two step ramp up in accrual from two regions – each starting at different offsets into the trial.\nNote that the accrual profile graph is only the mean expectation; actual accrual is simulated using exponential distributions for the intervals between subjects, derived from the mean accrual profile specified here. Thus some simulated trials will recruit more quickly than this and some more slowly.\nThere are commands to import and export region details from/to simple external XML files. When importing, the regions defined in the external file are added to the regions already defined, they don’t replace them.\nThis is an example of a very simple region file defining just one region:\n<?xml version=“1.0” encoding=“utf-8”?>\n<regions>\n<region>\n<name>Region 1</name>\n<rate>5</rate>\n<start>0</start>\n<ramp-up />\n<ramp-down />\n</region>\n</regions>\n\n4.2.1 Deterministic Accrual\nIf “Deterministic” accrual has been specified on the Study > Study Info tab, then on the Accrual tab, rather that specifying an accrual profile from which subject recruitment times are simulated, the user loads a file of specific accrual dates for every subject.\n\nThe user specifies a “.dat” file to load that contains the subject accrual dates in weeks[2] from the start of the trial.\nThe required file format is a text file with comma separate values. One row per subject, with 3 fields on each row:\n\nthe subject ID, (an integer)\nthe ID of the region where the subject was recruited (an integer)\nand the subjects randomization date (in weeks from the start of the trial – this is a ‘real’ number allowing fractions of a week to be specified)\n\nThe file must contain sufficient entries to allow the maximum number of subjects specified on the Study > Study Info tab to be recruited.\nAfter successfully loading a file, the FACTS GUI shows a plot of the resulting weekly accrual rate", + "section": "14.2 Analysis trigger events", + "text": "14.2 Analysis trigger events\nThe following are the events that trigger interims, stopping or changes of trial state:\n\nLast event is observed (TTE trial with a max number of events – this is the only circumstance that can arise before the end of burn-in / first analysis that can stop the trial).\nA “number of subjects interim” occurs (other than last subject of burn-in / first analysis)\nA “cohort complete” interim occurs (when using cohort enrolment). A cohort complete event is slightly different from a “number of subjects interim” in that after a cohort is fully enrolled the interim does not occur until all the subjects are complete.\nStudy max subject size is reached.\nRecruit last subject of burn-in / first analysis occurs.\nA “time” or “number of events” interim occurs.\nLast subject’s final observation is taken (in a TTE trial this might be that the last subject to have an event has their event, or last subject recruited reaches the end of the maximum follow-up and is censored).", "crumbs": [ "Documentation", "Version 7.1", @@ -1062,11 +1099,11 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#drop-out-rates", - "href": "documentation/v71/userguides/core.html#drop-out-rates", + "objectID": "documentation/v71/userguides/core.html#trial-state-transitions", + "href": "documentation/v71/userguides/core.html#trial-state-transitions", "title": "FACTS Core User Guide", - "section": "4.3 Drop-out Rates", - "text": "4.3 Drop-out Rates\nFor the continuous and dichotomous engines, and the multiple endpoint engine, the default dropout scenario is that no subjects drop out of the study before observing their final endpoint data. If dropouts are expected, the user can specify either the “Dropouts per Dose,” or “Dropouts per Dose per Visit.”\nIf “Dropouts per Dose” is selected, then each subject has a probability of not having an observable final endpoint value equal to the dropout rate of the dose that subject is randomized to. If each subject has multiple visits and “Dropouts per Dose” is selected, then the conditional probability of dropping out before each visit given that the subject had not dropped out up to the visit before rates are all equal. In other words, if the total dropout rate is πD, the probability of dropping out between visits i and i + 1 given that the subject had not dropped out at visit i is \\(1 - \\left( 1 - \\pi\\_{D} \\right)^{\\frac{1}{V}}\\) where V is the total number of visits.\nIf “Dropouts per Dose per Visit” is selected, then each subject has a user specified probability of dropping out before a visit v that is specified as the conditional probability of dropping out before visit v given that that they had not dropped out by visit v − 1. This leads to a total dropout rate πD for a participant that is equal to:\n\\[\\pi\\_{D} = 1 - \\prod\\_{v = 0}^{V}{(1 - \\pi\\_{v})}\\]", + "section": "14.3 Trial State Transitions", + "text": "14.3 Trial State Transitions\nNote: the term “study arms” is used to refer to the treatment arms that are not the control or active comparator arm. In an arm dropping design only the study arms can be dropped, and the trial stops if all study arms are dropped.\n\n\n\nFigure 3‑2 Add Posterior Probability QOI dialog\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nState transition table\n\n\n\n\n\n\n\nTriggers\n\n\nProcessed in order …\n\n\n\n\n1: In Burn-in / before first analysis\n\n\n[This is the starting state for adaptive allocation designs]\n\n\n\n\n2: Mid Trial\n\n\n[This is the starting state for arm dropping, early stopping, and non-adaptive designs]\n\n\n\n3: Fully Accrued but not complete\n\n\n\n4: Stopped Early but following up\n\n\n[This state can only be entered if “Continue follow-up if study stopped for success/futility is set]\n\n\n\n\n5: Complete\n\n\n[This is the final state]\n\n\n\n\n\nA: Last event is observed [can only occur in TTE trials]\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\nN/A\n\n\n\n\nB: A “number of subjects” interim occurs\n\n\nN/A\n\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then if “Continue follow-up” for the appropriate decision is selected go to “4: Stopped Early” otherwise a “final evaluation” is output and\n\n\nGo to “5: Complete”\n\n\nIf the interim size = Max subjects then go to “3: Fully Accrued”\n\n\nOtherwise stay in “2: Mid Trial”\n\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nC: A “cohort complete” interim occurs [for trials using cohort enrolment]\n\n\n\n[Can only occur when the final observation of a burn-in cohort is observed]\n\n\nAn interim is output.\n\n\nIf stopping conditions are met a “final evaluation” is output and go to “5: Complete”.\n\n\nOtherwise go to “2: Mid Trial”.\n\n\n\n\nAn interim is output.\n\n\nIf stopping conditions are met a “final evaluation” is output and go to “5: Complete”.\n\n\nIf the interim size = Max cohort or the max cohort size is reached then a “final evaluation” is output and go to “5: Complete”.\n\n\nOtherwise stay in “2: Mid Trial”\n\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nD: Study max subject size is reached\n\n\n\n[Can only occur if Burn-in / first interim size = Max subjects]\n\n\nGo to “3: Fully Accrued”.\n\n\n\nGo to “3: Fully Accrued”\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nE: Recruit last subject of burn-in / first analysis\n\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then ff “Continue Follow-up if study stopped“ for the appropriate decision is set go to “4: Stopped Early but following up” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\nOtherwise go to “2: Mid Trial”\n\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nF: A “time” or “number of events” interim occurs\n\n\nN/A\n\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then ff “Continue Follow-up if study stopped“ for the appropriate decision is set go to “4: Stopped Early but following up” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\nOtherwise stay in “2: Mid Trial”\n\n\n\n\nIf “Discontinue interim analysis after full enrollment” is set, then there is no output. Stay in “3: Fully Accrued”\n\n\nOtherwise:\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then ff “Continue Follow-up if study stopped“ for the appropriate decision is set go to “4: Stopped Early but following up” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\nOtherwise stay in “3: Fully Accrued”\n\n\n\n\nIf “Discontinue interim analysis after full enrollment” is set then there is no output, stay in “4: Stopped Early”\n\n\nOtherwise:\n\n\nAn interim only checking arm-dropping is output. Stopping conditions not checked.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf all study arms are dropped then if “Continue follow-up if arm dropped” is set stay in “4: Stopped Early” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\n\nN/A\n\n\n\n\nG: Last subject’s final observation is taken\n\n\nN/A\n\n\nN/A\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\nN/A\n\n\n\n\nFigure 3‑2 Add Posterior Probability QOI dialog", "crumbs": [ "Documentation", "Version 7.1", @@ -1075,613 +1112,627 @@ ] }, { - "objectID": "documentation/v71/userguides/core.html#posterior-probabilities", - "href": "documentation/v71/userguides/core.html#posterior-probabilities", - "title": "FACTS Core User Guide", - "section": "5.1 Posterior Probabilities", - "text": "5.1 Posterior Probabilities\nThese are Bayesian quantities to be calculated at each interim and at the final analysis.\n\nA Posterior Probability is specified as:\n\nCompare:\n\nContinuous: Means\nDichotomous: Rates or Log-odds\nTime-to-Event: Hazard Ratio or Hazard Rates.\n\n\n\n\nCondition: “>” or “<” a comparison value.\nRelative to an absolute value or relative to the response on a specific dose.\nThe comparison can include a delta, which is the absolute value to be compared against if the comparison is absolute, or a value that the difference relative to the comparison arm is compared to.\nThe QOI will be given a “name” derived from these details and a short or Alternative name that will be used in the output files to allow easier access from other software, e.g. from within R.\nIf the endpoint is TTE and the design includes a predictor endpoint, then the definition of the QOI includes the specification of which endpoint it applies to.\n\n\n5.1.1 Notes on setting Delta’s\nIn the three endpoints delta’s are defined as:\n\nContinuous A CSD (Clinically Significant Difference) in the estimates of the mean response.\nDichotomous A CSD in the estimate of the response rates\nTime-to-Event A CSHRD (Clinically Significant Hazard Ratio Difference) in the estimate of the Hazard Ratio\n\nA “standard” hypothesis test for demonstrating superiority to control uses a delta of 0. Testing for superiority with a non-zero delta is different, and the implications need to be carefully understood[3]. Where the term CSD is used in this document, it should be taken to refer to CSHRD as well unless it is specifically stated otherwise.\nWhen setting a target treatment difference from control for the study to beat, it is also common to require a degree of confidence that the target has been beaten. To achieve posterior probabilities of > 50% that the target has been beaten, the estimated mean difference will have to be greater than the target difference.\nThus, when setting a delta, we are setting up two hurdles the study drug must beat, first the delta and then on top of that an additional margin to give a > 50% confidence that the margin has been beaten. Thus, it is necessary to avoid setting the target delta too large. A common rookie error is to set the delta to the ‘expected difference’ (the value that might have been used in a conventional sample size calculation). In scenarios where the simulated response is equal to the ‘expected difference’ and hence the CSD this will give probabilities of being better than control by the delta of 50% on average, regardless of the sample size.\nIt is inadvisable to require a posterior probability of 50% or better than the response is better than the Control by the delta as this turns the test into one that simply depends on whether the point estimate of the response is better.\nIt is inadvisable to require posterior probability of less than 50% for success, as such criteria have the undesirable characteristic that they can be met in circumstances where it can be seen that if further data was gathered consistent with what has already been seen, it would lead the threshold no longer being met! The posterior distribution would shrink so that there was no longer sufficient of the tail above the CSD.\nIt is better therefore to use a delta that is less than the expected difference that it is hoped to achieve, somewhat like having a non-inferiority margin around the target. So, when the design is simulated with a response at the expected difference the target will be clearly exceeded. A useful default value to use for a delta is half the ‘expected difference’. This usually yields “comprehensible” probability thresholds for both success and futility.\nUsing a delta has benefits however – simply being better than control but for very small difference can be established simply by having large sample sizes. Being better than control by a delta establishes some confidence that there is some patient benefit. Use of a delta is also useful if otherwise success thresholds “well out in the tail” (e.g. > 0.99) are required such as the equivalent of an early look in a conservative Group Sequential design. Though the use of a delta does mean that there is a less direct equivalence to a p-value.\n\n\n5.1.2 P-value Delta’s\nSeparately from the CSD/CSHRD delta, with a continuous or dichotomous endpoint (but not time-to-event), a frequentist super-superiority/non-inferiority delta can be specified.\nThese use the same selection of super-superiority/non-inferiority as the CSD\n\nCurrently, unlike the CSD delta that is only applied to the default posterior probability QOI and MED target QOI, the p-value delta is applied to all the p-value QOIs and it cannot be overridden.\nThe value of the p-value delta is constrained to be 0 or positive. The ‘direction’ of the delta depends then on the direction of the endpoint (whether “higher/lower is better” or “a response is a positive/negative outcome”.\n\n\n\nFigure 8‑1: Accrual\n\n\n\n\n\n\n\n\n\n\n\n\nHigher is better / Response is positive\n\n\nLower is better / Response is negative\n\n\n\n\n\n\nSuper-Superiority\n\n\nTrt – Control > delta\n\n\nTrt – Control < -delta\n\n\n\n\nNon-inferiority\n\n\nTrt – Control > -delta\n\n\nTrt – Control < delta\n\n\n\n\nFigure 8‑1: Accrual\nSign of delta and direction of test\nIf no control arm is included p-values, with a continuous or dichotomous endpoint, the treatment response is compared to a fixed value:\n\nContinuous – compared to a response of 0.\nDichotomous – compared to a rate of 0.5.\n\nNow with p-value deltas the p-value QOIs (and current trial predictive probability QOIs) can be compared to any fixed value – by specifying a delta that combined with the default value (of 0 or 0..5) gives the absolute value that you want to compare to.", + "objectID": "documentation/v71/userguides/crm.html", + "href": "documentation/v71/userguides/crm.html", + "title": "FACTS Dose Escalation CRM", + "section": "", + "text": "This document describes how use the FACTS Dose Escalation (DE) CRM design engine. It is intended for all end users of the system.\n\n\n\nThis document covers the FACTS Dose Escalation N-CRM design engine user interface.\nThis document does not address the internal workings of the design engines or algorithms, which are addressed in the associated Design Engine Specification. It also does not address the use of FACTS Core Designs or Enrichment Designs, which are covered in other User Guides.\nThe screenshots provided are specific to a particular installation and may not reflect the exact layout of the information seen by any particular user. They were taken from FACTS 6.3 and later installed on Windows 10. Different versions of Windows or the use of different Windows themes will introduce some differences in appearance. The contents of each tab, however, will be consistent with the software.\n\n\n\nThis document has been updated for the version 7.1 release of Dose Escalation FACTS.\n\n\n\nIf writing in LaTex and using Bibtex, if you wish to cite FACTS (thank you!), can we suggest the following:\n@techreport{FACTS71,\n author = {{FACTS Development Team}},\n title = {{FACTS}: Fixed and Adaptive Clinical Trial Simulator},\n year = {2024},\n month = {12},\n number = {Version 7.1},\n type = {Computer Software},\n institution = {Berry Consultants LLC},\n address = {Austin, TX},\n note = {https://www.berryconsultants.com/software/facts/}\n}\nThis will result in a reference that, for example in the APA style, will look like the following:\nFACTS Development Team (2024). FACTS: Fixed and adaptive clinical trial simulator. Computer Software Version 7.1, Berry Consultants LLC, Austin, TX. https://www.berryconsultants.com/software/facts/.\n\n\n\nTable 1 gives an overview of the acronyms and abbreviations used in this document.\n\n\n\nTable 1: List of terms used in the CRM user guide\n\n\n\n\n\n\n\n\n\nName\nDefinition\n\n\n\n\nCap\nA limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap.\n\n\nControl\nIs the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\n\n\nCore\nFACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\n\n\nCRM\nContinual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\n\n\nDE\nDose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\n\n\nED\nEnrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications.\n\n\nFACTS\nFixed and Adaptive Clinical Trial Simulator.\n\n\nFinal Endpoint\nThe final value, or state, of a subject’s endpoint.\n\n\nGUI\nGraphical User Interface, the part of the FACTS application that the user interacts with.\n\n\nMethod\nIn the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\n\n\nModel\nIn the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\n\n\nMTD\nThe dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD).\n\n\nMTD+\nThe dose most likely to be the MTD+ – the dose with the highest Pr(MTD+).\n\n\nPr(MTD)\nA dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses.\n\n\nPr(MTD+)\nA dose’s probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range.\n\n\nProfile\nA profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nScenario\nA scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include: -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups -) the properties of subjects’ early responses and the correlation with their final outcome -) the rate at which subjects are recruited into the trial -) the rate at which subjects drop out of the trial.\n\n\nSPEC\nThe Design Engine Specification, describes the system algorithms, and meaning of parameters.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nSubject\nSomeone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\n\n\nTreatment Arm\nSubjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\n\n\nUG\nThe User Guide; describes how to use the system.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#predictive-probabilities", - "href": "documentation/v71/userguides/core.html#predictive-probabilities", - "title": "FACTS Core User Guide", - "section": "5.2 Predictive Probabilities", - "text": "5.2 Predictive Probabilities\nThere are two types of predictive probabilities –\n\nBayesian predictive probabilities, which are Bayesian predictions of frequentist outcomes and take into account the uncertainty around a set of parameters,\nand conditional power, which aims to calculate the frequentist probability of success assuming a set of parameters to be true.\n\nThe primary difference between the Bayesian predictive probabilities and the conditional power calculations is that the Bayesian predictive probabilities are calculated taking the variability around the estimated treatment effect into account, while the conditional power calculations assume that the observed test statistic of past data is the exact effect that future data will be generated from.\nFor both Bayesian predictive probabilities and conditional power, we differentiate two types, predicting the outcome in the current trial and predicting the outcome in a future trial.\n\n5.2.1 Bayesian predictive probabilities\n\n5.2.1.1 Current Trial Bayesian Predictive Probabilities\nIn the current trial, the outcome can be predicted under one of two assumptions:\n\nThat no new subjects are recruited, but all those who have been recruited are followed up until they are complete.\nThat the trial continues recruiting using the current allocation ratios until the trial maximum sample size is reached, and all subjects recruited are followed up until complete.\n\nPredictive probabilities currently can only predict outcomes based on p-values. Note that since p-values are only calculated as comparisons against a control arm, predictive probabilities of success in the current trial are only available if the current trial includes a control arm.\n\nThe user specifies how missingness is handled in the final analysis, the p-value test type – unadjusted, Bonferroni or Dunnett’s and the (one sided) alpha level for the significance test. The QOI assumes that the specified default p-value delta is used in the final test.\nThe predictive probability of the current trial at the maximum sample size is only available:\n\nIf the allocation is either fixed, or fixed with arm dropping, but not adaptive allocation.\n\nThe predictive probability is calculated by simulating the remaining subjects, assuming their allocated at the current probabilities of allocation and simulating their final response based on the rate of response or (Normal) distribution of responses observed so far for each arm.\n\nIgnoring the possibility of the trial stopping or dropping an arm at a future interim\nIgnoring the possibility of future subject drop-outs.\n\nThere is one simulation of the remaining data per MCMC loop, potentially significantly increasing the time to perform the overall simulation of the trial.\nIf there is no data available on the arms involved in the Bayesian predictive probability calculation, FACTS will still perform the simulation of future subject outcomes based on posterior distribution. The posterior distribution for the arms with no available data will be the same as the user specified prior distribution.\n\n\n5.2.1.2 Current Trial Bayesian Predictive Probabilities – Time-to-Event\nUnlike the Continuous and Dichotomous endpoints, to predict the probability of success at full enrolment with a Time-to-Event endpoint, it is also necessary to simulate the accrual rate (and hence how many events might be observed).\n\nFor TTE, for a Predictive Probability of Success at Full Enrolment, there are new parameters to determine how accrual is modelled. There are 3 models for accrual\n\nFixed Rate, the parameters for this are:\n\nThe fixed (mean) accrual rate per week to simulate.\n\nEstimated from the Last ‘W’ Weeks accrual data, using a Poisson distribution, with a Gamma prior. The parameters for this are\n\nThe number of past weeks W to use the accrual data from.\nThe prior mean for the model of the accrual rate\nThe weight of the prior\n\nEstimated from all the accrual data from the start of the trial, using a Poisson distribution, with a Gamma prior, the parameters for this are:\n\nThe prior mean for the model of the accrual rate\nThe weight of the prior\n\n\n\n\n5.2.1.3 Future Trial Bayesian Predictive Probabilities\nFor predictive probabilities for a future trial, a predictive probability of success in a subsequent phase 3 trial is estimated during the current trial. The probability of success in phase 3 is calculated for each study arm, based on the specification of the phase 3 trial given here of:\n\nwhether the aim is to show superiority or non-inferiority,\nthe sample size per arm,\nthe required one-sided alpha,\nand the super-superiority margin or non-inferiority margin (if any).\n\nGiven these criteria, FACTS calculates the predicted probability of success of the subsequent trial for that endpoint assuming the estimate of the response on that endpoint, integrated over the uncertainty in those estimates. The conventional expected power of the specified future trial is calculated for the treatment effect in each MCMC sample and then averaged. This predicted probability of success can then be used in the stopping criteria and final evaluation criteria for the current trial.\nThis QOI is an extension of the “probability of success in phase 3” in earlier versions of FACTS – the difference now is that multiple different possible future trials can be specified in different QOIs and used for different decisions.\n\nThis predictive probability has the following parameters that must be specified:\n\nWhether the future trial will be for Superiority or Non-inferiority.\nThe size of the future trial in terms of the number of subjects on each arm.\nThe (one sided) alpha level that will be used to determine the significance of the trial.\nThe Super-superiority margin (if any) or the non-inferiority margin. The default p-value delta is not used for this QOI it is specified as part of the QOI and can be different from the default.\n\nAs with all QOIs the QIO will be given an alternative shorter name that can be used when accessing the output files from other software such as R.\nIf there is no data available on the arms involved in the Bayesian predictive probability calculation, FACTS will still calculate the predictive probability of the future trial being a success based on the estimated posterior distribution. The posterior distribution for the arms with no available data will be the same as the user specified prior distribution.\n\n\n\n5.2.2 Conditional Power\nConditional power is currently available for Continuous and Dichotomous endpoints in Core and Staged Designs.\nWhen creating a Conditional Power QOI, the first specification that must be made is whether the conditional power should be calculated for the current trial or for a hypothetical future trial. The two selections are fundamentally different.\nThe Current Trial conditional power takes the information collected in the trial so far, and assumes that for the remainder of the current trial the data collected has an effect equal to the point estimate of the already collected data. The previously collected trial data is then combined with hypothetical future data and weighted based on the amount of information that has been and will be observed by the end of the trial. The result is the probability that the current trial will reject the null hypothesis at a provided alpha level under the assumption that the future patients are generated from a population having a treatment effect exactly equal to the past data’s test statistic.\nThe Future Trial conditional power also uses the information accrued in the trial so far to calculate the assumed treatment effect moving forward, but assumes that a new study would be started that does not use the data from the current trial in its analysis. The new study is assumed to be a 1:1 randomized study if there is a control arm, and a single arm study if no control, with a sample size per arm, objective, and alpha level specified at the time of QOI creation.\nIf a conditional power is ever calculated for an arm with no final response data or against a control arm with no final response data, the conditional power will be called missing (-9999 in FACTS).\n\n5.2.2.1 Current Trial Conditional Power\nWhen creating a current trial conditional power, the missingness strategy, multiplicity adjustment, final sample size, and alpha level for the significance test must be specified.\n\n\nHandle missingness using:\nMissingness handling for a continuous endpoint can be specified as:\n\nIgnore: subjects that are known dropouts are not included in the current or final sample size, and are not used to estimate the treatment effect.\nLast Observation Carried Forward (LOCF): subjects that are known dropouts have their last observed endpoint value assumed to be their final endpoint. Subjects with no early observed data are ignored. Subjects that have data to carry forward are considered complete, and are used to estimate the current treatment effect.\nBaseline Observation Carried Forward (BOCF): subjects that are known dropouts have their baseline value assumed to be their final endpoint. They are included in the current information as complete subjects and are used to estimate the current treatment effect. BOCF is only available for the continuous endpoint and when simulating baseline for subjects.\nFailure: subjects that are known dropouts are assumed to have a negative outcome at their final visit. If responses are good, the subject is a non-response, and if responses are bad, the subject is a responder. Failure is only available for dichotomous endpoints.\n\n\n\nTest Type\nThe test type can either be Unadjusted or Bonferroni. An unadjusted test will always use the specified alpha level in the significance test. The Bonferroni adjustment will divide the specified alpha value by the number of non-control arms enrolling in the study in the enrolment period leading up to the current analysis time.\n\n\nSample Size:\nThe current trial conditional power can be calculated at two different future time points.\n\nCurrent Enrollment: That no new subjects are recruited, but all those who have been recruited are followed up until they are complete.\nTrial Maximum: That the trial would continue recruiting subjects using the current allocation ratios until the trial maximum sample size is reached, and all subjects recruited are followed up until they have the opportunity to complete.\n\n\n\nOne-sided Alpha\nThe threshold that the current trial would have to be less than in order to be considered a success. The success/futility values specified in the design tab are not used in the conditional power calculation. This value may be adjusted by the “Test type:” input.\n\n\nSuper-Superiority (Non-inferiority) margin for p-value:\nThis value cannot be changed on the QOI pop-up. It’s instead modified at the bottom of the QOI page. The objective of the current trial cannot be different for each individual current trial conditional power QOIs.\n\n\nAdditional Notes\nCurrently, conditional power will always assume that there is no correction applied to combine the different p-values from the analysis timepoints, i.e. no combination test is used.\nThe conditional power of the current trial at the maximum sample size is only available if the allocation is either fixed, or fixed with arm dropping, but not adaptive allocation or deterministic allocation.\nConditional power for the current trial is calculated\n\nIgnoring the possibility of the trial stopping or dropping an arm at a future interim\n\n\n\nIgnoring the possibility of future subject drop-outs.\n\n\n\n\n5.2.2.2 Future Trial Conditional Power\nConditional power of a future trial is reduced to a power calculation for a future trial, given the current frequentist estimates of treatment effect and standard deviation and a set of assumptions for the future trial, such as sample sizes, hypothesis to be tested, and significance levels to be used.\nThe test type of the future trial can be set to Superiority or Non-inferiority. If the superiority or non-inferiority margin is set to 0, then both types of tests simplify to traditional tests of superiority with no margin. If a non-zero margin is set, then the future trial must meet the success criteria indicated by the test type and the margin. The margin cannot be negative, but a super superiority test with a margin of -0.5 is equivalent to a non-inferiority test with a margin of 0.5.\nThe subjects per arm dictates how many subjects would be enrolled on each arm in the future study. If there is a control arm in the current trial, then the future trial is assumed to be randomized 1:1 between the active arm and the control. If there is no control arm in the current study, then the future trial is a single arm trial testing against the performance goal specified in the Freq. Comparison Response box in the QOI creation pop-up.\nThe One-sided Alpha is the significance level of the final analysis test of the future trial. The future trial is assumed to have 1 active arm, so there are no adjustments to the alpha level available.\nThe superiority margin or non-inferiority margin indicate the amount that the active arm must be better/not worse than the control arm by. If there is no control arm then this is the Freq Comparison response, which is the value that the active arms must be significantly better than in order to be declared a success. The frequentist margin for p-value QOIs on the QOI tab is not used for Future conditional power calculations – the future trial can have a different objective than the current trial.\n\n\n\n5.2.2.3 Technical Aspects of Conditional Power Calculations\nThe conditional power calculations in FACTS are all calculated similarly to Jennison and Turnbull (2000)[4].\nFor continuous endpoint conditional power calculations, the conditional power of the future trial is calculated using a pooled standard deviation from all arms. For dichotomous conditional power calculations, each arm has its own standard deviation based on the MLE estimate of its proportion. These decision result in the conditional power tests matching how simple p-values are calculated for continuous and dichotomous endpoints.\nThe following sections will provide formulae to calculate the conditional power in the case where there is a control arm. Simplifications for when the arm is being compared to a fixed value rather than a control arm are simple: information fractions are only a function of the active arm standard deviation and the test statistic does not have a second sample mean subtracted from the active arm.\nThe value of δ, which can be a non-inferiority margin or a super superiority margin, is always positive coming out of FACTS. To make the math more concise we can define a couple of coefficients for the δ term that allow it to be used without re-writing formulas for different hypothesis test setups. If high values of the endpoint are good, then s1 = 1, and if low values of the endpoint are good, then s1 = −1. If the specified δ is a non-inferiority margin, then s2 = 1, and if it’s a super superiority margin then s2 = −1.\n\nContinuous Conditional Power for the Current Trial\nLet t be the interim index that the conditional power is being computed at, and T be the time of the analysis that the conditional power is being computed for. Then Zk is the test statistic of the data collected up to the current interim analysis in the study, Ik is the information level at the time of the interim analysis, and IK is the information level at the end of the study that the conditional power is being calculated for.\nLet arm 1 be the control and arm 2 be the active arm,  \\(\\overline{x\\_{it}}\\) be the sample mean of arm i at time t, \\(\\widehat{\\sigma\\_{i}^{2}}\\) be the sample variance of arm i at time t, n*i**t be the number of subjects with complete known final data on arm i* at interim analysis t, and n*i**T be the number of subjects with complete known final data on arm i* at the time that conditional power is being calculated for. The pooled variance estimate is \\(\\widehat{\\sigma^{2}} = \\sum\\_{d = 1}^{D}\\widehat{\\frac{\\sigma\\_{d}^{2}}{n\\_{dt}}}\\) where D is the total number of arms in the study.\nThen,\n\\[I\\_{t} = \\left( \\frac{\\widehat{\\sigma^{2}}}{n\\_{1t}} + \\widehat{\\frac{\\sigma^{2}}{n\\_{2t}}} \\right)^{- 1}\\]\n\\[I\\_{T} = \\left( \\frac{\\widehat{\\sigma^{2}}}{n\\_{1T}} + \\widehat{\\frac{\\sigma^{2}}{n\\_{2T}}} \\right)^{- 1}\\]\n\\[Z\\_{t} = \\left( {\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} + s\\_{1}s\\_{2}\\delta \\right)\\sqrt{I\\_{t}}\\]\nwhere δ is the non-inferiority or super superiority margin.\nThen for a one-sided alpha level of α, let z1 − α be the critical value corresponding to α.\nIf high values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{Z\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} + s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{{- Z}\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} - s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\n\n\nCalculation of Continuous Conditional Power for a Future Trial\nMost of the future trial conditional power calculation is the same as the above current trial conditional power. There are some simplifications.\n\\({\\overline{x}}\\_{it}\\) and \\(\\widehat{\\sigma\\_{i}^{2}}\\) are the same as in the current conditional power calculation. It, the weight of the current trial Z-score, is set to 0. IK is now the information at the end of the future trial, and is calculated as:\n\\[I\\_{T} = \\left( \\frac{\\widehat{\\sigma^{2}}}{n\\_{T}} + \\widehat{\\frac{\\sigma^{2}}{n\\_{T}}} \\right)^{- 1}\\]\nwhere nT is the sample size per arm in the future trial and again σ̂2 is the pooled variance.\nIf high values of the endpoint are good, the conditional power of a future trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} + s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of a future trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - ({\\overline{x}}\\_{2t} - {\\overline{x}}\\_{1t} - s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]\n\n\nCalculation of Dichotomous Conditional Power for the Current Trial\nThe dichotomous conditional power calculations are similar in spirit to the continuous conditional power calculations. One substantial difference is in how the dichotomous conditional power tests handle a non-inferiority or super superiority margin, δ. The method of calculating an appropriate test statistic for a frequentist hypothesis test is not obvious when the null scenario has a non-zero δ.\nWhen there is no margin, the estimate for each treatment is simply based on the observed response proportion \\(\\widehat{p\\_{i}}\\) for arm i, and the test statistic for a comparison of the control arm, c, with dose d is the usual Wald test\n\\[Z\\_{d} = \\frac{\\widehat{p\\_{d}} - \\widehat{p\\_{c}}}{\\sqrt{\\frac{\\widehat{p\\_{d}}(1 - \\widehat{p\\_{d}})}{n\\_{d}} + \\frac{\\widehat{p\\_{c}}(1 - \\widehat{p\\_{c}})}{n\\_{c}}}}\\]\nWhen there is a margin, FACTS uses the Farrington-Manning Likelihood Score test statistic to estimate quantities \\(\\widetilde{p\\_{d}}\\) and \\(\\widetilde{p\\_{c}}\\) based on the MLEs of the arm proportions governed by the constraint that \\(\\widetilde{p\\_{d}} - \\widetilde{p\\_{c}} = - s\\_{1}s\\_{2}\\delta\\). These constrained MLE estimates are used in the standard error of the test statistic. The FM test statistic is then,\n\\[Z\\_{FM,d} = \\frac{\\widehat{p\\_{d}} - \\widehat{p\\_{c}} + s\\_{1}s\\_{2}\\delta}{\\sqrt{\\frac{\\widetilde{p\\_{d}}(1 - \\widetilde{p\\_{d}})}{n\\_{d}} + \\frac{\\widetilde{p\\_{c}}(1 - \\widetilde{p\\_{c}})}{n\\_{c}}}}\\]\nSee the PASS documentation[5] or SAS documentation[6] for a complete description of the calculations that go into the FM test. In the SAS documentation, note that the FM test is the same as the Miettinen-Nurminen test without including the \\(\\frac{n}{n - 1}\\) variance correction. The FM test was used rather than the MN test because as δ → 0, the FM test converges to the simple Wald test.\nOnce the test statistic has been resolved, the dichotomous conditional power for the current trial is calculated as follows. For calculating the conditional power for arm 2 compared to the control arm, called arm 1 without loss of generality, let It be the current information amount and IT be the amount of information that the conditional power is being calculated for. Then,\n\\[I\\_{t} = \\left( \\frac{\\widetilde{p\\_{1}}\\left( 1 - \\widetilde{p\\_{1}} \\right)}{n\\_{1t}} + \\frac{\\widetilde{p\\_{2}}\\left( 1 - \\widetilde{p\\_{2}} \\right)}{n\\_{2t}} \\right)^{- 1}\\]\n\\[I\\_{T} = \\left( \\frac{\\widetilde{p\\_{1}}\\left( 1 - \\widetilde{p\\_{1}} \\right)}{n\\_{1T}} + \\frac{\\widetilde{p\\_{2}}\\left( 1 - \\widetilde{p\\_{2}} \\right)}{n\\_{2T}} \\right)^{- 1}\\]\n\\[Z\\_{t} = \\left( \\widehat{p\\_{2}} - \\widehat{p\\_{1}} + s\\_{1}s\\_{2}\\delta \\right)\\*\\sqrt{I\\_{t}}\\]\nwhere δ is the super superiority or non-inferiority margin, and n1t and n2t are current number of completers on the control and active arm, and n1T and n2T are the number of completers that will be on the control and active arm at time that the conditional power is being calculated for. Additionally, if there is no non-inferiority or super superiority margin δ, then all \\(\\widetilde{p\\_{\\*}}\\) values are equal to their corresponding \\(\\widehat{p\\_{\\*}}\\) values.\nFor a one-sided alpha level of α, let z1 − α be the critical value corresponding to α.\nIf high values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{Z\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} + s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{{- Z}\\_{t}\\sqrt{I\\_{t}} - z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} - s\\_{2}\\delta)\\left( I\\_{T} - I\\_{t} \\right)}{\\sqrt{I\\_{T} - I\\_{t}}} \\right)\\]\n\n\nCalculation of Dichotomous Conditional Power for a Future Trial\nMost of the calculation quantities for the future trial conditional power are the same as the current trial conditional power. The only difference is that for the future trial conditional power we discard the influence of the current trial test statistic on the final analysis, so It = 0. Then the conditional power calculations become:\nIf high values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} + (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} + s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]\nIf low values of the endpoint are good, the conditional power of the current trial is:\n\\[CP\\_{T} = \\Phi\\left( \\frac{- z\\_{1 - \\alpha}\\sqrt{I\\_{T}} - (\\widehat{p\\_{2}} - \\widehat{p\\_{1}} - s\\_{2}\\delta)\\left( I\\_{T} \\right)}{\\sqrt{I\\_{T}}} \\right)\\]", + "objectID": "documentation/v71/userguides/crm.html#sec-purpose", + "href": "documentation/v71/userguides/crm.html#sec-purpose", + "title": "FACTS Dose Escalation CRM", + "section": "", + "text": "This document describes how use the FACTS Dose Escalation (DE) CRM design engine. It is intended for all end users of the system.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#p-values", - "href": "documentation/v71/userguides/core.html#p-values", - "title": "FACTS Core User Guide", - "section": "5.3 P-values", - "text": "5.3 P-values\nA p-value QOI simply allows the user to specify which test type to be used (unadjusted, Bonferroni, Dunnett’s or Trend Test), and how missing data is to be handled (ignored, LOCF or BOCF – if baseline is being simulated). If a control arm is present, P-values are comparisons against the control arm, if there is no control arm present, p-value QOIs are comparisons against a fixed response or fixed rate that is specified at the bottom of the QOI tab (it cannot be set differently for separate QOIs).\nNote that for dichotomous endpoints p-value are calculated using the Test of Proportions, this test statistic asymptotically approaches a normal distribution and at least 5 success and 5 failures should be observed for this to be reasonable.\nThe p-values are calculated including the default frequentist delta that has been specified at the bottom of the screen. They cannot be modified as part of QOI, the value of the delta and nature of the test is the same for all the p-value QOIs.\nIn a TTE design with a predictor the p-values are only calculated for the final event endpoint, not the predictor.\n\n\n5.3.1 P-values when there is no control arm\nIf there is no control arm (not currently an option in Time-to-Event), the p-value delta is instead interpreted as the objective response or response rate to compare to. The option to set the trial type is also disabled (“Superiority” is selected and the “non-inferiority option is greyed out). For a non-inferiority trial comparing to an objective response or response rate simply use the objective rate minus the non-inferiority delta (if a higher response is better) or the objective rate plus the non-inferiority delta (if a lower response is better).\nIt is currently only possible to have one objective rate to compare against.\nThe same objective rate will be used for the target p-value test in the predictive probabilities.\n\n\n\n5.3.2 Fisher-Exact Test\nOn the bottom of the QOI tab, we can specify what statistical test to use when calculating p-values. Options are “Normal approximation” (default) and “Fisher exact test”. “Normal approximation” uses a t-test and should yield similar results to a Chi-Square test without continuity correction, while “Fisher exact test” uses an exact Fisher’s exact test for 2x2 tables.\nIf “Fisher exact test” is chosen as the test type, all p-value QOIs will use a Fisher’s exact test, except for future trial predictive probabilities, which will still use a t-test.\nIf “Fisher exact test” is chosen as the test type, only “Bonferroni” and “Unadjusted” are available as multiplicity corrections and any QOIs previously created using different multiplicity corrections will be deleted.\n“Fisher exact test” is not available for non-inferiority comparisons.", + "objectID": "documentation/v71/userguides/crm.html#sec-scope", + "href": "documentation/v71/userguides/crm.html#sec-scope", + "title": "FACTS Dose Escalation CRM", + "section": "", + "text": "This document covers the FACTS Dose Escalation N-CRM design engine user interface.\nThis document does not address the internal workings of the design engines or algorithms, which are addressed in the associated Design Engine Specification. It also does not address the use of FACTS Core Designs or Enrichment Designs, which are covered in other User Guides.\nThe screenshots provided are specific to a particular installation and may not reflect the exact layout of the information seen by any particular user. They were taken from FACTS 6.3 and later installed on Windows 10. Different versions of Windows or the use of different Windows themes will introduce some differences in appearance. The contents of each tab, however, will be consistent with the software.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#target-doses", - "href": "documentation/v71/userguides/core.html#target-doses", - "title": "FACTS Core User Guide", - "section": "5.4 Target Doses", - "text": "5.4 Target Doses\nThe target dose QOIs are Bayesian posterior probabilities based on MCMC sampling of how often each dose meets the specified target criteria. There are 3 types of target specifiable\n\nMax – the dose with the maximum response, this has no parameters to specify, so is available as a pre-defined default QOI.\nMED – a Minimum Effective Dose, the lowest dose that has a response better than an absolute or relative target.\nED – an effective dose, the dose that achieves a specified proportion (quantile) of the maximum improvement in response relative to an absolute value or the performance of a specific treatment arm.\n\n\nA Target dose posterior probability is specified as:\n\nMED or EDq.\nRelative to an absolute value or relative to the response on a Control or the Active Comparator.\nThe delta the MED must be better than, or the quantile of the effective dose.\nIf the endpoint is TTE and the design includes a predictor, then the definition of the QOI includes selecting which endpoint the QOI refers to.\n\nThe QOI will be given a name derived from these details, and alternative simpler name that can be used when accessing the output files from other software such as R.", + "objectID": "documentation/v71/userguides/crm.html#sec-context", + "href": "documentation/v71/userguides/crm.html#sec-context", + "title": "FACTS Dose Escalation CRM", + "section": "", + "text": "This document has been updated for the version 7.1 release of Dose Escalation FACTS.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#decision-quantities", - "href": "documentation/v71/userguides/core.html#decision-quantities", - "title": "FACTS Core User Guide", - "section": "5.5 Decision Quantities", - "text": "5.5 Decision Quantities\nThe QOI’s so far have defined values to be calculated across all the doses. For a Success / Futility decision to be taken, as well as the quantity to be tested, it is necessary to specify the treatment arm whose value is to be used. This selection can be by specifying a specific arm, but normally it is specified by using a “Probability of being Target” selection criteria. A simple and common example is “The probability of the response being better than that of the Control of the Treatment arm with the maximum response”:\n\n\nA decision QOI consists of (1) a QOI that has been calculated for each dose, and (2) at Target Dose QOI. The dose with the highest probability of being the target dose is selected and the value of the “per dose” QOI for that dose is the value used in the decision.\nFor example, evaluating a decision QOI that is the combination of\n\nThe probability of being better than Control by 2 points (Pr(θd – θ0 > 2))\nwith the target dose EDq relative to control; Quantile 0.9\n\nis the probability that the response of the ED90 is better than control by 2 points.\nInstead of a Target Dose QOI, it is also possible to specify a specific dose, or to use the terms “Max probability over all doses” and “Min probability over all doses” which mean that the dose with the minimum or maximum value of the per dose QOI is used. This enables:\n\nDecisions QOIs testing specific doses, for example by defining a Posterior probability QOI that compares all doses against the lowest dose, and then a Decision QOI using that posterior probability with the highest dose selected as the target dose it is possible to based decisions on the posterior probability that the highest dose is better than the lowest dose.\nA Decision QOI using “Max …” allows a decision to be based on whether a probability or p-value is greater than a threshold at any dose, or less than a threshold at all doses.\nA Decision QOI using “Min …” allows a decision to be based on whether a probability or p-value is less than a threshold for any dose or greater than a threshold at all doses.\n\nThere is one special case: if the QOI chosen is the Trend Test p-value, then because this is not actually a per-dose value, only one “Target dose” can be selected: “Overall Significance”.", + "objectID": "documentation/v71/userguides/crm.html#sec-citing", + "href": "documentation/v71/userguides/crm.html#sec-citing", + "title": "FACTS Dose Escalation CRM", + "section": "", + "text": "If writing in LaTex and using Bibtex, if you wish to cite FACTS (thank you!), can we suggest the following:\n@techreport{FACTS71,\n author = {{FACTS Development Team}},\n title = {{FACTS}: Fixed and Adaptive Clinical Trial Simulator},\n year = {2024},\n month = {12},\n number = {Version 7.1},\n type = {Computer Software},\n institution = {Berry Consultants LLC},\n address = {Austin, TX},\n note = {https://www.berryconsultants.com/software/facts/}\n}\nThis will result in a reference that, for example in the APA style, will look like the following:\nFACTS Development Team (2024). FACTS: Fixed and adaptive clinical trial simulator. Computer Software Version 7.1, Berry Consultants LLC, Austin, TX. https://www.berryconsultants.com/software/facts/.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#standard-evaluation-variables", - "href": "documentation/v71/userguides/core.html#standard-evaluation-variables", - "title": "FACTS Core User Guide", - "section": "5.6 Standard Evaluation Variables", - "text": "5.6 Standard Evaluation Variables\nThese 2 parameters are used across some of the default QOIs and hence specified outside the normal QOI dialog boxes.\n\nThe CSD value\nand whether absolute or relative to the Control arm\n\nthese are used in both the default “Pr(CSD)” and the “MED relative to Control” QOIs. \nNote that the CSD value here is designed to be usually entered as a positive value, as in earlier versions of FACTS. Its sign is automatically adjusted if “lower score means subject improvement” or if the trial is a non-inferiority trial.\nThese adjustments are not made for other user entered QOI, the directions of comparison both for the definition of the probability to be calculated and the comparison of the resulting probability with a threshold are under the user’s control as are whether delta’s are –ve or +ve. This allows the user to define QOI’s in whatever fashion is natural to them and the team.\nWhen there is no custom and practice as to how an endpoint and associated probability are expressed and used, it is recommended that the usual practice should be to create probabilities that are large when they are ‘good’ and low when they are ‘bad’. So tests for success are usually “> threshold” and for futility are “< threshold”. Using this convention whenever it is does not feel unnatural will reduce confusion and the opportunity for mistakes.\n\n5.6.1 The direction of comparison for default QOIs\nNote that as a result of being able to specify whether a higher or lower response represents improvement, and whether the aim is superiority or non-inferiority, the CSD or the NIM will almost always be a positive value. FACTS will automatically determine which direction is appropriate (e.g. if lower values are subject improvement, the engine will realize a CSD will need to be subtracted from the control score before comparing with the estimate of response on a treatment arm).", + "objectID": "documentation/v71/userguides/crm.html#sec-definitions", + "href": "documentation/v71/userguides/crm.html#sec-definitions", + "title": "FACTS Dose Escalation CRM", + "section": "", + "text": "Table 1 gives an overview of the acronyms and abbreviations used in this document.\n\n\n\nTable 1: List of terms used in the CRM user guide\n\n\n\n\n\n\n\n\n\nName\nDefinition\n\n\n\n\nCap\nA limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap.\n\n\nControl\nIs the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\n\n\nCore\nFACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\n\n\nCRM\nContinual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\n\n\nDE\nDose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\n\n\nED\nEnrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications.\n\n\nFACTS\nFixed and Adaptive Clinical Trial Simulator.\n\n\nFinal Endpoint\nThe final value, or state, of a subject’s endpoint.\n\n\nGUI\nGraphical User Interface, the part of the FACTS application that the user interacts with.\n\n\nMethod\nIn the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\n\n\nModel\nIn the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\n\n\nMTD\nThe dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD).\n\n\nMTD+\nThe dose most likely to be the MTD+ – the dose with the highest Pr(MTD+).\n\n\nPr(MTD)\nA dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses.\n\n\nPr(MTD+)\nA dose’s probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range.\n\n\nProfile\nA profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nScenario\nA scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include: -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups -) the properties of subjects’ early responses and the correlation with their final outcome -) the rate at which subjects are recruited into the trial -) the rate at which subjects drop out of the trial.\n\n\nSPEC\nThe Design Engine Specification, describes the system algorithms, and meaning of parameters.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nSubject\nSomeone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\n\n\nTreatment Arm\nSubjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\n\n\nUG\nThe User Guide; describes how to use the system.", + "crumbs": [ + "Documentation", + "Version 7.1", + "User Guides", + "FACTS Dose Escalation CRM" + ] + }, + { + "objectID": "documentation/v71/userguides/crm.html#facts-7.1-changes-to-n-crm", + "href": "documentation/v71/userguides/crm.html#facts-7.1-changes-to-n-crm", + "title": "FACTS Dose Escalation CRM", + "section": "2.1 FACTS 7.1 Changes to N-CRM", + "text": "2.1 FACTS 7.1 Changes to N-CRM\nIn FACTS 7.1 there were new features added to N-CRM:\n\nIt is now possible to backfill to the current escalation dose (also known as “frontfilling”).\nIt is now possible to specify a third queue concept – maximum number of patients in their DLT period on the current MTD estimate.\nIt is now possible to define the concept of “near” target/MTD as part of stopping rules, for both fine-grained and regular dosing.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#evaluation-of-bayesian-posterior-estimates", - "href": "documentation/v71/userguides/core.html#evaluation-of-bayesian-posterior-estimates", - "title": "FACTS Core User Guide", - "section": "6.1 Evaluation of Bayesian Posterior Estimates", - "text": "6.1 Evaluation of Bayesian Posterior Estimates\nThe Bayesian model fitted to the data at each update contains a dose response model and usually a longitudinal model. In the absence of a longitudinal model, the posterior is calculated as:\n\\[p(\\omega|Y) \\propto \\prod\\_{i = 1}^{n}{p(y\\_{i}|\\phi)p(\\phi)}\\]\nwhere ϕ is the set of parameters of the selected response model, p(ϕ) is the prior for those parameters, yi is the final response for each subject and n is the number of subjects.\nWith a longitudinal model, this becomes:\n\\[p(\\omega|Y) \\propto \\prod\\_{i = 1}^{n}{p(y\\_{i}|\\phi)p(\\phi)\\prod\\_{i = 1}^{n}{\\prod\\_{j = 1}^{L}{p(y\\_{ij}|\\psi)p(\\psi)}}}\\]\nwhere ψ is the set of parameters of the selected longitudinal model, p(ψ) is the prior for those parameters, y*i**j* is the response for each subject at each visit and L is the number of visits.\nThe posterior is evaluated using MCMC with individual parameters updated by Metropolis Hastings (or Gibbs sampling where possible), using only the yi and y*i**j* data available at the time of the update.", + "objectID": "documentation/v71/userguides/crm.html#facts-7.0-changes-to-n-crm", + "href": "documentation/v71/userguides/crm.html#facts-7.0-changes-to-n-crm", + "title": "FACTS Dose Escalation CRM", + "section": "2.2 FACTS 7.0 Changes to N-CRM", + "text": "2.2 FACTS 7.0 Changes to N-CRM\nIn FACTS 7.0 the only change was on the Analysis tab, when entering subject data manually, the FACTS GUI now ensures that a cohort number is entered for every subject.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#continuous-dichotomous-and-log-odds", - "href": "documentation/v71/userguides/core.html#continuous-dichotomous-and-log-odds", - "title": "FACTS Core User Guide", - "section": "7.1 Continuous, Dichotomous and Log-Odds", - "text": "7.1 Continuous, Dichotomous and Log-Odds\nWith the exception of two dose response models specific to a dichotomous endpoint, the same dose response modeling facilities are available for all endpoints.\nLet there be D total doses including the control arm if it exists. For any endpoint, the estimate of dose response model is called θd for a dose d ∈ {1, …, D}.\n\nIn the continuous case the individual response/change from baseline (if it exists) Yi of the i*t**h subject allocated to dose di is modeled: Yi ∼ N(θdi, σ2). The variance σ*2 has an inverse-gamma prior.\nIn the dichotomous case the final endpoint of the i*th subject who has been allocated to dose di is modeled: Yi ∼ Bernoull**i(Pdi) where Pdi is the probability of response for a subject on dose di. The probability Pd is modelled on the logit scale, so \\(P\\_{d} = \\frac{e^{\\theta\\_{d}}}{1 + e^{\\theta\\_{d}}}\\), and thus θd* is the log-odds ratio: \\(\\theta\\_{d} = ln\\left( \\frac{P\\_{d}}{1 - P\\_{d}} \\right)\\),\nIn the time-to-event case the time to a subject’s response, Yi is modeled as piece-wise exponentially distributed with hazard rates, λs for pieces s ∈ {1, …S}. So, Yi ∼ PWExp({λ1, …, λS}) for a subject on the control arm, and Yi ∼ PWExp({λ1eθd, …, λSeθd}) for non-control doses. Then, θd is the log-hazard ratio \\(\\left( \\ln\\left( \\frac{\\lambda\\_{s}e^{\\theta\\_{d}}}{\\lambda\\_{s}} \\right) = \\ln\\left( e^{\\theta\\_{d}} \\right) = \\theta\\_{d} \\right)\\) averaged over the observation time segments. This formulation implies a proportional treatment effect across the pieces of the piece-wise exponential.\n\nEach dose response model is parameterized in terms of θd, but each endpoint models this parameter on a different scale. The dichotomous dose response models are on the log-odds scale, and the time-to-event endpoint models are on the log hazard ratio. When specifying a prior distribution for a continuous endpoint dose response model the expected data mean and variance determine which priors should be considered non-informative. When estimating a probability in the dichotomous case, using a prior with standard deviation above, say, 10 leads to a diffuse distribution on the log-odds scale, but results in a prior distribution on the probability scale that is heavily peaked at 0 and 1. This can lead to undesirable model results and decisions being made in small sample size situations, and numerical instability in extreme cases. Similarly on the time-to-event scale, the prior put on the log-hazard ratio θd is exponentiated before being multiplied by the hazard rate, so diffuse priors on the log-hazard can have unexpected modelled results. Again, time-to-event θd priors that have standard deviations less than about 10 are generally acceptably diffuse for most situations while avoiding edge case curiosities.", + "objectID": "documentation/v71/userguides/crm.html#facts-6.5-changes-to-n-crm", + "href": "documentation/v71/userguides/crm.html#facts-6.5-changes-to-n-crm", + "title": "FACTS Dose Escalation CRM", + "section": "2.3 FACTS 6.5 Changes to N-CRM", + "text": "2.3 FACTS 6.5 Changes to N-CRM\nIn FACTS 6.5 there was a new feature added to N-CRM:\n\nIt is now possible to generate a design report – a Word document describing design - once the design has been simulated. In FACTS 6.5 there was two small changes to the functionality:\nWhen deriving toxicity/efficacy priors from quantiles at the lowest and highest doses, the “middle” probability option now refers to the median dose rather than the reference dose and is now optional. When pre-6.5 FACTS files are loaded in FACTS 6.5, the “middle” probability option will be ignored and replaced by 0.5.\nWhen deriving toxicity/efficacy priors from specific quantiles the specification of at least two dose levels is now required whereas previously the specification of at least three dose levels was required.\n\nIn FACTS 6.5 there were some improvements in the simulated behavior:\n\nDesigns which include efficacy, the “Maximum cohorts used to determine MTD” parameter on the Allocation Rule tab is now observed, in FACTS 6.4 and earlier it was ignored.\nIn N-CRM designs using open enrollment without accrual pausing, FACTS will now output entries in the cohort file for subjects that have been lost following stopping rules being met.\nIn N-CRM designs using open enrollment, FACTS will no longer prematurely apply stopping conditions when there are still subjects whose outcomes have been observed, but not yet processed.\nIn N-CRM designs using open enrollment, FACTS will now report the selected MTD/MED/OSD and associated state to be the dose where the stopping conditions were first met, unless the MTD has subsequently decreased post stopping rules being met. This is to prevent a dose above the one selected when the stopping conditions were met being reported as the MTD when it is very likely that there is insufficient data on this higher dose to justify its selection. If rather than reporting the MTD at the point when the stopping rules where met, you would like the trial to resume if the dose selected as MTD has changed (and this the stopping rules possibly no longer met), ensure that the ”Pause accrual and wait for completers” option is selected on the “Stopping Criteria” tab. This allows the trial to resume if the recruitment cap has not been met.\nFACTS Command Line mode and FLFLL (FACTS Linux File Loader Lite) now correctly handle the processing of N-CRM designs whose prior was derived using the “Legacy Prior” option.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#descriptions-of-dose-response-models", - "href": "documentation/v71/userguides/core.html#descriptions-of-dose-response-models", - "title": "FACTS Core User Guide", - "section": "7.2 Descriptions of Dose Response Models", - "text": "7.2 Descriptions of Dose Response Models\nThe Dose Response section of the Design tab allows the user to specify how to analyze the relationship between dose/treatment arm and the final response and hence estimate the values θd. The interpretation of θd depends on the nature of the endpoint:\n\nWhere the response is continuous, θd is the estimate of the mean response/change from baseline on treatment arm d, and the common inter-subject variance of the response σ2, is also estimated.\nWhere the response is dichotomous, θd is the estimate of the log-odds of the probability of observing a response on the treatment arm d.\nWhere the response is time-to-event, θd is the estimate of the log hazard ratio compared to the control arm on the treatment arm d.\n\nExcept where the endpoint is time to event, the response on the control arm, θ0, is estimated and can be included in the dose response model or modeled separately. When the endpoint is time-to-event, the response rate on the control arm, λ is estimated and θd for d ∈ {1, 2, …, D} is the log hazard of the response rate of each treatment arm compared to the control arm, so θ0 ≡ 0.\nSome, but not all, of the dose response models use the effective dose strength, νd, to model the dose response θd. The effective dose strength is specified on the Study > Treatment Arms tab. It is always fixed at 0 for the control arm (ν0 = 0).\n\n7.2.1 Independent Dose Model\nThe “Independent Dose Model” providing a simple pair-wise comparison between the study drug arms and the control arm and/or the active comparator arm. The doses are modelled as independent and normally distributed with a prior of:\nθd ∼ N(μd, νd2)\nWhere μd and vd2 are specified in FACTS and can be the same or vary across arms.\nThis model is useful:\n\nWhen there is only one or two experimental arms\nWhen the study drug arms don’t differ by dose but in other ways, so there is no ordered sequence of treatments – e.g. each arm is the study drug in combination with a different additional drug.\nFor simulating simple trial designs\nFor simulating a ‘conventional’ or ‘strawman’ design to compare more complex designs against\n\nOtherwise for trials with multiple related arms that differ by dose, it is usually more efficient to use a dose-response model.\n\n\n7.2.2 Independent Beta-Binomial Model (Dichotomous Only)\nThis is a “no model” option similar to the above, but only available for the Dichotomous endpoint. Unlike any other dose response model, this model uses the beta distribution to model the probability of response directly rather than fitting a model to the log-odds of the probability.\nThe final endpoint response Yi is modeled as:\nYi ∼ Bernoulli(Pd)\nwhere Pd is the probability that a patient is a response at the final endpoint for subjects randomized to dose d. With posterior\nPd ∼ Beta(αd + respondersd,   βd + non_*responder**sd*)\nWhere αd, βd are the priors for the arm d, respondersd is the number of responders on arm d and non_respondersd is the number of non-responders on arm d.\nThis model has the advantages of an easier to understand prior, and better estimation of Pd when the number of responders and non-responders is small (either is < 5) compared to the log-odds model. As it’s an independent model it is well suited to analyzing single arm, two arm or three arm trials, or trials where the experimental arms are unrelated, and so there is no basis on which to borrow information between them. With trials with multiple arms of the same treatment at different doses it is usually more advantageous to fit a dose response model.\n\n\n7.2.3 Simple NDLM\nThe Normal Dynamic Linear Model (NDLM) estimates the final endpoint as a smoothed curve across doses included in the model. Doses are tied directly to their nearest neighbor, and the prior expectation for a dose is that it is equal to its neighboring doses, tending to a constant dose response across doses in the absence of data. The model is defined as follows:\nLet doses d = d′, …, D be doses in the dose response model and θd be the estimated dose response for dose d. The initial dose d′ = 1 if there is no control or control is included in the dose response model, and d′ = 2 if the control arm is modelled separately.\nThe dose response of the first dose, d′, has a prior of:\nθd′ ∼ N(μd′, τd′2)\nwhere μd′ and τd′2 are specified directly in FACTS. Subsequent dose response estimates θd′ + 1, …, θD have priors centered at the previous dose response with variances based on the distance between the dose d strength and the dose d − 1 strength. Specifically,\nθd ∼ N(θd − 1, τd − 12) for d = d′ + 1, …, D\nwhere for dose strengths vd and vd − 1, td − 12 is defined as\nτd − 12 = τ2(vd − vd − 1)\nThe prior distribution for the “drift” parameter, which controls the amount of smoothing is:\n\\[\\tau^{2}\\sim IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nwhere τμ and τn are specified in the Dose Response tab in FACTS under Model Parameters.\nIn the continuous case the residual error around the estimated dose response is\n\\[\\sigma^{2}\\sim IG\\left( \\frac{\\sigma\\_{n}}{2},\\frac{\\sigma\\_{\\mu}^{2}\\sigma\\_{n}}{2} \\right)\\]\nwhere σμ and σn are specified on the Dose Response tab in FACTS under Error Parameters.\nThe Simple NDLM is generally a good model to use when the shape of the likely dose response is unknown, but we would like to borrow information between a dose and its neighboring doses. No monotonicity or pre-determined shape is enforced by the Simple NDLM. The variance in dose response from dose to dose is updated based on the observed data, but as the number of doses in a trial is typically small, a moderately informative prior is often used.\nIn a ‘null’ scenario where the response on all the doses is the same as control, the simple NDLM reduces type-1 error. The estimate of τ2 tends towards zero and the estimate of the dose response tends to a flat line. The smoothing of the estimates of the response reduces the random fluctuations in the estimates from dose to dose and is a very effective counter to the problem of type-1 error inflation due to the multiplicity of doses being tested. A small prior for the mean value of τ will accentuate this effect. The price to be paid for this benefit is a tendency to underestimate large changes in response or where there is a peak in the response. This over-smoothing can reduce power. A prior for the mean of τ centered at large values will minimize over-smoothing, and a very large prior would simply remove any smoothing effect at all. A standard prior for the mean of τ would be the expected average change in response from dose to dose, scaled to take into account the differences in the specified effective dose strengths.\nUsually, the choice of prior for τ2 is tuned based on simulation results, trading off reducing type-1 error in the null case against loss of power and reduced estimate of maximum response in the effective scenario with the largest jump in response or steepest peak.\nAside: When using the NDLM model or any of its alternatives (2nd order or Monotonic NDLM), and including doses in a design that receive no subject allocation (ie. Allocation ratio set to 0), some important characteristics of the model should be considered in the interpretation of results. First, the NDLM model “borrows” information from neighbouring doses, and therefore including unallocated intermediate doses will increase uncertainty in the fitted response. Information must “pass through” these intermediate doses, and uncertainty should be expected to increase as the number of intermediate unallocated doses between two allocated doses increases. Secondly, the NDLM model estimates the response at unallocated doses, but without subject data at these doses the uncertainty in the estimate can be considerably larger than doses with subject data. This high degree of uncertainty can lead to a vestigial probability that an unallocated dose is the target dose (Pr(EDx), Pr(MED), Pr(Max)) even though the mean response estimate and probabilities at neighbouring doses with subject data would not suggest this to be the case.\n\n\n7.2.4 Monotonic NDLM\nThe Monotonic NDLM endpoint model is similar to the NDLM in the sense that it smooths dose response estimates using neighboring doses, but is constrained to be either monotonically increasing or monotonically decreasing across doses. The direction of monotonicity depends on the value specified in the “Monotonic:” selection in the Model Parameters section of the Monotonic NDLM Dose Response page.\nThe use of this model is generally limited to endpoints where a strong presumption of increasing/decreasing response with dose is reasonable – such as a biomarker or a toxicity endpoint.\nLet doses d = d′, …, D be doses in the dose response model and θd be the estimated dose response for dose d. The initial dose d′ = 1 if there is no control or control is included in the dose response model, and d′ = 2 if the control arm is modelled separately. The following model is the monotonically positive NDLM:\nθd′ ∼ N(μd′, τd′2)\nand\nθd ∼ N+(θd − 1, τd − 12) for d = d′, …, D,\nWhere τd − 12 is defined as in the NDLM, and X ∼ N+(μ, σ2) refers to a positive truncated normal distribution with density function:\n\\(f\\_{X}(x) = \\frac{1 - \\Phi\\left( - \\frac{\\mu}{\\sigma} \\right)}{\\sqrt{2\\pi}\\sigma}\\exp\\left\\\\ - \\frac{1}{2\\sigma^{2}}(x - \\mu)^{2} \\right\\\\\\) for x > 0.\nThe result of this dose-response model is that the curve is monotonically increasing, in that θd > θd − 1.\nThe monotonically decreasing NDLM is similar except:\nθd ∼ N−(θd − 1, τd − 12) for d = d′, …, D,\nWhere X ∼ N−(μ, σ2) refers to a negative truncated normal distribution:\n\\(f\\_{X}(x) = \\frac{\\Phi\\left( - \\frac{\\mu}{\\sigma} \\right)}{\\sqrt{2\\pi}\\sigma}\\exp\\left\\\\ - \\frac{1}{2\\sigma^{2}}(x - \\mu)^{2} \\right\\\\\\) for x < 0.\nThe result of this dose-response model is that the curve is monotonically decreasing, in that θd < θd − 1.\n\n\n7.2.5 Second Order NDLM\nThe second order NDLM described in this section is the version utilized in FACTSTM version 4.0 and later. The model labelled “Second Order NDLM” versions before 4.0 is now maintained as the model labelled “Legacy 2nd Order NDLM.” The second order NDLM serves as a “smoother” similar to the NDLM, however it tends to smooth toward a linear fit with a slope (the NDLM itself tends to shrink each dose’s fit toward its neighbours, while the second order NDLM prefers any trend in the neighbours).\nLet doses d = d′, …, D be doses in the dose response model and θd be the estimated dose response for dose d. The initial dose d′ = 1 if there is no control arm or control is included in the dose response model, and d′ = 2 if the control arm is modelled separately. The initial dose d′ is modelled:\nθd′ ∼ N(μ0, τ02)\nWhere μ0 and τ02 are specified directly in FACTS.\nIn the case of TTE, the initial dose d′ is the control arm, and has a θd′ = 0 by definition, so no prior distribution is needed.\nThe prior distribution for the dose response for the dose directly after the initial dose is specified on the difference between the d′ and d′ + 1 level doses:\nθd′ + 1 − θd′ ∼ N(μ1, τ12)\nSuccessive doses are then modelled based on differences in slope between the dose and the two doses below them. Let:\n\\[\\theta\\_{d} = \\theta\\_{d - 1} + \\Delta\\_{d}\\zeta\\_{d} + \\frac{\\Delta\\_{d}}{\\Delta\\_{d - 1}}\\left( \\theta\\_{d - 1} - \\theta\\_{d - 2} \\right)\\]\nfor doses d = d′ + 2, …, D, where Δd = νd − νd − 1 and Δd − 1 = νd − 1 − νd − 2. The priors for the dose response smoothing terms ζd are:\nζd ∼ N(0, τ22)\nThe smoothing is determined by the parameter τ2. Small values of τ2 lead to more smoothing, while large values of τ2 lead to little information sharing between doses (above dose 1). Note that “small” and “large” is dependent on the scale of the doses. The prior on the smoothing parameter is:\n\\[\\tau\\_{2}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nwhere τμ is a central value for τ2, and τn is the prior weight.\nNote that that in this formulation, τ22 can be thought of as the deviation from linearity. The linear scaling of deviations thus leads to a conditional variance that scales as the square of the dose difference:\nVar[θd|θd − 1, θd − 2]= τ22•(νd − νd − 1)2\nThe Second Order NDLM, like the Simple NDLM, is generally a good model to use when the shape of the likely dose response is unknown, but we would like to borrow information between a dose and its neighboring doses. No monotonicity or pre-determined shape is enforced by the Second Order NDLM. The variance in dose response from dose to dose is updated based on the observed data, but as the number of doses in a trial is typically small, a moderately informative prior is often used.\nIn a ‘null’ scenario where the response on all the doses is the same as control, like the simple NDLM, the second order NDLM reduces type-1 error. As the estimate of τ2 tends to zero and the estimate of the dose response tends to a line (with non-zero slope if appropriate).\nThe second order NDLM has more power than the Simple NDLM when the dose response is smooth, but will tend to underestimate by more than the Simple NDLM if there are marked peaks or steps in the response. Because it borrows from two doses, it is better at estimating a response for a dose where there is no data than the simple NDLM can, and can be used with burn-in’s where not all doses have been allocated to, but doesn’t cope well if there are consecutive doses where there is no data.\nHowever, unlike the simple NDLMs where the variance structure is preserved if doses are added to or dropped from the design, this is not true for the 2nd order NLDM. Thus, if using the 2nd order NDLM, and the doses that are available to the model are changed, then the parameters for the prior for τ22 may need to be re-visited.\nThe simple NDLM is likely to be preferred where there are fewer doses (4-5), and the second order NDLM is often preferred when there are 7 or more (it will depend on the expected smoothness of the response – the smoother it is the more useful the second order NDLM will be).\nAs with the simple NDLM, the choice of prior for τ2 can be tuned based on simulation results: balancing having a smaller prior that limits type-1 error in the null case, against having a larger prior that yields more power and better estimate of maximum response in the effective scenarios with the large jumps in response or pronounced peaks.\n\n\n7.2.6 3-Parameter Logistic\nThe 3-parameter logistic dose response model estimates efficacy as a smooth curve using an intuitive parameterization. The dose response for a dose d with effective dose strength vd is:\n\\[\\theta\\_{d} = a\\_{1} + \\frac{a\\_{2}v\\_{d}}{v\\_{d} + a\\_{3}}\\]\nWhere the a parameters have the following description:\na1 is the estimated dose response for a dose of strength 0\n\na2 is the estimated change in dose response for a dose with strength ∞ when compared to a dose of strength 0.\na3 is the estimated ED50, the dose that has 50% of the dose response maximum (a2)\n\nThe shape of the 3-parameter logistic curve can vary wildly based on the parameter values, but always starts at a1 at dose strength 0 and monotonically increases to a1 + a2 as the effective dose strength goes to infinity.\nThe following independent prior distributions are assumed:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\nIn the continuous case, the prior distribution for the error term in the 3-Parameter Logistic is Inverse Gamma:\n\\[\\sigma^{2}\\sim IG\\left( \\frac{\\sigma\\_{n}}{2},\\frac{\\sigma\\_{\\mu}^{2}\\sigma\\_{n}}{2} \\right)\\]\nAn advantage of the 3-Parameter Logistic model is that it is has a small number of parameters that have defined, intuitive interpretations. Since there are few parameters it’s generally easy to estimate the parameters even on small amounts of data. Because of the limited flexibility of the logistic curve, the 3-parameter logistic model should only be used when there is evidence that it is appropriate. See the Hierarchical Logistic and Sigmoid (Emax) models for dose response models with a similar pattern, but slightly more flexibility in shape.\n\n\n7.2.7 Hierarchical Logistic\nThe hierarchical logistic model is an extension of the 3-parameter logistic with the form:\n\\[\\theta\\_{d} = a\\_{1} + \\frac{a\\_{2}v\\_{d}}{v\\_{d} + a\\_{3}} + \\zeta\\_{d}\\]\nwhere ζd is a random intercept term that modifies a1 differently for each dose under the constraint that all ζd must sum to 0.\nThe additional term ζd is a per dose ‘off-curve’ effect. It allows for a secondary non-parametric dose effect over and above the logistic model. It has been used in circumstances in which there is actually some falling away of effect at the highest dose. This is an example mean fit from 100 simulations. The model fit and error bars are in green, and the true dose responses are shown by the black line.\n\nζd is modelled as:\nζd ∼ N(0, a42)\nconditioned that\n\\[\\sum\\_{d}^{}\\zeta\\_{d} = 0\\]\nAnd a42 has an inverse gamma prior:\n\\[a\\_{4}^{2}\\sim IG\\left( \\frac{\\Lambda\\_{n}}{2},\\frac{\\Lambda\\_{\\mu}^{2}\\Lambda\\_{n}}{2} \\right)\\]\nThe following independent prior distributions are assumed:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\nA typical recommended value for the center of the prior distribution of α4 is the largest expected likely deviation in true response from the underlying logistic with a weight of 1. The effect of this prior is then checked through simulation of a range of plausible dose response profiles, with a range of designs to check the sensitivity of the final estimate of response to this prior.\nIn this model, compared to the ‘plain’ 3-parameter logistic above, it is important that the true ED50 lies within the expected dose range, and that the prior for the ED50, a3, has the majority of its probability mass in the available dose range, for example if the range of the effective dose strengths is from 0 to νD, then a typical ‘weakly informative’ prior for a3 would be:\n\\[a\\_{3}\\\\\\sim\\\\N^{+}\\left( \\frac{\\nu\\_{D}}{2},\\left( \\frac{\\nu\\_{D}}{2} \\right)^{2} \\right)\\]\nUsing a weaker prior, such as: N+(νD, (νD)2), leads to a more linear fit, for instance with just this change to the prior for a3 the average of the estimated of the mean response change from the graph above, to:\n\n\n\n7.2.8 Sigmoid Model\nA sigmoid model (Emax model) provides a coherent parameterization of the dose response trend similar to the 3-parameter logistic, but with one extra shape parameter, a4.\nThe model formula is:\n\\[\\theta\\_{d} = a\\_{1} + \\frac{(a\\_{2} - a\\_{1})v\\_{d}^{a\\_{4}}}{{a\\_{3}}^{a\\_{4}} + v\\_{d}^{a\\_{4}}}\\]\nThe interpretation of the four parameters is:\na1 is the estimated dose response for a dose of strength 0\n\na2 is the estimated dose response for a dose of strength ∞ (slight difference from Logistic models)\na3 is the estimated ED50, the dose that has 50% of the dose response maximum attainable effect (a2 − a1)\na4 controls the slope of the dose response model at the ED50. A larger value of a4 corresponds to a steeper slope. A value of a4 = 1 makes the Sigmoid model equivalent to a Three Parameter Logistic model with a2 equal to a1 + a2 from the Sigmoid model. A value of a4 approaching 0 corresponds to a dose response model that is nearly flat at \\(\\frac{a\\_{1} + a\\_{2}}{2}\\). By differentiation, it can be seen that the slope where the effective dose νd = a3 is \\((a\\_{2} - a\\_{1})\\frac{a\\_{4}}{4a\\_{3}}\\).\n\nThe following independent prior distributions are assumed:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\na4 ∼ N+(Λ4, λ42)\nThe advantage of the model is that it is considerably more flexible than the logistic, but still more efficient to estimate than an NDLM. This model (if applicable) is ideal if the target is an Effective Dose (ED) such as an ED90. Estimating an ED requires estimating the response on control, the maximum response, and the gradient which is requires a lot of data to do well if using no model or a smoothing model such as one of the NDLMs. With the 4-parameter sigmoid model (or 3-parameter logistic – but that has a more limited applicability due to being significantly less flexible in shape), it’s usually not an issue to estimate the EDx well.\nThe caveats to using this model are:\n\nWhilst being much more flexible than the logistic, it still has model assumptions, in particular monotonicity, that must be met for this to be a reasonable model to be used.\nThe curve is only well estimated if the true ED50 lies within the doses tested.\nLike the hierarchical logistic model above, the prior for a3 should be weakly informative, with the majority of its probability mass in the available dose range. So similarly, if the range of the effective dose strengths is from 0 to νD then a typical ‘weakly informative’ prior for α3 would be:\n\n\n\\[a\\_{3}\\\\\\sim\\\\N^{+}\\left( \\frac{\\nu\\_{D}}{2},\\left( \\frac{\\nu\\_{D}}{2} \\right)^{2} \\right)\\]\n\n\n\n\n7.2.9 U-Shaped Model\nThe U-shaped model when the allows for an initial increase (decrease) in the dose response with dose, followed by a levelling out of the mean, then a decrease (increase). Whether the U-Shaped model increases then decreases or decreases then increases is specified by the user on the Dose Response tab. An example curve for this model is given in the figure below.\nThe dose-response curve can be characterized in four different regions of doses. For the first region, which contains the lowest doses, 0 < νd < pmin, the dose-response curve is increasing (decreasing):\n\\[\\theta\\_{d} = \\theta\\_{0} + S \\bullet \\delta \\bullet \\left( \\frac{\\nu\\_{d}}{p\\_{\\min}} \\right)^{\\alpha}\\]\nThe next region is the plateau, where the dose-response curve is constant. For pmin < νd < pmin + pwidth:\nθd = θ0 + S • δ\nFor the third region, the dose-response curve is decreasing (increasing). For pmin + pwidth < νd < pmin + pwidth + wwidth,\n\\[\\theta\\_{d} = \\theta\\_{0} + S \\bullet \\delta \\bullet \\left( 1 - \\frac{\\nu\\_{d} - \\left( p\\_{\\min} + p\\_{width} \\right)}{w\\_{width}} \\right)^{\\beta}\\]\nFor the final region, the dose-response curve is again constant, at the same level as the zero-dose. For νd > pmin + pwidth + wwidth,\nθd = θ0\nThe parameters of the model are described below:\n\nS is 1 or -1, as determined by the Model is increasing/decreasing radio buttons. S=1 if Model is Increasing is selected, indicating that the model starts increasing at low doses.\nθ0 represents the zero-strength dose response:\n\n\nθ0 ∼ N(μ0, σ02)\n\n\nδ represents the maximal change in response from the zero-strength dose. It is restricted to be positive:\n\n\nδ ∼ N+(μδ, σδ2)\n\n\npmin represents the lowest dose at which the maximal change in response from the zero-strength is achieved. It is restricted to be positive:\n\n\npmin ∼ N+(μmin, σmin2)\n\n\npwidth represents the width of the plateau – the region where all doses achieve maximal change in response from the zero-strength dose. It is restricted to be positive:\n\n\npwidth ∼ N+(μwidth, σwidth2)\n\n\nwwidth represents the width of the region for doses beyond the plateau, where response is returning to the zero-strength dose level. It is restricted to be positive:\n\n\nwwidth ∼ N+(μw, σw2)\n\n\nα determines the rate of change of the dose response curve for doses below the plateau. Values less than 1 indicate a rapid initial change from baseline, with slower change as the plateau is reached. Values greater than 1 indicate a slow initial change from baseline, with more rapid change as the plateau is reached. To help avoid identifiability issues, α is restricted to be between 10-1 and 101.\n\n\nα ∼ *L**N*(μα, σα*2)\n\nwhere *L**N** represents the lognormal distribution, with the truncation constraints at 10-1 and 101.\n\nβ determines the rate of change of the dose response curve for doses beyond the plateau. Values less than 1 indicate a slow initial change from the plateau level, with more rapid change subsequently. Values greater than 1 indicate a rapid initial change from the plateau level, with slower change subsequently. To help avoid identifiability issues, β is restricted to be between 10-1 and 101:\n\n\nβ ∼ *L**N*(μβ, σβ*2)\n\nThe U-shaped model has seven free parameters, and thus it is inadvisable to use such a model for dose-finding trial designs that contain only a few dose levels. When a small number of doses are available, it may help to constrain the values of α and β by utilizing small standard deviations in the priors.\n\n\n\n7.2.10 Plateau Model\nThe plateau model is a special case of the U-shaped model, in which pwidth = ∞. That is, there is no return to baseline for high doses. This model thus eliminates three parameters, since pwidth, wwidth, and β are not used. See the figure below to see an example dose response model for the plateau model that mimics the beginning of the U-Shaped model above.\n\n\n\n7.2.11 3 Parameter Exp Logistic (Dichotomous Only)\nThe 3-parameter exponential logistic model has the following structure:\nθd = a1 + a2 * νda3\nWhere νd is the effective dose strength of dose d. This is a logistic model for the dichotomous endpoint because θd is the log odds ratio of the probability of the response, Pd at dose d.\nThe exponent parameter α3 allows the change in slope at the lower end of the curve to be asymmetric in comparison to the change in curve at the upper end of the curve.\nThe priors for the parameters are:\na1 ∼ N(Λ1, λ12)\na2 ∼ N(Λ2, λ22)\na3 ∼ N+(Λ3, λ32)\nThe interpretations of the parameters defining this model are:\na1 is the dose response for a dose with strength 0\na2 is the slope associated with the exponentiated dose strength\na3 is a shape parameter modifying the effective dose strength through exponentiation.\nThe figure below shows an example of two different exp3-paramtere exponential logistic model fits. Notably, the fit showing in green has an a3 parameter greater than 1, which leads to faster increases of the sigmoid model as the effective dose strength increases.\n\n\n\n7.2.12 Hierarchical Model\nLike the Independent Dose Model, the hierarchical model treats the arms as if they are an unordered set of treatments, but unlike the Independent Dose Model the Hierarchical Model shares information between doses included in the model. The hierarchical model is a way of encouraging the estimates of arm responses to be similar, and the degree of this encouragement can be controlled using parameters of the prior distribution. The hierarchical model assumes that the arm parameters are drawn from the same normal distribution:\nθd ∼ N(μ, τ2)\nWhere d is the set of doses included in the model. The prior distributions for μ and τ2 are\nμ ∼ N(Λμ, λμ2)\nand\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nwhere τμ is a central value for τ, and τn is the prior weight. τ2 governs the amount of information sharing between doses in the model. The estimates of the dose parameters can be encouraged to be close together by choosing a small value for τμ and a large value for τn.\nThe control arm can be included in the hierarchical model, if it is desired to encourage the experimental arms to be similar to the control arm, or excluded from it, if the experimental arms are encouraged to be similar to each other but not necessarily to the control arm. The exception is with time-to-event data, when the control arm must be excluded from the hierarchical model.\n\n\n7.2.13 Linear Model\nThe linear model uses a strong assumption of exact linearity between the responses and the dose strengths. (For dichotomous models, the linearity is on the log-odds scale, and the linearity is on the log hazard ratio scale for TTE models.) The model is\nθd = α + *β**νd*\nfor all doses d in the model. Both α and β are given normal prior distributions:\nα ∼ N(Λα, λα2)\nβ ∼ N(Λβ, λβ2)\nThe linear model is appropriate when there is strong scientific knowledge that the shape of the response curve should be linear as a function of dose strength. Note that if an arm has a dose strength between two other arms in the model, its response will always be estimated to be between the responses of those two arms. As a result, the linear model may not be appropriate in combination with certain decision quantities such as Pr(Max), because some doses are guaranteed to have probability zero of being the best arm. If the control arm is included in the linear model and it has the smallest dose value, then all experimental arms will always have exactly the same probability of being better than control.\nWe recommend creating scenarios where the true parameters deviate from linearity and simulating them to test the robustness of a design based on the linear model.\nFor dichotomous models, the linear model replaces the 2-parameter logistic model available in FACTS versions before 6.4. The two models are identical.\n\n\n7.2.14 Hierarchical Linear Model\nA more flexible version of the linear model is the hierarchical linear model. This model encourages the arm responses to have a linear-like shape, but also includes a term allowing parameters to deviate from linearity when appropriate. The arm parameters satisfy the relationship\nθd = α + *β**νd + ζd*\nwhere the α and β parameters are as in the linear model, with prior distributions\nα ∼ N(Λα, λα2)\nβ ∼ N(Λβ, λβ2),\nand the ζd parameters are the deviations from linearity. These deviations are assumed to have a normal distribution constrained so that their average value is zero:\nζd ∼ N(0, τ2) with ∑ζd = 0.\nThe prior distribution for τ2 is\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nIf τ2 is small, which can be encouraged by choosing τμ to be small and τn to be large, then the dose parameter estimates will lie close to a line.\nThe hierarchical linear model is a good choice when, for example, one expects a linear relationship between the dose strengths and the response but one is not prepared to assume exact linearity. It can also be a good way of encouraging, but not requiring, monotonicity in the response.", + "objectID": "documentation/v71/userguides/crm.html#facts-6.4-changes-to-n-crm", + "href": "documentation/v71/userguides/crm.html#facts-6.4-changes-to-n-crm", + "title": "FACTS Dose Escalation CRM", + "section": "2.4 FACTS 6.4 Changes to N-CRM", + "text": "2.4 FACTS 6.4 Changes to N-CRM\nIn FACTS 6.4 there were no changes to the Dose Escalation simulators.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#d-treatment-dose-response-models", - "href": "documentation/v71/userguides/core.html#d-treatment-dose-response-models", - "title": "FACTS Core User Guide", - "section": "7.3 2D Treatment Dose Response Models", - "text": "7.3 2D Treatment Dose Response Models\nIf on the Study > Treatment Arms tab, the “Use 2D treatment arm model” option has been checked, the user may either use any of the 1D Dose Response options described above, or may use a dose response model specifically modelling the two dosing dimensions.\nIf using one of the 1D dose response models, the effective dose strength νd is as specified by the user on the “Select doses to be used in the trial” tab. These calculated dose levels are forced to be distinct values, and this results in a 1D ordering of the combinations.\nThere are also three 2D Dose Response models that can be used:\n\n2D Continuous Factorial Model\n2D Discrete Factorial model\n2D NDLM\n\nThese are described in the next sections.\nThe 2D dose response models work with a slightly different notation to accommodate that treatments are defined as the combination of two factors. Rather than θi being the estimated mean of the dose response estimate for dose i, the estimated dose response for the treatment created from row factor level r and column factor level c is denoted θrc. Yrc denotes the mean of the observed data in the cell.\nIn the continuous case, the likelihood for the data is,\nYrc ∼ N(θrc, σ2)\n\\[\\sigma^{2}\\\\\\sim\\\\IG\\left( \\frac{\\sigma\\_{n}}{2},\\frac{\\sigma\\_{\\mu}^{2}\\sigma\\_{n}}{2} \\right)\\]\nWhere the form of θ*r**c* varies based on dose response model selection.\nSimilarly, in the dichotomous case,\nYrc ∼ Bernoulli(Prc)\n\\[P\\_{rc} = \\\\\\frac{e^{\\theta\\_{rc}}}{1 + e^{\\theta\\_{rc}}}\\]\n\n7.3.1 2D Continuous Factorial Model\nThe 2D Continuous Factorial Model fits a regression on the dose response that uses the numeric dose strength as a continuous valued covariate. The dose response (with ηr and ζc denoting dose strength of the row level and column level, respectively) is modelled as:\nθ*r**c = α0 + α1ζc + α2ηr + α3ζcηr*\nWith priors\nα0 ∼ N(μ0, σ02)\nα1 ∼ N(μ1, σ12)\nα2 ∼ N(μ2, σ22)\nα3 ∼ N(μ3, σ32)\nThus α0 is the response at the control combination, α1 is the linear coefficient of the response to the column factor strengths ζc, and α2 is the linear coefficient of the response to the row factor strengths ηr.\nThe user has the option to simplify the model and exclude the interaction term α3, which is the coefficient of the product of the two factor strengths.\nNote that despite being called “continuous” this dose response model applies to all endpoints. It’s called continuous because the coefficients act on the dose strengths as continuous measures of strength.\n\n\n\n7.3.2 2D Discrete Factorial Model\nThe 2D Discrete Factorial Model fits a regression on the dose response that uses the dose strength as a factor covariate rather than a numeric dose strength. Each dose is an independent level within each row or column factor, so any dose is equidistant from all other doses\nθ*r**c = α + γr + βc*\nWith priors\nα ∼ N(μα, σα2)\nβc ∼ N(μβc, σβc2)\nγr ∼ N(μγr, σγr2)\nThe parameters associated with lowest level of each factor, γ0 and β0, are constrained to be 0.\n\n\n\n7.3.3 2D NDLM\nThe 2-D NDLM Model takes the idea of smoothing across doses that was used in the standard NDLM model, but smooths across row factors and column factors separately.\n\n7.3.3.1 The Base Model, with Control Included\nThe treatment effect for the combination of level r in the row factor and level c in the column factor is denoted as θrc, and Yrc is the observed data in that cell. The borrowing parameters are denoted as ϕ for the row factor smoothing, and τ for the column factor smoothing. The dose strengths are denoted as vr for the row factors, and ωc for the column factors. Let Δνr = νr − νr − 1 and Δωc = ωc − ωc − 1 (for r > 0 and c > 0). For notational convenience at the grid edge, let θ−1, c = 0, θr, −1 = 0, Δν0 ≡ ∞, and Δω0 ≡ ∞.\nThe 2-D NDLM Model with control included in the model can then be specified as:\nθ0, 0 ∼ N(μ0, τ02)\nθrc ∼ N(μrc, τ*r**c*2)\nwhere\n\\[\\tau\\_{rc}^{2} = \\\\\\left( \\frac{1}{\\mathrm{\\Delta}\\nu\\_{r}\\phi^{2}} + \\frac{1}{\\mathrm{\\Delta}\\omega\\_{c}\\tau^{2}} \\right)^{- 1}\\]\n\\[\\mu\\_{rc} = \\\\\\tau\\_{rc}^{2}\\left( \\frac{\\theta\\_{r - 1,c}}{\\mathrm{\\Delta}\\nu\\_{r}\\phi^{2}} + \\frac{\\theta\\_{r,c - 1}}{\\mathrm{\\Delta}\\omega\\_{c}\\tau^{2}} \\right)\\]\nwith priors\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\n\\[\\phi^{2}\\\\\\sim\\\\IG\\left( \\frac{\\phi\\_{n}}{2},\\frac{\\phi\\_{\\mu}^{2}\\phi\\_{n}}{2} \\right)\\]\nNote: that not all combinations of r and c will have data associated with them. However, FACTS will still evaluate the prior at all combinations. Thus, in the situation depicted below where the grayed-out point indicates a treatment combination with no allocation, θ1, 2 is not modeled conditionally only on θ1, 1; θ0, 1 also informs on θ1, 2 via θ0, 2.\n\n\n\n7.3.3.2 Fix smoothing ratio for row factor and column factor\nOptionally, the user might want to specify the row factor borrowing as a function of the column factor borrowing:\nϕ ≡ k • τ\nwhere k is a user-specified constant. This can be performed by selecting “Fixed smoothing ratio” in the ϕ2 prior specification area.\n\n\n7.3.3.3 Control not in model, no zero-level doses\nIf neither treatment arm allows zero-level doses (e.g. like one would expect if the column factor represented doses and the row factor represented frequency), then a prior for the lowest dose would instead be needed as input from the GUI:\nθ1, 1 ∼ N(μ1, τ12)", + "objectID": "documentation/v71/userguides/crm.html#facts-6.3-changes-to-n-crm", + "href": "documentation/v71/userguides/crm.html#facts-6.3-changes-to-n-crm", + "title": "FACTS Dose Escalation CRM", + "section": "2.5 FACTS 6.3 Changes to N-CRM", + "text": "2.5 FACTS 6.3 Changes to N-CRM\nIn FACTS 6.3 a number of changes were made to improve facilities in N-CRM, or improve the way existing facilities were implemented. These were:\n\nNew run-in options: the existing run-in scheme is available as “simple run-in”, “custom run-in” allows a specific sequence of doses and number of subjects to test at each dose to be specified, “small cohort pre-escalation” allows a run that uses a smaller cohort size but follows the dose escalation rules and over dose control.\nNew “backfill” options in open enrolment. Backfill allows subjects that become available at a time when they can’t be allocated to the current dose (because the maximum number of subjects without final results have already been allocated to the current dose).\nImproved handling of “maximum subjects without final results” in open enrolment. In earlier versions of FACTS this was a “global” maximum, which led to a suboptimal allocation pattern and overly cautious rejection of subjects that became available. The new model applies a maximum “per dose” so that once the trial has escalated to a new dose strength, any subjects without final results on lower doses do not block allocation to the new dose, in addition it is possible to specify two different maximums – one for when a dose has just been escalated to but has not been “cleared” (typically smaller and more cautious), and one when a dose has been cleared but we continue to allocate to it because it is the target dose (typically larger and more confident). This method is such an improvement that we recommend moving any design using open enrolment to this new version of FACTS.\nImproved Ordinal Toxicity model – the way the likelihood is calculated has been improved – reducing the uncertainty in the model fit. Any design using an ordinal model will need to re-calibrate the prior if you move the design to FACTS 6.3. If you have a design already complete, or in execution we recommend you remain using the earlier version of FACTS for that trial.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#baseline-adjusted-model-continuous-only", - "href": "documentation/v71/userguides/core.html#baseline-adjusted-model-continuous-only", - "title": "FACTS Core User Guide", - "section": "7.4 Baseline Adjusted Model (Continuous Only)", - "text": "7.4 Baseline Adjusted Model (Continuous Only)\nIf a baseline endpoint is simulated, the user has the option of adding a linear covariate effect to the dose response model. Thus, if the chosen dose response model states that for dose d,\nE[Yd] = g(d)\nThen the baseline adjusted model will fit a model of the form\nE[Yd|Z] = g(d)+ *β**Z*\nwhere β is a parameter estimated alongside the dose response parameters, and Z is the standardized baseline value (take each baseline value, subtract the observed mean, and divide by the observed standard deviation, for a given dataset this creates a set of fixed known constants). The model uses a normal prior for β for which the user enters a mean and standard deviation.\nNote that the VSR based simulation of baseline is more general than the model description (this is to allow baseline to be incorporated in a number of different ways). This means that the parameters entered in the VSR (for example the β parameter) need not match its estimated value. As a simple example, suppose we enter into the VSR response Y ∼ N(μY, σY), baseline X ∼ N(μX, σX), and use the baseline adjustment so the actual simulated Y is \\(Y^{'} = Y + \\beta\\_{VSR}\\frac{X - c}{s}\\).\nThe baseline adjusted value works for Z (standardized value of X). For a sufficiently large sample, this should be approximately \\(Z = \\\\\\frac{X - \\mu\\_{X}\\\\}{\\sigma\\_{X}}\\) and thus X is approximately *Z**σX + μX*. Thus, the actual simulated response is\n\\[Y^{'} = Y + \\beta\\_{VSR}\\left( \\frac{Z\\sigma\\_{X} + \\mu\\_{X} - c}{s} \\right)\\]\nThe model is fit under the assumption the Z values are fixed constants (identical to any simple linear regression). Thus, for a simple dose response (no model assumed, just fitting a separate mean for each dose\n\\[E\\left\\lbrack Y^{'} \\right\\rbrack = \\mu\\_{Y} + \\beta\\_{VSR}\\left( \\frac{Z\\sigma\\_{X} + \\mu\\_{X} - c}{s} \\right) = \\left\\lbrack \\mu\\_{Y} + \\beta\\_{VSR}\\left( \\frac{\\mu\\_{X} - c}{s} \\right) \\right\\rbrack + \\left\\lbrack \\beta\\_{VSR}\\frac{\\sigma\\_{X}}{s} \\right\\rbrack Z\\]\nThus, the fitted β from the model may not match the β used in the VSR, unless the values are also standardized in the VSR. Note the variances will always be inflated by using a baseline adjustment, so the estimated standard deviation of the responses from the model will tend to be greater than the standard deviation entered in the dose response tab of the VSR.", + "objectID": "documentation/v71/userguides/crm.html#facts-6.2-changes-to-n-crm", + "href": "documentation/v71/userguides/crm.html#facts-6.2-changes-to-n-crm", + "title": "FACTS Dose Escalation CRM", + "section": "2.6 FACTS 6.2 Changes to N-CRM", + "text": "2.6 FACTS 6.2 Changes to N-CRM\nIn FACTS 6.2 features available separately in the other FACTS CRM engines (CRM (Toxicity), bCRM & CRM Ordinal) were all incorporated into N-CRM. This allowed these features to be used in conjunction with N-CRM’s target toxicity band methodology, overdose control and open enrollment features, as well as in conjunction with each other for the first time.\nThe new features are:\n\nFrom CRM (Toxicity) the option to specify that the data is coming from ‘two groups’ and for the toxicity experienced in the two groups to be modelled with a joint model [CRM 2 Sample]. This allows a trial where there are two patient populations (such as adults and children) or where there are two versions of the treatment to be simulated.\nFrom bCRM the option to model a second binary efficacy endpoint [bCRM] and the for dose allocation to proceed in two stages – the first to establish an MTD and the second to establish an MED.\nFrom CRM Ordinal the option for the toxicity endpoint to be modelled not as binary endpoint, but one with different categories of toxicity, and with a joint model applied to the different categories [CRM Ordinal]. The endpoint can be to model either 3 or 4 categories of toxicity:\n\ncategory 1 is “no toxicity”,\ncategory 2 is “mild toxicity”,\ncategory 3 is “toxicity”\ncategory 4 (if included) is “severe toxicity”\n\n\nAll decision making is made in terms of the probability of observing a category 3 (or worse) toxicity.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#control-and-comparator-priors", - "href": "documentation/v71/userguides/core.html#control-and-comparator-priors", - "title": "FACTS Core User Guide", - "section": "7.5 Control and Comparator Priors", - "text": "7.5 Control and Comparator Priors\nThe control arm may be modelled as part of the dose response model or separately. If it is modelled separately, it may have a simple user specified Normal prior or a “historical” prior. A historical prior in FACTS is a hierarchical prior that models the response on control as coming from a distribution that also contains some historical response rates.\n\nThe active comparator is always modelled separately, and as with a control arm modelled separately, it can be modelled with a user specified Normal prior or a “historical” prior.\nWhen a user specified Normal prior is used the user specifies the mean and standard deviation of the prior normal distribution for θ0. This is useful if the control response is not thought to be consistent with the model being used to model the study doses – for instance if using an NDLM and there might be a sharp step in response from control to the lowest dose.\nIf “historical” prior is selected for either the control arm or an Active Comparator arm, an “Augmented Priors” tab is created.", + "objectID": "documentation/v71/userguides/crm.html#facts-6.1-changes-to-n-crm", + "href": "documentation/v71/userguides/crm.html#facts-6.1-changes-to-n-crm", + "title": "FACTS Dose Escalation CRM", + "section": "2.7 FACTS 6.1 Changes to N-CRM", + "text": "2.7 FACTS 6.1 Changes to N-CRM\nIn FACTS 6.1 N-CRM has the new feature of ‘design variants’ that allow the user to easily simulate and evaluate an N-CRM design at different sample sizes. This change includes 4 elements:\n\nUnder the ‘Study’ tab the user can now specify the number of design variants, and for each variant the maximum study size in Cohorts.\nOn the simulation tab FACTS will display a copy of each simulation scenario for each variant.\nThe simulation results now include the Ppn of trials that stopped for each stopping reason: stopping because all doses are too toxic (the toxicity estimates exceed the overdose criteria), because a stopping rule was met or because the study cap was reached.\nThere are now a set of cross variant graphs that show trellis plots of the key summary graphs by design variant and scenario.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#inverse-gamma-priors", - "href": "documentation/v71/userguides/core.html#inverse-gamma-priors", - "title": "FACTS Core User Guide", - "section": "7.6 Inverse-gamma priors", - "text": "7.6 Inverse-gamma priors\nFACTS uses inverse-gamma priors for parameters of variance – these are conjugate and allow efficient computation and avoid problems of convergence. Andrew Gelman’s 2006 paper[7] however notes a potential problem with this model, the problem is specifically\n\nWhen updating the estimate of the variance of a hierarchical model parameter there will be typically relative few actual data observations (e.g. relatively few historic studies for estimating the variance of the hyper parameter in a BAC (Bayesian Augmented Control) model for the response on a control arm, and relatively few observations of the change in response from one dose to the next when using an NDLM dose-response model).\nThe conventional ‘non-informative’ gamma-prior of IG(0.001, 0.001) has an effect when the observed variance is small, of over-shrinking the posterior estimate of variance.\n\nIn FACTS this possibility arises in the dose response models in the context of priors for ‘tau’ τ parameter for the NDLM models and α4 parameter for the hierarchical logistic dose response model, where the number of observations is the number of doses or dose intervals. [It also arises in the context of Bayesian Augmented Control and the hierarchical modeling or responses in different groups in ED].\nTo avoid the problem reported by Gelman we recommend using a weakly informative prior. Using the settings that control how the inverse-gamma distribution is parameterized (Settings > Options > Gamma Distribution Parameters), use the ‘mean and weight’ options and use a weight of 1, with a ‘reasonable’ expectation for the upper limit difference in the values being modeled entered as the prior mean for the SD. Strictly the distribution is the prior of the variance, so the parameter being specified is more correctly the prior mean of the square root of the mean of the variance.\nThis ‘reasonable’ upper limit for the difference is a value that a clinical team will usually have an intuition about: for the largest change in mean response from one dose to another for instance, it is often[8] reasonable to assume that the upper limit for the expected change in response from one dose to the next is the ‘expected difference in effect size’ that might have been used to power the trial in a conventional setting.\nIn this setting we are typically less concerned with the final estimate of the parameters of the hierarchical model and more concerned with the estimates of the values in the model (the dose –response) and thus less concerned to have a non-informative prior for it. The purpose of the trial is usually to estimate the dose response, and the hierarchical models are a means to an end, not an end in themselves.", + "objectID": "documentation/v71/userguides/crm.html#overdose-control", + "href": "documentation/v71/userguides/crm.html#overdose-control", + "title": "FACTS Dose Escalation CRM", + "section": "3.1 Overdose Control", + "text": "3.1 Overdose Control\nOverdose control can be specified on the Study > Toxicity tab. Overdose control specifies a limit on the probability that a dose has a toxicity rate above a certain level. After fitting the Bayesian logistic regression model, all doses for which the posterior probability that their toxicity rate lies above the specified level exceeds the specified limit are ineligible for allocation. Because the Bayesian Logistic regression is monotonic, this means that after every analysis either all doses are permitted for allocation or there will be a dose level above which no dose is permitted for allocation.\n\n\n\n\n\n\nFigure 1: Setting the overdose control limit\n\n\n\nThe overdose control is specified in terms of the “toxicity bands” (concept of allowing ranges for the target toxicity, excess toxicity, unacceptable toxicity and under-dosing explained in more detail in this section) and can either be in terms of the “excess and unacceptable toxicity bands” or just the “unacceptable toxicity band”. The “excess and unacceptable toxicity band” is every toxicity rate above the upper bound of the target band. Care should be taken when setting the permitted threshold for this joint band. If set below 0.5, it will likely exclude doses whose mean expected toxicity rate is within the target band with the risk that this makes the escalation decision in the design too cautious. Initially it might be recommended to just use the “unacceptable band” for specifying the overdose control. This allows an overdose control that is more strict – for example: “exclude any dose where the probability that the toxicity rate is above 0.6, is greater than 20%“. The lower bound for the unacceptable band can be set wherever desired, its only role is in defining this band for overdose control. It is also possible to specify that the limit changes over the course of the trial, allowing the overdose control to become stricter as more information becomes available. For example, one could reduce the permitted probability of a dose having a toxicity rate in the unacceptable band from 50% to 25% in steps of 2.5% after every cohort.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#handling-missing-data", - "href": "documentation/v71/userguides/core.html#handling-missing-data", - "title": "FACTS Core User Guide", - "section": "7.7 Handling Missing Data", - "text": "7.7 Handling Missing Data\nFACTS allows a “preprocessing” step to occur in handling missing data due to dropouts. If a subject has incomplete data due to a dropout, the user may specify all dropouts have their unknown final endpoint treated as known with the following options\n\nBOCF (continuous only, requires baseline be simulated) – All dropouts are assumed to have a final endpoint equal to their observed baseline value.\nLOCF (continuous or dichotomous, requires longitudinal data be present) – All dropouts are assumed to have a final endpoint equal to their last observed visit value. If no post-baseline visits are available, but the subject has a baseline visit value, then the baseline values is carried forward to their final endpoint.\nMissing is failure (dichotomous only) – All dropouts are assumed to be failures (which may be coded as 0 or 1 depending on whether a response is considered a success).\n\nSubjects who are imputed in this preprocessing step have final endpoint values known and used for the purposes of estimating the dose response curve. However, these preprocessed final endpoint values are not used in the updating on the longitudinal model, which is based only on observed visit data.\nIf the user does not specify one of the dropout imputation methods specified above, the dropout subjects and incomplete subjects (subjects who have not reached their final endpoint but are still continuing in the study) will have their final endpoints multiply imputed using Bayesian Multiple Imputation, described in the longitudinal modeling section.\nGenerally, patients with “no data” do not affect the posterior distribution, and thus are omitted from the analysis. However, one must take into account a subject can have no visit data but still have “data” based on these dropout imputation methods. For example, if one selects “missing as failure” and a patient drops out before any visit data is recorded, then the subject still supplies information through the dropout imputation (similarly for BOCF). However, if LOCF is selected and no visit data is available, there remains no information on the subject to be used for the LOCF dropout imputation, and thus these subjects are omitted from the analysis as well. Thus, all subjects are included which either 1) have some visit data available, or 2) are dropouts before visit 1 with sufficient information to impute their final endpoint with this preprocessing step.\n\n7.7.1 Time-to-Event Missingness\nFor a time-to-event endpoint, as is the convention in this endpoint, subjects are observed up to the time they have an event (or the end of follow up), so no subject drops out after having had an event; subjects that do drop-out are included in the analysis as not having had an event up to the last observation of the subject.", + "objectID": "documentation/v71/userguides/crm.html#dose-escalation-rules", + "href": "documentation/v71/userguides/crm.html#dose-escalation-rules", + "title": "FACTS Dose Escalation CRM", + "section": "3.2 Dose Escalation Rules", + "text": "3.2 Dose Escalation Rules\nThe dose escalation could be solely controlled by the overdose control (as originally proposed in (Neuenschwander, Branson, and Gsponer 2008)), however this means that the escalation behavior is very dependent on the interplay between the prior and the observed data. Usually, teams prefer to have a fixed set of rules in place ensuring the escalation behavior is sufficiently cautious. FACTS has an option to just use overdose control or to use a combination of overdose control and a set of fixed escalation rules. In the latter case, the following rules can be set in the Design > Allocation Rule > Allocation tab:\n\n\n\n\n\n\nFigure 2: Dose escalation rules\n\n\n\nWe introduce the notion of whether a dose has been “cleared”. A dose is cleared once we have sufficient data on it (usually, but not necessarily, the results of one cohort, but if the cohort size is small, for example 2 subjects, perhaps more than one cohort will be required). This can be supplemented by a rule that if the observed raw toxicity rate at the dose exceeds a certain limit, then the dose is not counted as cleared (this rule is usually unnecessary if overdose control limits have been set). Once a dose has been cleared, it stays cleared, meaning there is “maximum cleared dose”. The number of dose increments or the factor of dose strength above the current cleared dose that can be allocated to is then specified. For example, with doses of 12.5, 25, 50, 100, 150, 200, 250, we might allow escalation at two dose increments a time. In the figure below, you see the combination of settings used to achieve this behaviour alongside the “Fastest Possible Dose Escalation” plot on the right:\n\n\n\n\n\n\nFigure 3: Escalation by number of dose increments\n\n\n\nAlternatively, we can specify the permitted escalation as a ratio, for example we might allow the dose strength to be at most tripled at each escalation, which, with the example dose strengths, makes the initial escalation more cautious:\n\n\n\n\n\n\nFigure 4: Escalation by dose strength factor\n\n\n\nThe escalation rules can be adjusted so that instead of a single increment rule, there are different increments depending on the dose, or depending on the number of observed toxicities. To modify our earlier example, we can allow escalation by 2 dose levels while no toxicities have been observed, but limit it to only one dose level once one or more toxicities have been observed:\n\n\n\n\n\n\nFigure 5: Escalation increment varying by number of toxicities\n\n\n\nLastly escalation can be relative to the highest cleared dose, or relative to the last dose allocated.\nTo summarize the allocation procedure:\n\nThe current maximum cleared dose is identified.\nThe current data is analyzed using the Bayesian Logistic Regression model.\nThe overdose rules are evaluated and all doses exceeding the overdose control limit are excluded from this escalation selection.\nFrom the remaining doses, the dose best meeting the target MTD or target toxicity interval objective based on the model is selected as the “target dose” (TD).\nIf the TD is at or below the current maximum cleared dose, the next cohort is allocated to the TD.\nIf the TD is within the escalation rules of the current maximum cleared dose, the next cohort is allocated to the TD.\nOtherwise, the next cohort is allocated to the highest dose above the current maximum cleared dose as allowed by the escalation rules.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#bayesian-baseline-adjusted-model", - "href": "documentation/v71/userguides/core.html#bayesian-baseline-adjusted-model", - "title": "FACTS Core User Guide", - "section": "7.8 Bayesian Baseline Adjusted Model", - "text": "7.8 Bayesian Baseline Adjusted Model\nFor a continuous endpoint, if Baseline has been included in the simulation, it is possible to include modeling a linear covariate effect to the dose response model. The model for response changes from:\nY ∼ N(θd, σ2)\nto:\nY ∼ N(θd + *β**Z, σ*2)\nwhere β is the estimated parameter and Z is the standardized baseline value.\n\\[Z = \\frac{\\left( X - \\overline{X} \\right)}{s\\_{x}}\\]\nNote that the estimate of β will only correspond to the β used on the VSR tab to simulate the baseline adjustment if the centering and scaling values are the mean and the standard deviation of the baseline values.", + "objectID": "documentation/v71/userguides/crm.html#initial-run-in", + "href": "documentation/v71/userguides/crm.html#initial-run-in", + "title": "FACTS Dose Escalation CRM", + "section": "3.3 Initial Run-in", + "text": "3.3 Initial Run-in\nThe purpose of defining a run-in is to define a fixed allocation behavior to be followed up to the first toxicity being observed. The specified number of subjects to allocate to each dose in the run-in and which doses to test are specified. This scheme is followed until a toxicity is observed or we reach the end of this fixed scheme.\nThree forms of run-in specification are available:\n\nSimple: allocates a small cohort to every defined dose in ascending order (unless fine grain doses - see this section – have been specified, in which case the escalation rules are followed).\nCustom: allocates a defined number of subjects (possibly varying by dose) to selected doses in ascending order.\nSmall cohort pre-escalation: allocates a small cohort, but follows the escalation rules assuming just a single small cohort is required to clear a dose.\n\nAll run-in schemes can be modified in a number of ways:\n\nSpecifying a maximum dose at which the run-in stops if no toxicities are observed until that dose.\nIf ordinal toxicities are being simulated, the run-in may should at the first observed category 2 toxicity (rather than a category 3 toxicity)\nWhether the subjects used in the run-in should be counted towards the trial sample size or not.\nWhen a toxicity is observed the standard behavior is to allocate to the minimum of: the last dose tested in the run-in, the current TD or the highest dose that can be allocated to by the overdose rules. This can be replaced by expanding the allocation on the current dose to make it a full cohort as specified in Study > Study Info tab (this option is particularly useful in conjunction with stopping for a category 2 toxicity).", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#continuous-endpoints", - "href": "documentation/v71/userguides/core.html#continuous-endpoints", - "title": "FACTS Core User Guide", - "section": "8.1 Continuous Endpoints", - "text": "8.1 Continuous Endpoints\nThe model used for incorporating data from previous trials is as follows:\nθ0t ∼ N(μ0, τ02) for t = 0, 1, 2, …, T\nwhere θ0t is the mean for the control arm in trial t (t = 0 for the current trial; t = 1, 2, …, T for previous trials). User needs to specify appropriate priors for the hyper-parameters:\nμ0 ∼ N(m0, σ02)\nτ02 ∼ *I**G(a0, b*0)", + "objectID": "documentation/v71/userguides/crm.html#two-groups", + "href": "documentation/v71/userguides/crm.html#two-groups", + "title": "FACTS Dose Escalation CRM", + "section": "3.4 Two Groups", + "text": "3.4 Two Groups\nFACTS has the option to model the subjects in the trial as belonging to two different groups, these can be either:\n\nTwo groups distinguished by a baseline property of the subjects, for example adults and paediatrics.\nTwo groups separated by a difference in treatment (and selected randomly), for example the study drug alone or in combination with an additional drug.\n\nThere are options for when group 2 starts enrolling:\n\nThey can be recruited sequentially – group 1 then group 2.\nThey can be recruited in parallel\nThe second group can be started when the allocation to the first group reaches a particular dose\nThe second group can be started when the number of subjects allocated to group 1 reaches a particular threshold.\n\nA joint model is fitted to the two groups.\nThe first group is modeled:\n\\[\nlogit(p_{1j}) = \\alpha + \\beta \\hat{x}_j\n\\]\nThe second group is modeled:\n\\[\nlogit(p_{2j}) = (\\alpha + a) + (\\beta + b) \\hat{x}_j\n\\] With separate priors and some optional constraints on \\(a\\) and \\(b\\). Dose escalation and stopping are judged independently for the two groups.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#dichotomous-endpoints", - "href": "documentation/v71/userguides/core.html#dichotomous-endpoints", - "title": "FACTS Core User Guide", - "section": "8.2 Dichotomous Endpoints", - "text": "8.2 Dichotomous Endpoints\nThe model used for incorporating data from previous trials is as follows:\nθ0t ∼ N(μ0, τ02) for t = 0, 1, 2, …, T\nwhere θ0t is the log-odds for the control arm in trial t (t = 0 for the current trial; t = 1, 2, …, T for previous trials). User needs to specify appropriate priors for the hyper-parameters:\nμ0 ∼ N(m0, σ02)\nτ02 ∼ *I**G(a0, b*0)\nThe prior distributions for the hyper-parameters of the hierarchical model. The hyper-parameters are the mean and standard deviation of Normal distribution for the log hazard ratios of the event rates of the historical studies and the current study.", + "objectID": "documentation/v71/userguides/crm.html#sec-concepts-efficacy", + "href": "documentation/v71/userguides/crm.html#sec-concepts-efficacy", + "title": "FACTS Dose Escalation CRM", + "section": "3.5 Efficacy", + "text": "3.5 Efficacy\nFACTS has the option to additionally model an efficacy endpoint. There are currently two limitations in simulation:\n\nOnly a binary efficacy endpoint can be simulated\nThe efficacy endpoint is assumed to be available at the same time as the toxicity endpoint.\n\nThe efficacy and toxicity endpoints are modelled separately. There are options to specify early stopping rules for finding the MTD, and to specify a cap on the sample size that can be spent finding the MTD. Once these rules are met, then allocation is towards the Minimum Efficacious Dose (MED) – if this is below the MTD. If the estimated MED lies at or above the estimated MTD, the allocation is at the estimated MTD.\nIf while allocating to the estimated MED further toxicity results change the estimate of the MTD, and if there is now insufficient information on the MTD as specified by the early stopping rules for finding the MTD, allocation switches back to allocating to the estimated MTD, if the sample size cap for finding the MTD allows.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#time-to-event-endpoints", - "href": "documentation/v71/userguides/core.html#time-to-event-endpoints", - "title": "FACTS Core User Guide", - "section": "8.3 Time-to-Event Endpoints", - "text": "8.3 Time-to-Event Endpoints\nThe model used for incorporating data from previous trials is as follows:\nλ*s**t= λsexp (γt) for t = 0, 1, 2, …, T*\nwhere λ*s**t is the hazard rate for the control arm in segment s* (s = 1, 2, …, S) for previous trial t (t = 1, 2, …, T) and λs0 is the hazard rate for the current control arm in segment s; λs is a base hazard for segment s; and γt is the log hazard ratio between that base rate and the λ*s**t* values.\nThe following hierarchical model is used\nγt ∼ N(μγ, τγ2) for t = 0, 1, 2, …, T\nUsers specify priors for the hyper-parameters:\nμγ ∼ N(mγ, tγ2)\nand\nτ2 ∼ *I**G(aγ, bγ*)\nThe formulation above is not identifiable as changes in λs can be compensated for by changes in the γt values (thus, one can use different combination of λs and γt but acquire the same set of values λ*s**t and thus the same likelihood. To avoid this difficulty, we use the above formulation but fix γ0 = 0. In addition to preserving the identifiability of the structure, this constraint allows λs to have the interpretation of being the hazard rate for the current control arm, and thus the prior on λs from the main dose response may be used as the prior for λs*.", + "objectID": "documentation/v71/userguides/crm.html#sec-concepts-fgd", + "href": "documentation/v71/userguides/crm.html#sec-concepts-fgd", + "title": "FACTS Dose Escalation CRM", + "section": "3.6 Fine Grain Dosing", + "text": "3.6 Fine Grain Dosing\nIn some settings, e.g. when the drug is delivered in solution by IV or when manufacturing allows any dose in a range from say 100mg to 400mg in steps of 10mg, dose strengths need not be restricted to just a small number of pre-defined levels. FACTS has a feature that allows this to be simulated, not with a continuous range of doses, but with “fine grain” dosing.\nFACTS supports the specification of a range of doses from a minimum to a maximum with doses either equally spaced or spaced with equal ratio. Using dose ratio makes most sense it you want to use the dose strength whilst believing the effect will be roughly log-dose. Using dose ratios, it’s necessary to accept FACTS reporting dose strengths only close to those desired. As an example, if the main doses followed a dose doubling scheme: 12.5, 25, 50, etc., one might use fine grain dosing with dose space ratios of approximately the 4th root of 2 (1.1892). The resulting doses are 12.5, 14.865, 17.677, 21.022, 24.999, 29.729, 35.354, 42.043, 49.998, etc., which means there are three dose levels between each of the original doses.\nThere are two alternatives:\n\nUse nominal dose strengths 1, 2, 3, 4, … (i.e. assuming the dose spacing is linear in expected effect) and label the doses according to their actual strength.\nUse a fixed dose interval (e.g. 12.5 resulting in doses of 12.5, 25, 37.5, 50, 62.5, etc.) so the lower doses (of the original scheme) have fewer (or no) intermediate doses and the higher doses have many more. The dose escalation rules can be specified in terms of dose strength ratio to achieve the required escalation, for example allowing dose escalation with a dose strength ratio of 2 will result in the initial escalation using doses 12.5, 25, 50, 100, etc.\n\nAs well as possibly adjusting the dose escalation step size to accommodate the new dose levels on the Design > Allocation Rule tab, there are two other rules that may need modification:\n\nTo count a dose as “cleared”, we might now count cohorts on nearby doses to count towards the required clearing total. This is specified as the “Max ratio of dose strengths considered as near” (if dose allocation rules apply to ratio of dose strength) or “Delta in dose strength considered as near” (if dose allocation rules apply to dose strength) on the Design > Allocation Rule tab.\n\nFor example, if we have doses at roughly 4th root of 2 intervals, we might count any dose within a ratio of 1.2 as “near” so that any cohorts allocated to immediate neighbor doses count towards clearing a dose.\nAlternatively, if we have doses every 12.5mg from 12.5 to 400, counting any dose within a ratio of 1.1 will mean that from dose 125 and above, immediate neighbor doses (within 12.5) count towards clearing a dose, and from dose 250 and above, doses within 25mg (two immediate neighbor doses) count towards clearing a dose.\n\nThe concept of “near doses” in fine grained dosing allows us to skip certain doses in the escalation phase, which might make sense if there is reason to believe that doses of similar dose strengths behave similarly and don’t provide enough additional information to justify assigning more cohorts to.\n\n\n\n\n\n\nFigure 6: Doses from 12.5 to 400mg, with fixed spacing of 12.5. Showing dose escalation by dose doubling.\n\n\n\nWhen requiring a certain number of cohorts to have been allocated to the estimated MTD before the trial can stop / to allow the trial to stop, we might now count cohorts on doses near the estimated MTD as counting towards that total. This is set on the Design > Stopping Criteria tab. In considering which doses are near, the same logic as on the Design > Allocation Rule tab regarding Dose Strength or Ratio of Dose Strength will be used.\n\nIf Dose Strength is used, then on the Design > Stopping Criteria tab, we can include cohorts on nearby doses to count towards the required number of cohorts on the estimated MTD by specifying “nearby” in terms of dose strength. For example, by +/- 12.5 mg:\n\n\n\n\n\n\nFigure 7\n\n\n\nIf ratio of Dose Strength is used then on the Design > Stopping Criteria tab, we can include cohorts on nearby doses to count towards the required number of cohorts on the estimated MTD by specifying “nearby” in terms of dose strength ratio. For example, by +/- 10%:\n\n\n\n\n\n\nFigure 8\n\n\n\n\n\nNote that with Fine Grain dosing, if a band is specified for a dose to count as cleared, then the maximum cleared dose will be the maximum dose within that band, and if incrementing relative to the Maximum cleared dose, then the maximum permitted increment will be relative to the maximum dose within the cleared band.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#setting-priors-for-hierarchical-model-hyper-parameters", - "href": "documentation/v71/userguides/core.html#setting-priors-for-hierarchical-model-hyper-parameters", - "title": "FACTS Core User Guide", - "section": "8.4 Setting Priors for Hierarchical Model Hyper Parameters", - "text": "8.4 Setting Priors for Hierarchical Model Hyper Parameters\n\n\n\nFigure 8‑2 Execution > Accrual tab, with deterministic accrual\n\n\n\n\n\n\n\n\n\nUnless the intent is to add information that is not included in the historic studies, the hyper parameters can and should be set so that they are ‘weak’ priors, centered on the expected values.\n\n\nIn this case the following would be reasonable:\n\n\n\n\nSet the prior mean value for Mu as the mean of the mean responses on the control arm in the historic studies\n\n\n\n\nSet the prior SD for Mu equal to the average SD of response divided by the square root of the number of studies.\n\n\n\n\nSet the mean for tau to the same value as the prior SD for Mu.\n\n\n\n\nSet the weight for tau to be < 1.\n\n\n\n\nOne can traverse the spectrum from ‘complete pooling of data’ to ‘completely separate analyses’ through the prior for tau. If the weight of the prior for tau is small (relative to the number of studies), then (unless set to a very extreme value) the mean of the prior for tau will have little impact and the degree of borrowing will depend on the observed data.\n\n\nTo give some prior preference towards pooling or separate analysis the weight for tau has to be large (relative to the number of historic studies) – to have a design that is like pooling all the historic studies the mean for tau needs to be small (say 10% or less of the value suggested above). For there to be no borrowing from the historic studies the value for tau needs to be large (say 10x or more the value suggested above).\n\n\nThe best way to understand the impact of the priors is try different values and run simulations.\n\n\n\n\n\n\n\nFigure 8‑2 Execution > Accrual tab, with deterministic accrual", + "objectID": "documentation/v71/userguides/crm.html#sec-concepts-oe", + "href": "documentation/v71/userguides/crm.html#sec-concepts-oe", + "title": "FACTS Dose Escalation CRM", + "section": "3.7 Open Enrollment", + "text": "3.7 Open Enrollment\nOpen enrollment (Broglio et al. 2015) can be used instead of cohort enrollment. Cohort enrolment enrolls a fixed number of subjects to a given dose, then waits until their treatment and follow up is complete (so their final status – whether they suffered a DLT (Dose Limiting Toxicity) or not – is known) before deciding on the next dose to allocate to and then recruiting the next cohort. This likely means that subjects become available for inclusion in the trial, but have to be turned away as the trial waits for the current cohort to complete. Open enrollment attempts to address this by allowing subjects to be enrolled whilst the current “cohort” is completing. However, this may come with some risk – more than a cohort’s worth of subjects may now be exposed to a new dose before we have any estimate of its DLT rate. To allow this risk to be managed, open enrollment introduces two new concepts:\n\nWhen allocating to an uncleared dose, a cap can be set on the number of subjects that can be allocated to that dose who have not yet got their final results (“OE cap 1”). For example, if this number is set to 3 (to be the same as a common cohort size), after 3 subjects have been recruited and allocated to the current dose, no more subjects will be allocated to this dose until at least one of these subjects has completed. Until then, potential subjects that become available will be turned away unless backfilling is enabled (see next point below). But unlike cohort enrolment, as soon as the first of the subjects on the dose completes, a subject that comes available could now be allocated to the dose, depending on further rules explained below (frontfilling) – unless of course that subject’s result has changed the estimated MTD. Note that the trial won’t escalate beyond the current dose until the required number of subjects to clear the dose have completed. By default, the trial won’t allocate more than the number of subjects required to clear the dose until the dose is cleared, meaning if 3 subjects are required to clear a dose and 3 subjects have been allocated to this dose, even when 1 or 2 of these subjects have their final results and a new subjects is enrolled, they won’t be allocated to this dose. If this is regarded as over cautious, it can be modified by enabling frontfilling, allowing 3 subjects without final results simultaneously. In the above example, this would mean we could place a fourth subject on the dose when the result of the first subject has come in and a fifth subject as soon as the result of the second subject has come in.\nWhen the cap on the number of subjects without final results on an uncleared dose has been reached (“OE cap 1”) new potential subjects will be turned away, unless backfilling is enabled. Enabling backfilling allows these subjects to instead be included, allocating them to a lower dose that has already been cleared. Whilst such an allocation may not contribute as much to identifying the MTD as allocating to the current dose would, it can still contribute by:\n\nIncreasing the information on the next lower dose can inform the estimate of toxicity on the current dose through the Bayesian logistic model.\nProviding additional information on a dose that it may be necessary to de-escalate too if the current dose turns out to be too toxic.\n\nIt can also contribute information on other endpoints (such as efficacy). Once backfilling has been enabled, it is also possible to enable frontfilling. For more information on backfilling and frontfilling, see this section.\n\nAssume at a given point in time we want to allocate a subject to a specific dose, denoted by “candidate dose”. FACTS allows 3 different caps to be specified on how many subjects who have not yet got their final results (i.e. are not yet complete) can be allocated to this candidate dose:\n\n\n\n\n\n\nFigure 9\n\n\n\n\nMaximum subjects without final results if dose is uncleared: As described early in this section, we encounter this cap during escalation when the candidate dose is not yet cleared. This cap takes into account subjects not yet complete on the candidate dose and any higher dose (“OE cap 1”).\nMax subjects without final results if dose is cleared and below MTD: We encounter this cap when the candidate dose is cleared and below the estimated MTD (which can happen if the estimated MTD is beyond the range of available doses, when backfilling, or when allocating during the efficacy phase of a toxicity plus efficacy trial). This cap takes into account subject not yet complete on the candidate dose and any lower doses (“OE cap 2”).\nMax subjects without final results if dose is cleared and at MTD: We encounter this cap when the candidate dose is cleared and the current model estimated MTD (which can happen when after clearing a dose we decide not to escalate, or after de-escalating) (“OE cap 3”).", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#bac-example", - "href": "documentation/v71/userguides/core.html#bac-example", - "title": "FACTS Core User Guide", - "section": "8.5 BAC Example:", - "text": "8.5 BAC Example:\nIt is easiest to study the impact of BAC in a simplified version of the trial being designed, for example use a 2 arm fixed design with ‘no model’, no adaptation, no longitudinal modeling, etc.\nFor instance in a continuous setting with an expected sample size of 50 on control, a mean response of 5 and an SD in the response of 2, looking at the effect of having 4 prior, similarly sized studies:\n\n\n\nFigure 8‑4 Deterministic accrual tab\n\n\n\n\n\n\n\n\n\n\n\n\n\nNumber of subjects\n\n\nMean Response\n\n\nSD of Response\n\n\n\n\n\n\nStudy 1\n\n\n50\n\n\n4.76\n\n\n2\n\n\n\n\nStudy 2\n\n\n50\n\n\n4.93\n\n\n2\n\n\n\n\nStudy 3\n\n\n50\n\n\n5.07\n\n\n2\n\n\n\n\nStudy 4\n\n\n50\n\n\n5.24\n\n\n2\n\n\n\n\nFigure 8‑4 Deterministic accrual tab\nFor simplicity we have just varied the means of the studies – they are all consistent with a normally distributed estimate, with mean of 5 and a standard error of \\(\\frac{2}{\\sqrt{50}}\\).\nBy simulating a fixed trial with a sample size of 100 and fixed 1:1 allocation between control and a study arm we can easily observe the effects of a BAC on the control arm. Creating 6 VSR profiles with sigma = 2, and the same mean response for control and the study arm in each profile of: 4.53, 4.76, 5.07, 5.24 and 5.47 we can look at the bias of the final estimate and the shrinkage in the SD of the estimate that could be brought about by using BAC:\n\n\n\nFigure 3‑1 Quantities of Interest tab\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nTrue Mean\n\n\nRaw mean\n\n\nRaw SD\n\n\nEstimate inc BAC\n\n\nSD inc BAC\n\n\nBias\n\n\nEffective additional Subjects\n\n\n\n\n\n\n4.53\n\n\n4.55\n\n\n0.28\n\n\n4.64\n\n\n0.255\n\n\n2.1%\n\n\n11.1\n\n\n\n\n4.76\n\n\n4.78\n\n\n0.28\n\n\n4.83\n\n\n0.250\n\n\n1.0%\n\n\n13.5\n\n\n\n\n4.93\n\n\n4.95\n\n\n0.28\n\n\n4.96\n\n\n0.248\n\n\n0.2%\n\n\n14.3\n\n\n\n\n5.07\n\n\n5.09\n\n\n0.28\n\n\n5.07\n\n\n0.248\n\n\n-0.4%\n\n\n14.2\n\n\n\n\n5.24\n\n\n5.26\n\n\n0.28\n\n\n5.20\n\n\n0.250\n\n\n-1.1%\n\n\n13.2\n\n\n\n\n5.46\n\n\n5.49\n\n\n0.28\n\n\n5.38\n\n\n0.255\n\n\n-1.9%\n\n\n10.7\n\n\n\n\nFigure 3‑1 Quantities of Interest tab\nNote it is important to use the column “SD Mean resp 1” from the simulations file to see the SD of the estimate and not use the SD of the estimates in the summary table.\nThe small shrinkage in the SD is more impressive when viewed in terms of how many additional subjects would have to be recruited to achieve the same shrinkage in the raw estimate. These are useful savings for small additional bias.\nThe “effective additional subjects” was calculated:\n\\(\\left( \\frac{True\\\\sigma}{AVG(SD\\\\Mean\\\\resp)} \\right)^{2} - \\left( \\frac{True\\\\sigma}{AVG(SE\\\\Mean\\\\Raw\\\\Response)} \\right)^{2}\\)where in this example True Sigma was 2.", + "objectID": "documentation/v71/userguides/crm.html#sec-concepts-bf", + "href": "documentation/v71/userguides/crm.html#sec-concepts-bf", + "title": "FACTS Dose Escalation CRM", + "section": "3.8 Backfilling and Frontfilling", + "text": "3.8 Backfilling and Frontfilling\nAs described in the preceding section, Backfilling is the allocation of subjects to a lower dose when, due to restrictions, it is not possible to allocate a subject who comes available to the current dose (Dehbi, O’Quigley, and Iasonos 2021). FACTS provides a number of options to configure how backfilling behaves. Backfilling can be enabled in the Study > Study Info tab. The total sample size can be divided between the subjects allocated as part of conventional dose escalation and those allocated using backfill. When backfill is enabled, it is important to increase the total sample size and then limit the number that can be allocated using backfill, as subjects allocated using backfilling will not contribute to the escalation and the confirmation of the MTD and it’s usually important to retain sufficient sample size to achieve this aim.\n\n\n\n\n\n\nFigure 10\n\n\n\nWhen enabling backfilling, several options can be specified in the Design > Backfill Allocation tab.\n\n\n\n\n\n\nFigure 11\n\n\n\n\nTwo maximum caps can be specified on the number of subjects that are assigned in the process of backfilling to a given dose:\n\nan overall cap on subjects per dose that cannot be exceeded by backfill, counting also subjects that were assigned to that dose through regular allocation\na cap on the number of subjects per dose that were allocated by backfill, counting only subjects that were assigned to that dose using backfilling.\n\nHow many dose levels below the current dose can be allocated to when backfilling. Backfilling will always be to the highest dose possible (which might be the current dose if frontfilling is enabled, otherwise it will be below the current dose). Allocation to the next highest dose might be limited either by an open enrolment cap if there are already subjects allocated to that dose who have not yet completed, or it might be limited by the backfill caps described above. If allocation to the dose below the current dose is not possible, backfilling will by default look at the dose below that (two levels below the current dose) and so on. Using this option can ensure no backfilling happens to doses that are too far below the current dose.\nThe lowest dose that can be allocated to when backfilling. This option is particularly useful when there is reason to believe doses below a certain level will not be effective.\nWhether frontfilling is allowed – frontfilling allows allocating more subjects to uncleared doses than the number required to clear that dose (see this section).", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#continuous-endpoints-1", - "href": "documentation/v71/userguides/core.html#continuous-endpoints-1", - "title": "FACTS Core User Guide", - "section": "9.1 Continuous Endpoints", - "text": "9.1 Continuous Endpoints\nAt the end of each simulated trial the following frequentist values will be calculated using LOCF for missing data:\n\nUsing unadjusted dose-placebo comparisons based on a two-sample t-test calculate the:\n\ntest statistic,\np-value[9],\nconfidence interval for the mean difference,\nfor each dose its marginal probabilities of significance (the number of times it was significantly separated from placebo independent of whether any other doses were) .\n\nusing Dunnett-adjusted[10] dose-placebo comparisons based on a two-sample t-test calculate the:\n\ntest statistic,\np-value,\nconfidence interval for the mean difference\nfor each dose its marginal probabilities of significance (the number of times it was significantly separated from placebo independent of whether any other doses were) .\n\nUsing the general trend test calculate the t-test statistic and p-value using user supplied contrast coefficients.\n\n(If neither placebo or active comparator are specified, difference from 0 is assessed for each dose arm and Dunnett-adjusted calculations are not carried out.)\nP-values are calculated using a one-sided t-test testing H0: μT < μC against H1: μT ≥ μC, with subscript T referring to the treatment arm and subscript C referring to the control arm (if high values are good; otherwise, the opposite hypotheses are being tested).\nLast observation carried forward (LOCF), baseline observation carried forward (BOCF), and Per-protocol (Ignore) are available as ways to handle missingness in continuous frequentist calculations.", + "objectID": "documentation/v71/userguides/crm.html#open-enrollment-backfilling-and-fine-grain-dosing", + "href": "documentation/v71/userguides/crm.html#open-enrollment-backfilling-and-fine-grain-dosing", + "title": "FACTS Dose Escalation CRM", + "section": "3.9 Open Enrollment, Backfilling and Fine Grain Dosing", + "text": "3.9 Open Enrollment, Backfilling and Fine Grain Dosing\nWhen using open enrolment and fine grain dosing, the interval defined on the Design > Allocation Rule tab “Delta in dose strength considered as near +/-“, or “Max ratio of dose strengths considered as near” is crucial: it is used to define the range of doses where subjects allocated to any of them count towards clearing a dose.\n\nIf dose allocation rules are selected to apply to “Dose strength”, the interval is defined “Delta in dose strength considered as near +/-“. Thus, for example, if this is set to 2, then subjects complete on doses with strength in the range 4-8 will contribute to the dose of strength 6 being cleared. At the same time, clearing the dose of strength 6 will automatically clear the dose of strength 8.\nIf dose allocation rules are selected to apply to “Ratio of strength”, the interval is defined “Max ratio of dose strengths considered as near“. Thus, for example if this is set to 1.5, then subjects complete on doses with strength in the range 4-9 will contribute to the dose of strength 6 being cleared. At the same time, clearing the dose of strength 6 will automatically clear the dose of strength 9. These ranges also apply when assessing “OE cap 1-3”, and how many subjects have been allocated overall, or via backfilling. In backfilling, FACTS checks each dose strength and the doses in its “near” interval range, at (if frontfilling) or below the current dose, until the first dose strength is found where backfilling can take place.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#dichotomous-endpoints-1", - "href": "documentation/v71/userguides/core.html#dichotomous-endpoints-1", - "title": "FACTS Core User Guide", - "section": "9.2 Dichotomous Endpoints", - "text": "9.2 Dichotomous Endpoints\nAt the end of each simulated trial the following frequentist values will be calculated using LOCF for missing data:\n\nUsing the methodology described by Agresti[11], Mee[12] and Nurminem[13] for comparing the difference of proportions:\n\ntest statistic,\np-value,\n95% confidence interval for the difference in proportions,\nmarginal probabilities of significance.\n\nusing Dunnett-adjusted dose-placebo comparisons for comparing the difference of proportions:\n\ntest statistic,\np-value,\n95% confidence interval for the difference in proportions,\nmarginal probabilities of significance.\n\nUsing the general trend test calculate the t-test statistic and p-value using user supplied contrast coefficients.\n\nP-values are calculated by user choice either using a normal approximation (see previous section on p-value calculations for continuous endpoints) or a Fisher’s exact test, which is a conservative test to test the null hypothesis that the outcome is independent of the treatment assignment. For the normality approximation to have good asymptotic coverage, the expected number of successes and failures under the null hypothesis should be greater or equal to 5 for both groups. In cases where this is not guaranteed, Fisher’s exact test is recommended when strict type 1 error control is required.\nIf neither placebo or active comparator are specified, difference from 0 is assessed for each dose arm and Dunnett-adjusted calculations are not carried out.\nLast observation carried forward (LOCF), Per-protocol (Ignore), and missing data considered failure are available as ways to handle missingness in dichotomous frequentist calculations.", + "objectID": "documentation/v71/userguides/crm.html#the-file-menu", + "href": "documentation/v71/userguides/crm.html#the-file-menu", + "title": "FACTS Dose Escalation CRM", + "section": "6.1 The “File” Menu", + "text": "6.1 The “File” Menu\nFACTS has a File menu with commands similar to those found in most Windows applications, but also some unique to FACTS. The commands can be found in Table 2.\n\n\n\nTable 2: List of commands in the CRM file menu\n\n\n\n\n\n\n\n\n\nCommand\nDefinition\n\n\n\n\nNew\nAllows the user to select a trial design type and start a new design; if there are unsaved changes in the current design the user is prompted to save them first.\n\n\nOpen\nAllows the user to select an existing FACTS file and open it; if there are unsaved changes in the current design the user is prompted to save them first.\n\n\nSave\nSaves the current changes in the design to the currently open FACTS file.\n\n\nSave As\nAllows the current version of the design to be saved to a new FATCS file; this file is then the “currently open” FACTS file going forward.\n\n\nExport Project\nCreates a “Zip” archive containing the current FACTS file and all the simulation results, so these can be easily archived, emailed, saved, etc.\n\n\nRecent Projects\nContains entries for the last ten FACTS files opened: selecting one re-opens it.\n\n\nRecent Folders\nContains entries for the folders that contain the last ten FACTS files opened: selecting one opens a file browser window on that folder allowing a ‘.facts’ file in that folder to be selected (or allowing the user to navigate to some different folder and select a ‘.facts’ file there).\n\n\nExamples\nContains example projects for the different design engines: selecting one opens it.\n\n\nClose\nCloses the current FACTS file, returning the user to the FACTS introduction screen.\n\n\nExit\nCloses FACTS altogether.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#time-to-event-frequentist-analysis", - "href": "documentation/v71/userguides/core.html#time-to-event-frequentist-analysis", - "title": "FACTS Core User Guide", - "section": "9.3 Time-to-Event Frequentist Analysis", - "text": "9.3 Time-to-Event Frequentist Analysis\nFor each simulated trial, the following frequentist analyses will be performed:\n\nDose-placebo comparisons based on log-rank test and the Cox proportional hazards model. Summaries include:\n\nThe log-rank and Wilcoxon test statistics and the corresponding p-values,\nEstimated hazard ratio and its confidence interval from Cox model,\nFor each dose its marginal probabilities of significance (the number of times it was significantly separated from placebo independent of whether any other doses were, based on the hazard ratio inference from the Cox model).\n\nMedian survival times based on the Kaplan-Meier method.\nFor the predictor, descriptive statistics are computes – a 7 number summary for a continuous predictor, percentages for the dichotomous predictor, and median time, average hazard, and a cox model with predictor as covariate are computed for a time to event predictor.\n\nThe following variations for adjusting the alpha level for multiple comparisons should be available using the user-specified 1-sided alpha: unadjusted, and Bonferonni adjusted.", + "objectID": "documentation/v71/userguides/crm.html#facts-settings-menu", + "href": "documentation/v71/userguides/crm.html#facts-settings-menu", + "title": "FACTS Dose Escalation CRM", + "section": "6.2 FACTS Settings Menu", + "text": "6.2 FACTS Settings Menu\nThe “Settings” command menu allows the user to do 2 things:\n\nSet various FACTS options to local settings – see below for details.\nReset the options based on the stored configuration file. This file, “config.xml”, will initially be installed during the FACTS installation process and is stored in the Windows “Program Files” folder, in the sub-folder where FACTS get installed.\nChange the stored configuration file. This command allows you to select a new configuration file and have FACTS copy it to the sub-folder within the Windows “Program Files” folder, where FACTS get installed so it becomes the new stored configuration file. This allows IT support to easily disseminate configuration changes.\nEnter a new or changed license key.\n\n\n6.2.1 Set Options\nThe FACTS Options dialog allows the user to:\n\nSet and Test the connection parameters to access a compute grid for running simulations.\nConfigure the version and location of R or R Studio that can be launched from within FACTS\nSelect how gamma distributions are parameterized.\n\n\n6.2.1.1 Grid Configuration\nA grid compute facility for running simulations will only be available if your local IT services have set one up. If they have done so, they\n\nMay have already set the appropriate parameters In the FACTS configuration file included with the FACTS installation files.\nInform you of the parameters to be set manually via this dialog\nSend a new configuration file that can be installed using the “Load Options” menu command.\n\nIf modifying the grid options manually, select the “Options” menu command and enter the values on the “Grid Configuration” tab of the displayed dialog window.\n\n\n\n\n\n\nFigure 16: Webservice Configuration\n\n\n\nFirst select the type of interface to the grid to be used, this is either:\n\nVia a network shared drive (with a “sweeper script” running on a client machine to transfer jobs to the grid management system and return results from it).\nVia a web service system using a webserver and database to communicate to a grid management system. The IT group supporting the grid should be able to tell you which interface they have implemented, if any. If access to the grid is via a Network Share it is necessary to specify:\nThe location of the network share folder, usually in the form \\<server name>\\<folder name\\>.\nWhether the grid client is running Windows or Linux (so end-of-line characters can be corrected)\nThe listener delay – this is the interval between “looks” when FACTS is waiting for simulation results to be complete\n\nOnce specified it is possible to use the “Test” button to check that the Network Shared folder is accessible and writeable.\nIf access to the grid is via a web service:\n\nThe location of the web service endpoint.\n\nClicking on “Test Configuration” and will cause FACTS will attempt to connect to the FACTS grid controller. The control will show which components of the connection are working.\nSee the FACTS Installation Guide and FACTS Simple Grid Interface Guide for more details of setting up a grid.\n\n\n6.2.1.2 R Configuration\nIn FACTS on the Simulation tab there are two controls that launch R – “Open in R” and “ Design Report” (in FACTS 6.2.0 the latter only available for FACTS Core designs).\nTo enable these to work the user must specify where the R or RStudio executable is installed and (if there is more than one version of R installed) which version of R to use.\n\n\n\n\n\n\nFigure 17: The R Configuration Dialog\n\n\n\nThe dialog allows the user to Add, Edit, Test and Remove links to versions of R.\n\n\n\n\n\n\nFigure 18: Adding a link to R\n\n\n\nClicking on “Add” opens a normal Windows directory browser window, the user must navigate to the location of an R installation (for example “C:\\Program Files\\R\\R-2.15.2\\bin”, select the file R.exe, and click “Open”. This adds a new entry on the R configuration dialog.\nClicking on “Edit” operates similarly to “Add” above, except the selected location replaces that currently selected entry on the R configuration dialog rather than adding a new one.\nClicking on “Test” checks whether the currently selected entry on the R configuration dialog is available, if it is not an error dialog is displayed:\n\n\n\n\n\n\nFigure 19: Example of R Configuration error\n\n\n\nClicking on “Remove” removes the currently selected location on the R configuration dialog.\nThe version of R to use by default is selected by clicking on the ‘Active’ check box of the version to use.\n\n\n6.2.1.3 Gamma Distribution Parameters\nIn FACTS a number of parameters require inverse gamma distributions to be specified as priors for the parameter value. There are two different parameterization of the inverse gamma provided so that the user can select the form they find the most intuitive.\n\n\n\n\n\n\nFigure 20: The parameterisation of Inverse Gamma Distributions\n\n\n\nThe first form uses parameters that are the mean of the distribution and the equivalent weight in terms of the equivalent number of observations. The second form uses an ‘Alpha’ and ‘Beta’ parameterization that some statisticians are familiar with and will find natural to use.\n\n\n\n6.2.2 Enter a license key\nIf a new license key is required, this command can be used to enter one. There are two ways of entering a new license:\n\n\n\n\n\n\nFigure 21: Enter FACTS License Key\n\n\n\nThe key can be entered directly, along with the associated Organization name, or by selecting a supplied license file.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#imputation", - "href": "documentation/v71/userguides/core.html#imputation", - "title": "FACTS Core User Guide", - "section": "10.1 Imputation", - "text": "10.1 Imputation\nUnless a deterministic method is used such as LOCF or BOCF, longitudinal models inform the dose response estimates by using the longitudinal model to stochastically impute subjects’ final endpoint data when it’s not been directly observed.\nFirst, data from subjects with intermediate and final observations is used to estimate the parameters of the longitudinal models.\n\nSubjects with missing final data have final data sampled from the posterior probability distribution of the longitudinal model given the subjects most recent intermediate visit (or in some models, all their available intermediate visit data). Subjects with no final or intermediate data have final data sampled from the posterior probability distribution of the dose response model given the dose arm the subject was allocated to.\n\nThe dose response model is then re-estimated using all the data.\n\nThis process is then repeated on successive iterations of the MCMC sampling loop. Thus the imputed values are imputed with both the uncertainty in the longitudinal model and the uncertainty in the estimates of the parameters of that model.\nIt is actually better not to update both the longitudinal model parameters and the dose response model parameters every MCMC step, but allow the model parameters to converge slightly before imputing the missing data again. This can be done on the MCMC settings control on the Simulation tab and setting the “Samples per Imputation” parameter. As a rough guide, if it at some early interims > 5% of the data being analyzed will be imputed, a value in the range 2 to 10 is recommended to avoid underestimating the uncertainty. A higher number should be used the greater the proportion of imputed data.\nA similar procedure is used when imputing event times based on a predictor endpoint in FACTS Core Time-to-Event.\nNote: FACTS is not fitting a joint Bayesian model of the longitudinal and dose response models. This would require a full MCMC fit of one model for every MCMC step of the other. Thus, if taking 2,500 samples, we would require a total of 2,5002 samples. This would make running simulations with longitudinal model prohibitively expensive.[14] Rather in FACTS the LM is a “working mode” to improve our estimate of the dose response model.", + "objectID": "documentation/v71/userguides/crm.html#the-help-menu", + "href": "documentation/v71/userguides/crm.html#the-help-menu", + "title": "FACTS Dose Escalation CRM", + "section": "6.3 The Help Menu", + "text": "6.3 The Help Menu\nFACTS has a Help menu with commands to assist you with the use of FACTS, providing links to users guides, tutorial and training videos. The commands are:\n\n\n\nTable 3: List of commands in the CRM help menu\n\n\n\n\n\n\n\n\n\nCommand\nDefinition\n\n\n\n\nUser Guides\nProvides access to documents such as this one, with (mainly) one user guide to each design type within FACTS. Exceptions to this simple structure are: 1. Core Design User Guide: A guide to the options under the ’Design” tab for FACTS Core for all endpoints. 2. Staged Design User Guide: As the staged design allows the design of one FACTS Core stage followed by a second, most of the interface is common to the basic FACTS Core. This guide describes the differences and additional aspects for all endpoints. 3. Dose Escalation User Guide: This covers all the Dose Escalation engines except for N-CRM and 2D-CRM that have their own. It thus covers the 3+3, mTPI, CRM(Toxicity), CRM(Ordinal), CRM(Efficacy) and bCRM engines.\n\n\nTutorials\nProvides access to all the tutorial documents, which describes detailed examples of use of all the engines in FACTS and many of their options. The examples under the File > Examples menu option largely correspond to the different tutorials described here.\n\n\nDesign Specifications\nThese are technical documents that describe the mathematical models implemented in FACTS in detail.\n\n\nExecution Guides\nThe FACTS GUI can be run in command line mode so simulations can be run/re-run from scripts. With the simulation command line flag, and passed a directory rather than a file, FACTS will run simulations for every “.facts” file in that directory – and recurse into any sub-directories and simulate any “.facts” files there too. A full guide to command line mode can be found here. The FACTS simulation engines are also available in “command line executable” form. There are guides here that document their command line parameters and how to use them to analyse a data set – e.g. to perform an interim analysis whilst executing a trial designed with FACTS.\n\n\nFACTS file XML Specs\nThese guides describe the parameters in the “.facts” files, which are text files in XML format. For expert users understanding this format allows them to use scripts to generate versions of an initial “.facts” file with slight variations in the parameters such as stopping thresholds or priors. Modification of “.facts” files outside of FACTS needs to be done with care, errors may render the file unusable by FACTS.\n\n\nVideos\nProvides access to links to the introductory, training and webinar videos that Berry Consultants has recorded and makes available over the internet to FACTS users.\n\n\nView log…\nIf an error has occurred in FACTS, often the FACTS log file can shed light on what is going wrong. The log file is hidden away in some unfashionable and hard to locate Windows folder; this command option provides easy access to it. Allowing you to email facts support with a description of what occurred, attaching a copy of this log file having saved it somewhere convenient such as your desktop.\n\n\nSupport\nLaunch a simple editor for sending an email to our support account: facts@berryconsultants.net\n\n\nAbout\nDisplays a simple “about box” that includes the detailed version number of FACTS.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#how-many-longitudinal-models", - "href": "documentation/v71/userguides/core.html#how-many-longitudinal-models", - "title": "FACTS Core User Guide", - "section": "10.2 How many longitudinal models?", - "text": "10.2 How many longitudinal models?\nWhen specifying a longitudinal model in FACTS, the user must clarify whether the longitudinal model is shared across all doses, or if different arms are to estimate different functions connecting early endpoints to the final endpoint.\nThe options that may be selected for the number of model instances are:\n\n“Single model for all arms” – just one set of longitudinal parameters is estimated using all the subject data regardless of their treatment.\n“Model control separately” – two sets of longitudinal parameters are estimated, one using data from just those subjects on the control arm, and the other using all the subject data from all the other arms.\n“Model comparator separately” (only available if there is an active comparator arm) - two sets of longitudinal parameters are estimated, one using data from just those subjects on the active comparator arm, and the other using all the subject data from all the other arms (control and active treatments).\n“Model control and comparator separately” (only available if there is an active comparator arm) - three sets of longitudinal parameters are estimated, one using data from just those subjects on the active comparator arm, one using data from just those subjects on the control arm, and the third using all the subject data from all the other arms.\n“Model all arms separately” – a set of longitudinal parameters is independently estimated separately for each arm, each set estimated just using the data available from the subjects on that arm.\n\nThe fewer models used, the more data is pooled, the more precisely the model parameters can be estimated, and the more informative the intermediate data can be. Pooling data assumes that subjects in different groups have the same longitudinal profile, although they may still have different magnitude or probability of response (estimated by Dose Response Model).\nIf the response profile could be different on different treatment arms – for example, if subjects on control recover constantly over time, but those on an effective dose of the study drug recover very quickly early on, and more gradually later in their follow-up - a longitudinal model based on pooled data would tend to over-estimate the final endpoint of subjects on an effective dose of the study drug when only their early data was available. In a case like that, it would be better to use separate models. If the rapid early response was likely on all study drug treatment arms, then possibly use “model control separately.” If, however, the rapid response will only be seen on some study drug arms then use “model all arms separately”.\nIn addition to declaring how many longitudinal models should be estimated, when there is more than one model instance the user must declare if the prior distributions should be specified differently across each model instance or not. The options that may be selected for prior specification (for all LMs but linear regression) are:\n\nSame priors across all model instances\n\nEach instance of the model has identical prior distributions on its parameters. Estimation is still performed independently on each model instance.\n\nSpecify priors per model instance\n\nEach instance of the model has its own priors that may vary across instances.\n\n\nThe linear regression longitudinal model has a different parameter set estimated for each visit, so its prior specification rules are slightly different. See the linear regression section below for specifics about prior specification specific to this model.", + "objectID": "documentation/v71/userguides/crm.html#study-info", + "href": "documentation/v71/userguides/crm.html#study-info", + "title": "FACTS Dose Escalation CRM", + "section": "7.1 Study Info", + "text": "7.1 Study Info\nThe Study Info sub-tab provides parameters for specifying:\n\nWhether the trial has an Efficacy endpoint as well as a Toxicity one.\nWhether recruitment is in Cohorts or uses Open Enrolment,\nWhether the trial data is being analyzed as a single population (single group) or two groups (which could be 2 different patient types, or 2 different treatment types).\nThe option to specify that the trial should include an expansion cohort once the MTD has been identified.\nThe option (if using open enrolment) to specify the use of backfill.\n\nIncluding an efficacy endpoint – this allows the trial to include a binary efficacy outcome that is observed at the same time as the toxicity endpoint. Once the MTD has been sufficiently determined further cohorts are allocated to determine the MED (Minimum Effective Dose) as long as that is below the MTD, until the maximum sample size or MED stopping rules have been reached.\nCohort versus Open enrolment: cohort enrolment is the standard way of running a phase 1 trial, a cohort of subjects of pre-determined size are treated at the current dose and the trial pauses until all the subjects in the cohort are complete, then the dose for the next cohort is determined. A phase 1 trial using Open Enrolment recruits ‘all comers’ with a cap on the number of subjects who can be treated but have not yet had a final result. Subjects that arrive whilst this cap has been reached are deemed to be ‘lost’ to the study.\nIf Open Enrolment and Efficacy Endpoint options are being used together, then subjects who arrive who cannot be allocated to the MTD (because the cap number of subjects awaiting a final result has been reached), can be allocated to the MED (as long as that is below the MTD).\nIf the trial is analyzing 2 Groups then a joint statistical model is used with options to constrain the group 2 difference in the intercept term to be +ve or -ve, and options as to whether a common or separate estimates of the slope term are used.\nIf an expansion cohort is included, the this is a single cohort (or one per group, if 2 groups is being used) typically much larger than used during the dose escalation, that is assigned at the end of the study to the target dose. FACTS simulates the results that arise from this cohort and a final analysis.\nIf open enrolment is being used, the further option to use backfill becomes available. The parameters on this tab for backfill, are to specify the maximum number of subjects that can be allocated for escalation, and the maximum that can be allocated in backfill. These two maximums should not total less than the overall “Max subjects” that can be enrolled. If adding backfill to a trial, usually the previous “Max subjects” becomes the “Max study allocation for escalation”, and an additional sample is allowed for backfill and added to the overall Max subjects.\nIf the trial has two groups the backfill maximums are the sum of the subjects in the two groups.\nFor Cohort enrolment, the parameters are:\n\nMaximum Study Size, in cohorts: the maximum number of cohorts the trial can use, though designs can include conditions that cause them to stop earlier.\nIf the trial has two groups, the maximum number of cohorts of the second group.\nCohort size: The number of subjects in each cohort. The maximum sample size for the trial is simply: Max Trial Size (cohorts) * Cohort Size.\nCohort information delay: Normally left at zero, this allows for the trial to be simulated with cohorts recruited more quickly than if waiting for the last cohort to complete before treating the next cohort. This allows the trial to complete in shorter time, but is likely to lead to a larger incidence of toxicities. If the delay is set to 1, the second cohort will be recruited before the results for the first cohort are available, the third cohort will be recruited after the results of the first cohort are available but before the results for the second cohort are available, and so on.\nExecution rate: the time taken to recruit, treat and complete the observation of each cohort (in weeks). The value of this parameter does not affect the behavior of the simulations, but it allows a nominal “duration” of each simulation to be calculated. Unlike other FACTS simulations, this duration is not simulated stochastically, it is simply the number of cohorts * this duration. Its purpose is to give a figure to compare with open enrolment designs of the same trial.\n\n\n\n\n\n\n\nFigure 22: Study Info - Cohort Enrolment\n\n\n\n\n\n\n\n\n\nFigure 23\n\n\n\nIf rather than Cohorts, subjects are recruited using open enrolment, the parameters are:\n\nMax subjects: the maximum number of subjects who can be recruited into the study.\nTime unit – this is a text string that will change the “units” label for time on graphs. This allows data to be more easily entered when the natural time unit is not “weeks”, but “days” or “months”.\nMean recruitment rate: for simulation purposes this is the average number of subjects who will be expected to be available for recruitment during each time period. Recruitment is simulated using a standard Poisson process.\nTime until final result: the time for each subject for their final result to become available. This is simulated as a fixed length of time that is the same for all subjects.\nMaximum subjects without a final result: the cap on the number of subjects on the current dose or a backfill dose (if backfill is enabled) who can be recruited but not yet completed. This is also known as the ‘maximum queue length’. Subjects arriving and available for recruitment while the number of subjects on this dose who have been treated but have not yet completed is at this maximum, are dropped and assumed no longer available for recruitment. Once the current subjects complete the study has to await further new subjects to become available. There are three caps:\n\nMaximum subjects without final results if the dose is uncleared. This allows the design to be cautious when a new dose is used for the first time.\nMaximum subjects without final results if dose is cleared and below MTD. This allows a larger number of subjects without final results to be recruited at backfill doses or at the current escalation dose if backfill to the current escalation dose (“frontfilling”) is enabled, or at the MED in the efficacy phase of a trial that includes an efficacy endpoint.\nMaximum subjects without final results if dose is cleared and at MTD. This allows us to be more cautious if the model thinks all doses are toxic or if we are allocating at the model MTD and don’t want to expose too many subjects.\n\nBackfill – this can be enabled. Backfilling is the allocation of subjects to a dose below the current target dose, if the number of subjects allocated to the current target dose without final results has reached the maximum. Further parameters for backfill are set on the “Backfill” tab under the “Design” tab. On this tab, if backfill is enabled, two sub-maximums can optionally be specified:\n\nthe maximum number of subjects who can be allocated as part of usual allocation for escalation and MTD determination (and MED if efficacy is included in the trial),\nand the maximum number of subjects who can be allocated as part of “backfill”.\n\n\n\n\n\n\n\n\nFigure 24: Study Info - Open Enrolment\n\n\n\nGroups: a trial can be analyzed as a “single group” or as “two groups”. If analyzed as a single group, then all subjects are assumed to be the same and treated the same (except for the difference in the dose strength). If analyzed as two groups this allows either:\n\nThe subjects can be simulated as coming from two similar but distinct groups such as: adults and children, first line or recurrent, having some concomitant treatment or not. The separation into the two groups is based on some property of the subject.\nOr the subjects can be simulated as having been allocated (possibly randomized) to one of two versions of the treatment, with the same rang of dose strengths and differing in some other way such as dosing schedule, treatment duration or combination with an additional treatment. The separation of the subjects into the two groups is under the control of the protocol.\n\nIn either case the same analysis options are available (hence we use the generic term “groups” to describe this feature).\nIf enrolment is by cohort, the there are two separate “maximum study sizes” in cohorts – one for each group.\nThe Group 2 recruitment, while it overlaps in time with the Group 1 recruitment, is simulated as being in lock-step and the recruitment of the cohort in each group is concurrent and analyzed when both are complete. In the ‘cohorts.csv’ files that are output, the cohort numbers indicates which cohorts were concurrent. The options are:\n\nTo recruit group 1 first then recruit group 2 only when group 1 is complete.\nTo start recruiting both groups in parallel from the outset.\nTo start recruiting group 2 once group 1 has reached a specified dose. The first group 2 cohort is recruited in parallel with the next group 1 cohort after the first group1 cohort has been allocated the specified dose (if cohorts can be accrued before the cohort before has completed, the group 2 is accrued too – it does not wait until the group 1 cohort completes unless the next group 1 also waits).\nTo start recruiting group 2 once group 1 has recruited a specified number of subjects. The first group 2 cohort is recruited in parallel with the next group 1 cohort after the specified number of subjects had been recruited into group 1.\n\nIf enrolment is open then there are options similar to the cohort enrolment to control when enrolment into group 2 starts:\n\nTo recruit group 1 first then recruit group 2 only when group 1 is complete.\nTo start recruiting both groups in parallel from the outset.\nTo start recruiting group 2 once group 1 has reached a specified dose. The first group 2 subject can be recruited after the first group1 subject has been allocated the specified dose.\nTo start recruiting group 2 once group 1 has recruited a specified number of subjects. The first group 2 subject can recruited after the specified number of subjects had been recruited into group 1.\n\nBut in addition the user specifies the maximum number of subjects in Group 2 and how the recruitment is to be simulated:\n\nWith the group membership a property of the subject – along with a mean recruitment rate for group 2.\nWith subjects randomized between the two groups (the randomization is fixed at 1:1).\n\nThe user specifies the three “Maximum subjects without final results …” for the second group.\nIf backfill is enabled, the backfill totals apply to the total of the subjects on both groups.\n\n\n\n\n\n\nFigure 25: Study info - 2 group options with open enrolment\n\n\n\nEnable Final Expansion Cohort: if this is enabled a final cohort of specified size will be allocated the dose selected as MTD at the end of the N-CRM phase of the study:\n\nIf the study includes a control arm, the number of subjects in this expansion cohort to be allocated to control is also specified.\nIf the study has two groups, two separate expansion cohorts will be allocated, their sizes are set separately.\nIf the study includes observing efficacy then the target dose can be changed from MTD to MED or OSD.\n\n\n\n\n\n\n\nFigure 26\n\n\n\nSimulating an additional efficacy outcome is simply specified by checking the “include efficacy” checkbox.\n\n\n\n\n\n\nFigure 27: Study tab with “Include efficacy” checked\n\n\n\nSimulating an efficacy endpoint can be combined with all the other features (two groups, open enrolment, backfilling) already discussed, as well as with ordinal toxicity and fine grain dosing that are described below.\nCurrently there are two significant limitations to the simulation of an efficacy endpoint:\n\nThe endpoint is assumed to be dichotomous.\nThe endpoint is assumed to be observable at the same time as toxicity.\n\nWe hope to lift these restrictions in a later version of FACTS.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#longitudinal-models-for-a-continuous-endpoint", - "href": "documentation/v71/userguides/core.html#longitudinal-models-for-a-continuous-endpoint", - "title": "FACTS Core User Guide", - "section": "10.3 Longitudinal Models for a Continuous Endpoint", - "text": "10.3 Longitudinal Models for a Continuous Endpoint\n\n10.3.1 LOCF (Last Observation Carried Forward)\nThe simplest possible longitudinal model. If {yit} is the set of observed responses from early visits, and yitm is the last observed value of y*i**t, then the LOCF model for the final endpoint Yi* is\nYi|{yit} = yitm\nIn the continuous engine tm can be any earlier observed visit including the baseline value.\n\n\n10.3.2 Linear Regression\nThe linear regression model fits a simple linear model from the data at each visit with the final visit\nYi|yit ∼ αt + βtyit + N(0, λt2)\nThe parameter αt is the intercept of the model for visit t, and the parameter βt is a multiplicative modifier (slope) of the response observed longitudinal at visit t to adjust the prediction of the final endpoint.\nImputation of the final endpoint value for a subject using the linear regression longitudinal model is based on only the latest observed visit’s endpoint value.\nThe default setting of “Same priors across all model instances and visits,” implies that each parameter α, β, and λ have the same prior for all t. Estimation of those parameters is still done independently for each model instance. The one prior across all model instance are formulated as:\nαt ∼ N(αμ, ασ2)\nβt ∼ N(βμ, βσ2)\n\\[\\lambda\\_{t}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n}}{2},\\frac{\\lambda\\_{\\mu}^{2}\\lambda\\_{n}}{2} \\right)\\]\nThe above prior formulation may not be desirable if specifying priors that are not extremely diffuse – especially on the β parameters. Instead, selecting “Specify priors per visit across all model instances,” will share the prior specification across all instances of the model, but allows for different priors to be put on the parameters associated with each visit. The user inputted prior parameters are now subscripted with t to denote the visit they correspond to. These priors apply to all model instances:\nαt ∼ N(αμt, ασt2)\nβt ∼ N(βμt, βσt2)\n\\[\\lambda\\_{t}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n\\_{t}}}{2},\\frac{\\lambda\\_{\\mu\\_{t}}^{2}\\lambda\\_{n\\_{t}}}{2} \\right)\\]\nIt is also possible to specify priors “Per model instance and visit,” in which every visit has separate priors, and those differing priors vary across model instances. This is the most flexible prior specification method. The user inputted prior parameters are now subscripted by both t for visit and i for model instance.\nαti ∼ N(αμti, ασ*t**i*2)\nβti ∼ N(βi, βσti2)\n\\[\\lambda\\_{ti}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n\\_{ti}}}{2},\\frac{\\lambda\\_{\\mu\\_{ti}}^{2}\\lambda\\_{n\\_{ti}}}{2} \\right)\\]\nA potential starting place for non-informative prior values would be\n\nα mean of 0, SD >= largest expected response\nβ mean of either 0 or (final visit time / early visit time), SD >= largest expected ratio of final visit to first visit\nλ mean of expected SD of the endpoint (‘sigma’), weight of 1. The variability of the prediction from the longitudinal model (based on an observed intermediate response) should be less than that based solely on the treatment allocation, thus this is a weakly pessimistic prior on the effectiveness of the longitudinal model that should be quickly overwhelmed by the data.\n\nThis model is easy to understand and can be used even if there is only one visit, but doesn’t get more powerful if there are more visits. Its power will depend on the degree of correlation between the intermediate visit response and the final response.\n\n\n10.3.3 Time Course Hierarchical\nThe Time Course Hierarchical models the relationship between subjects’ early responses and their final response. It incorporates a per-subject offset from the mean response and a scaling factor from each visit to the final endpoint, but with no model of the change from visit-to-visit.\nThe response at the tth visit for the ith subject, having been randomized to the d*t**h* dose is modeled as:\ny*i**t ∼ eαt(θd + δi) + N(0, λt*2)\nThe imputed final response (visit T) for the ith subject, having been randomized to the dth dose is modeled as:\nY*i**T ∼ θd + δi + N(0, λT*2)\n(i.e. αT is 0).\nThe model parameters can be interpreted as follows:\nθd is the estimated mean response at the final visit in dose d from the dose response model.\n\nδi is the estimated patient level random effect around the mean final response (θd) for the dose d that patient i is randomized to.\nαt is a scaling parameter that determines the proportion of the final response that is observable at visit t. A value of αt = 0 indicates that the expected value of early visit t is equal to the estimated final visit mean θd. A value of αt = −0.69315 indicates that the expected value of early visit t is 50% of the estimated final visit mean θd.\nλt2 is the variance of the endpoint around the estimated mean response at visit t.\n\nThe prior for αt is a normal distribution with a user specified the mean and standard deviation:\nαt ∼ N(αμ, ασ2),\nThe prior for the δi terms is a normal distribution with a mean of 0 and variance τ2.\nδi ∼ N(0, τ2)\nτ2 is estimated as part of the longitudinal model, and has an inverse gamma prior distribution with prior central value τμ and weight (in terms of “equivalent number of observations”) τn:\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\\\\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\nThe prior for the λt2 terms is an inverse gamma distribution with prior central value λμ and weight (in terms of “equivalent number of observations”) λn:\n\\[\\lambda\\_{t}^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n}}{2},\\frac{\\lambda\\_{\\mu}^{2}\\lambda\\_{n}}{2} \\right)\\]\nA reasonable starting place for prior values would be\n\nαt mean of -2, SD of 2, … so the prior ~70% interval for αt is between -4 and 0 (+/1 1 SD) and thus the prior 70% interval for eαt to be between 0.02 and 1.\nτ mean set to the expected SD of the endpoint (‘sigma’), with a weight of 1.\nλt mean set to the expected SD of the endpoint (‘sigma’), with weight of 1.\nWe would expect τ2 + λ2 ≈ σ2, thus to specify a prior mean of σ for each with a weight of 1 is a weakly pessimistic prior that should be quickly overwhelmed by the data.\n\nThis model is useful if there is thought to be a significant per-subject component to the response that should be manifest at the intermediate visits, and sufficient visits for the per-subject component to be estimated.\n\n\n10.3.4 Kernel Density\nThe Kernel Density Model longitudinal model is a non-parametric re-sampling approach that is ideal for circumstances where the relationship between the interim time and the final endpoint is not known or not canonical.\nThe procedure is as follows. Assume an interim value for patient i at time t, Y*i**t. Patient i* does not have an observed final endpoint at time T, so one is to be imputed. Let (X1t, X1T), …, (Xnt, XnT) be the set of values for the previous subjects for whom there exists an interim value X*t and final value X*T.\nTo impute a value of YiT given Yit, a pair (Xkt, XkT) is selected with probability based on the pair’s time t visit response’s proximity to the observed Y*i**t*:\n\\[\\Pr\\left( Selecting\\\\\\left( X\\_{kt},\\\\X\\_{kT} \\right) \\right) = \\frac{\\exp\\left( - \\frac{1}{2h\\_{X\\_{t}}^{2}}\\left( Y\\_{it} - X\\_{kt} \\right)^{2} \\right)}{\\sum\\_{k = 1}^{n}{\\exp\\left( - \\frac{1}{2h\\_{X\\_{t}}^{2}}\\left( Y\\_{it} - X\\_{kt} \\right)^{2} \\right)}}\\]\nThen, a value of YiT is imputed from the following distribution, which uses the selected pair’s final endpoint response XkT:\nYiT ∼ N(XkT, hXT2)\nThe bandwidths hXt and hXT are selected based on the criterion given by Scott (1992). That is,\n\\[h\\_{X\\_{j}} = \\sigma\\_{X\\_{j}}\\\\\\left( 1 - \\rho^{2} \\right)^{\\frac{5}{12}}\\\\\\left( 1 + \\\\\\frac{\\rho^{2}}{2} \\right)^{- \\frac{1}{6}}{\\\\n}^{- \\frac{1}{6}}\\\\\\\\\\\\\\\\\\\\\\\\for\\\\j = t\\\\and\\\\T\\]\nwhere σXj is the standard deviation of the observed responses at time j, n is the number of pairs (X*t, X*T) that were chosen between, and ρ is the correlation coefficient between Xt and XT in the pairs (X1t, X1T), …, (Xnt, XnT).\nThe Kernel Density model does not take prior distributions as input. So long as each early visit has more subjects with an observed early response and final response than the value entered in “Kernel minimum number of subjects:” then this algorithm runs without regard for user input.\nIf any visit has fewer subjects with early data and final data than the value of “Kernel minimum number of subjects:”, then instead of calculating the values of hXt or hXT the input values of Kernel bandwidth and standard deviation of prior mean are used.\nPossible starting values for these parameters are:\n\nhx and hy the expected SD of the endpoint (‘sigma’)\nThe minimum number of subjects completed: 6\n\nThe Kernel Density model is effective and flexible with no model assumptions, but its computational overhead is large. Simulations may take ~10 times longer to run, and having no prior model there has to be ‘in trial’ data before it can come into play.\n\n\n10.3.5 ITP\nThe ITP (Integrated Two-component Prediction) model fits an observation for patient i on dose d at visit t as:\n\\[y\\_{idt} = \\left( \\theta\\_{d} + s\\_{id} + \\epsilon\\_{idt} \\right)\\left( \\frac{1 - \\text{exp}\\left( kx\\_{idt} \\right)}{1 - \\text{exp}(kX)} \\right)\\]\nwhere ϵidt ∼ N(0, λ2)\ns*i**d ∼ N(0, τ*2)\nand θd is the mean estimate of the final endpoint for dose d using all complete and partial data and assuming an independent dose response model on the doses. s*i**d is a subject specific random effect, k* is a shape parameter, xidt is the time yidt is observed, X is the time to final endpoint, and each ϵidt is a residual error.\nThe ITP model is similar to the Time Course Hierarchical above in that both models estimate subject specific component of the response. The biggest difference between the two is that the ITP models the response change over time as a parametric function based on the parameter k, rather than having a separately estimated eαt for each visit.\nThe shape parameter k determines the rate at which the final endpoint’s eventual effect is observed during a subject’s follow-up. A value of k = 0 indicates that the proportion of effect observed moves linearly with time. A value of k < 0 means that the eventual final effect is observed earlier in follow-up and plateaus off as time moves towards the final endpoint. A value of k > 0 indicates that less of the total final endpoint effect is observed early in follow up, but as time approaches the final endpoint time the proportion of the effect observed increases rapidly. Values of k less than 0 tend to be more common than values of k greater than 0. See the figure below for a visualization of the different response-over-time curves that can be estimated with the ITP model.\n\nThe priors for the parameters in the ITP model are:\nk ∼ N(μk, σk)\nθd ∼ N(μθd, σθd2)\n\\[\\tau^{2}\\\\\\sim\\\\IG\\left( \\frac{\\tau\\_{n}}{2},\\\\\\frac{\\tau\\_{\\mu}^{2}\\tau\\_{n}}{2} \\right)\\]\n\\[\\lambda^{2}\\\\\\sim\\\\IG\\left( \\frac{\\lambda\\_{n}}{2},\\\\\\frac{\\lambda\\_{\\mu}^{2}\\lambda\\_{n}}{2} \\right)\\]\nA reasonable starting place for prior values would be:\n\nθd mean of the expected mean improvement from baseline on the Control arm, with SD greater than or equal to the expected treatment effect size.\nk a mean of 0 and SD of 2, if subject improvement is expected to be rapid and then diminishing, the prior mean might be -0.5 or -1, if subject improvement is expected to be initially slow or non-existent then increasing, the prior mean might be 0.5 or 1.\nτ mean set to the expected SD of the endpoint (“sigma”), with a weight of 1.\nλ mean set to the expected SD of the endpoint (“sigma”), with a weight of 1.\n\nThe ITP model implies that the variance of the observations shrinks towards 0 with the mean (so early visits have reduced expected responses and variances). The ITP model may result in biased estimates of θd and/or the variance terms τ2 and λ2 if the mean-variance relationship assumed by the ITP model is not present in the observed data. If the model assumptions are correct this can be a very effective longitudinal model.", + "objectID": "documentation/v71/userguides/crm.html#toxicity", + "href": "documentation/v71/userguides/crm.html#toxicity", + "title": "FACTS Dose Escalation CRM", + "section": "7.2 Toxicity", + "text": "7.2 Toxicity\nThe Toxicity sub-tab provides parameters for specifying:\n\nWhether toxicity should be simulated as dichotomous or ordinal. If simulated as Ordinal, toxicity can be simulated as a 1-3 scale or 1-4 scale. In both cases ‘1’ is “no-toxicity”, 2 is “mild toxicity” and 3 is the toxicity of interest (from the point of view of defining the MTD, target toxicity band and Overdose Control. If a four category scale is selected, 4 is “sever toxicity” or death. Choosing whether to model the ordinal response is a separate option and is present on the Design > Toxicity Response tab.\nType of target: this allows the user to specify whether the dose selection targets “the dose who’s estimated toxicity rate is closest to a specified target rate” or “the dose with the highest posterior probability of having a toxicity rate in a target band”. The former is the target rule used in the original CRM papers ((O’Quigley, Shen, and Gamst 1999), (deMoor et al. 1996), and the latter rule was introduced in (Neuenschwander, Branson, and Gsponer 2008).\nToxicity target (only displayed if the type of target is “a single dose”): this allows the target toxicity rate to be specified and whether the target dose is the one nearest, the one nearest but with a lower rate or the one nearest but with a higher rate.\nTarget: this panel allows the target toxicity bands to be specified along with overdose control limits. The panel is displayed and enabled even if the target type is “a single dose” to allow overdose control limits to be specified.\nType of Target: controls the selection of the dose for the next cohort – this can be to target a single dose (to replicate the original CRM behavior, see this section) or to target the dose with the highest probability that its toxicity rate lies in a target band.\n\n\n\n\n\n\n\nFigure 28: Toxicity tab targeting a toxicity band\n\n\n\n\n7.2.1 Targeting a Toxicity Interval\nTargeting a toxicity band or interval is an innovation introduced with the N-CRM design, unlike other CRM designs that select the dose that is expected to have a toxicity response closest to the desired tolerated limit, the N-CRM selects the dose that has the highest posterior probability of having a toxicity rate in a target toxicity band. This has the advantage of a) having a clearer probability statement and b) having in addition probability statements about the probability of under and overdosing (the toxicity rate being below or above the target toxicity band).\n\nThe uncertainty in the estimate of toxicity at each dose is expressed by calculating the posterior distribution of the estimate of the rate of toxicity at each dose and calculating the proportion of that distribution that falls in to each of 4 bands of toxicity: ‘Under-dosing’ (toxicity so low that it is likely that a higher dose could be used), ‘Target’ toxicity (we want to select doses whose toxicity rate is most likely to be in this band), ‘Excess’ toxicity (toxicity higher than desired) and ‘Unacceptable’ toxicity.\n\nUnder-dosing: this band always starts at 0.0; the user specifies the upper bound.\nTarget band: this band always starts at the upper-bound of the under-dosing band; the user specifies the upper bound.\nExcess toxicity: this band always starts at the upper-bound of the target band; the user specifies the upper bound.\nUnacceptable toxicity: this band always starts at the upper-bound of the target band, with an upper bound of 1.0. The graph shows the width of the different bands using a simple, fixed, example posterior probability distribution of a toxicity rate.\n\nIntervals are relative to control: if a control arm is included in the study, then toxicity bands can be defined as the difference in toxicity rate relative to control. Negative differences (a lower toxicity rate than control) are always treated as under-dosing. To enable this option it is necessary to first go to the Study > Treatment Arms tab and select Include Control.\nLimit max excess/unacceptable toxicity: the ‘overdose control’ in terms of a maximum allowed posterior probability that a dose’s toxicity rate lies in either the ‘Excess’ or the ‘Unacceptable’ toxicity bands. Any dose with a posterior probability of having a toxicity rate in either of these two bands that is higher than the specified limit, cannot be selected for allocation to the next cohort, nor selected as MTD at the end of the study (this gives rise to slightly different results compared to those in (Neuenschwander, Branson, and Gsponer 2008) where the overdose control was not applied to final selection).\n\nIt is possible to have the overdose control limit vary with the number of cohorts allocated. In particular this can be used to reduce the overdose limit as the number of cohorts (and the amount of information) grows. For example for a particular prior and final level of overdose control, it may be that initial escalation is excessively constrained, one way to allow early escalation in this setting is to use these parameters to allow an higher initial overdose control limit and gradually reduce it over time to the final desired limit. Tuning the parameters will require some iteration and simulation. A varying limit is specified by the specifying amount to change the limit by per cohort and the final limit. The amount to change by is always entered as a number in the range (0,1), whether this is an increment or decrement depends on whether the target limit is greater or less than the initial limit. Leaving the change in limit at its default of 0 means the limit does not vary.\nLimit max unacceptable toxicity: as for the previous parameter, but here the overdose control is only in terms of the posterior probability that a dose’s toxicity rate lies in the ‘Unacceptable’ toxicity band.\nAs or the limit on excess/unacceptable toxicity it is possible to have the overdose control limit vary with the number of cohorts, see the description above.\n\n\n\n7.2.2 Targeting a single dose\nIt is possible to use the N-CRM design engine with a conventional CRM allocation strategy - to “allocate to the nearest / highest dose below the maximum tolerated toxicity”; this allows conventional CRM design to be simulated with some of the additional features of N-CRM:\n\nOverdose control\nEstimate both parameters of the 2 parameter logistic\nThe “Recommender” to analyze a specific data set.\n\nThe target is calculated by:\n\nIn the MCMC sampling loop finding the dose that meets the target criteria, a doses probability of being the target is then the proportion of times that dose meets the target criteria across the MCMC sampling.\nRather than selecting the dose with the highest probability, the dose at the 50% quantile is used. The cumulative probability of being the target is calculated over the doses in ascending dose strength, and the dose when the cumulative probability passes 50% is selected. This addresses some problems that can arise when very little data is available: that the dose with the highest probability is at one end of the dose range, but that probability is not that high, or that doses are not evenly spaced and a dose close to both its immediate neighbors may never have greater probability than both of them.\n\nSetting the Type of Target option to Target a single dose, modifies the tab thus:\n\n\n\n\n\n\nFigure 29: N-CRM, targeting a single dose, not a toxicity band\n\n\n\nWhen targeting a single dose FACTS allows the user to specify:\n\nThe target toxicity rate\nWhether to allocate to the dose with the mean estimate of its toxicity rate nearest the target, highest dose with a mean estimate of its toxicity rate below the target or lowest dose with a mean estimate of its toxicity rate above the target.\nAn option to use the toxicity rate relative to control, rather than the default of the absolute toxicity rate. To enable this option it is necessary to first go to the Study > Treatment Arms tab and select Include Control.\n\nThe definition of the boundaries of the toxicity bands is still included in order to allow the specification of overdose control limits. These are calculated and applied in exactly the same way as when targeting a toxicity interval.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#longitudinal-models-for-a-dichotomous-endpoint", - "href": "documentation/v71/userguides/core.html#longitudinal-models-for-a-dichotomous-endpoint", - "title": "FACTS Core User Guide", - "section": "10.4 Longitudinal Models for a Dichotomous Endpoint", - "text": "10.4 Longitudinal Models for a Dichotomous Endpoint\n\n10.4.1 LOCF (Last Observation Carried Forward)\nThe simplest possible longitudinal model. If {yit} is the set of observed responses from early visits, and yitm is the last observed value of y*i**t, then the LOCF model for the final endpoint Yi* is\nYi|{yit} = yitm\n\n\n10.4.2 Beta Binomial\nThe Beta Binomial longitudinal model imputes a patient’s final endpoint given their most recent observed response.\nThe final endpoint response Yi is modeled as:\nYi ∼ Bernoulli(πtyit)\nwhere πtyit is the probability that a patient is a response at the final endpoint given its early observed endpoint at time t is y*i**t*,\nπtyit = Pr (Yi = 1 | yit) ∼ Beta(αtyit, βtyit)\nWe use the set cardinality operator |…| to obtain the posterior distributions of αt* and βt* as:\nαt0 = αμ0 + |Yi = 1, y*i**t* = 0|\nβt0 = βμ0 + |Yi = 0, y*i**t* = 0|\nαt1 = αμ1 + |Yi = 1, y*i**t* = 1|\nβt1 = βμ1 + |Yi = 0, y*i**t* = 1|\ni.e. a prior value (αμ0, αμ1, βμ0, βμ1) plus the number of subjects for which the final response is known to be 1 for αtx (or 0 for βtx) and the response at time t is x.\nThe αtx and βtx parameters are independently estimated using only patients in their model instance, and may or not have identical priors αμ* and βμ* depending on the Model Priors selection in FACTS. A common non-informative prior for the πt0 and πt1 parameters is Beta(1,1).\n\n\n10.4.3 Logistic regression\nThe Logistic regression longitudinal model works similarly to the Beta Binomial imputation model. The difference is in the method of modeling the probability of a transition from an interim visit to the final visit Pr (Yi = 1|y*i**t*). Like the Beta Binomial model, the logistic regression model imputes a patient’s final endpoint given their most recent observed response.\nThe final endpoint response Yi is modeled as:\nYi ∼ Bernoulli(πtyit)\nwhere πtyit is the probability of a response at the final endpoint time given that its early observed endpoint at time t is y*i**t. Then, we define the parameter \\(\\theta\\_{ty\\_{it}} = logit\\left( \\pi\\_{ty\\_{it}} \\right) = \\log\\left( \\frac{\\pi\\_{ty\\_{it}}}{1 - \\pi\\_{ty\\_{it}}} \\right)\\). The priors on θt0 and θt*1 are:\nθt0 ∼ N(μ0, σ02)\nθt1 ∼ N(μ1, σ12)\nThe model computes the posterior distribution of θt0 and θt1 using all patients in arms belonging to the model instance that have observed endpoint values at time t and the final endpoint time T.\nThe priors on θt0 and θt1 may be shared across model instances and/or visits depending on the selection made in the Model Priors section of the FACTS Logistic regression Longitudinal model page.\nA possible starting place for non-informative priors in this model would be: μ = 0,  σ = 2. A weakly informative set of priors that an early response makes a final response more likely could be θt0 ∼ N(−.75, 1.252) and θt1 ∼ N(0.75, 1.252).\n\n\n10.4.4 Restricted Markov Model (Absorbing Markov Chain)\nThe Absorbing Markov Chain model assumes that at each visit a subject is in one of three states – responder (1), stable (S), or failure (0). The responder and failure states are absorbing, meaning that once a patient has entered one of those states they must remain in that state for the remainder of the visits. Patients in the stable state may move to a responder or a failure in subsequent visits.\nUnlike most other longitudinal models in FACTS, the Restricted Markov Model estimates the probability of a result at a visit based on the visit right before it, rather than predicting directly to the final endpoint from the early visit.\nPr (yit = n |yi, t − 1  = S) ∼ Dirichlet({α0t, α1t, αSt})   for t ≥ 2\nWhere n can be 0, 1, or S, denoting the probability of going to the Fail state, the Responder state, or the Stable state at visit t from the Stable state at visit t − 1. t must be greater than or equal to 2, because we do not impute the first visit – a subject missing visit 1 and all visits after does not contribute to the longitudinal model or dose response model.\nThe priors for the α parameters are specified in terms of the prior number of transitions from Stable at t − 1 to each different state at time t. For example, if the prior value for the parameter γ13 is 2, we are putting a priori information into the Dirichlet distribution suggesting that 2 patients transitioned from Stable at visit 2 to Responders at visit 3. Specified priors can either be common or different across model instances based on user specification.\nThe parameters defining the posterior distribution of the state probabilities are available in closed form as:\nα0t = γ0t + |y*i**t = 0, yi, t − 1 = S*|\nαSt = γSt + |y*i**t = S, yi, t − 1 = S*|\nα1t = γ1t + |y*i**t = 1, yi, t − 1 = S*|\nTo create a dichotomous endpoint, the user specifies in the Study > Study Info > Design Options section whether patients remaining in a stable state at the final visit should be dichotomized as responders or failures.\n\n\n10.4.5 Dichotomous Endpoint: Dichotomized Continuous Longitudinal Model\nThe user may select (on the study tab) to assume that the dichotomous final endpoint is generated by observed continuous longitudinal data and then dichotomizing the final endpoint. The user specifies the dichotomization thresholds and whether a response occurs for values above or below the threshold. If the user selects this option, then the user may select any of the continuous longitudinal models specified in the Continuous Longitudinal Models section above. The engine will impute incomplete subjects according to the continuous model, resulting in a continuous imputed final endpoint. The imputed dichotomous final endpoint is then simply the dichotomized version of the continuous imputation.\nAll priors and methods are identical to the continuous longitudinal models mentioned above.", + "objectID": "documentation/v71/userguides/crm.html#efficacy", + "href": "documentation/v71/userguides/crm.html#efficacy", + "title": "FACTS Dose Escalation CRM", + "section": "7.3 Efficacy", + "text": "7.3 Efficacy\nIf include efficacy has been checked on the Study Info tab, a simple additional input page is included:\n\n\n\n\n\n\nFigure 30: The Efficacy tab\n\n\n\nIf simulating and modelling an efficacy endpoint is included there are two items to be specified on this tab:\n\nWhether a subject experiencing a toxicity can also count towards efficacy or not. If unchecked patients outcomes are simply sampled separately and a patient can both have a toxicity and an efficacy response. If checked, a patient’s toxicity outcome is sampled first, and only if there is no toxicity is an efficacy outcome sampled.\nThe efficacy target – this consists of:\n\nThe target efficacy rate required for the Minimum Efficacy Dose (MED).\nWhether the target dose is the nearest dose to the MED rate, the lowest dose above the MED rate or the highest dose below the MED rate.\nIf a control arm has been included, whether the target rate is absolute or relative to the observed rate on the control arm.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#time-to-event-predictor-models", - "href": "documentation/v71/userguides/core.html#time-to-event-predictor-models", - "title": "FACTS Core User Guide", - "section": "10.5 Time-to-Event Predictor Models", - "text": "10.5 Time-to-Event Predictor Models\nFor all predictors (Z) for time to event endpoints, the engine estimates both a marginal distribution (normal mean and variance for continuous, probability of response for dichotomous, and a piecewise exponential hazard model for time to event predictors) and a working model relating the predictor to the final endpoint. The marginal distribution is used to impute predictors for subjects lacking an observed predictor value and may also be used for stopping (see section on stopping). The working model is used to impute final endpoints for subjects lacking a final endpoint. For subject missing both a predictor and final endpoint, the predictor is imputed first from its marginal distribution, and then the final endpoint is imputed conditionally on the predictor Z.\n\n10.5.0.1 Continuous Predictor\nWithin each dose (including control and active comparator), the marginal distribution of Z is a normal distribution with mean θZd and standard deviation σZ. The standard deviation is common across the doses, but the means θZd are allowed to vary across the same range of dose response models as the final endpoint (NDLM, Logistic, etc.). The prior specification for these predictor dose response models is identical in structure to the final endpoint, although the user selects a separate set of parameter values. The dose response for the predictor does not need to match the dose response for the final endpoint.\nThe working model assumes the final event time T is related to the predictor Z by assuming T|Z ∼ Exp(λde*βZ), where λd varies by dose and has separate priors λd ∼ Gamm**a(αd, βd) for each dose. The coefficient in the exponent β (no subscript) is constant across doses with prior β ∼ N(m, s*). \n\n\n10.5.0.2 Dichotomous Predictor\nA dichotomous predictor is handled similarly to a continuous predictor, with a marginal distribution having a predictor dose response model. However, in this case the predictor dose response relates the log-odds rather than the probability of response itself. The working model for dichotomous is identical to the working model for a continuous predictor, with T|Z ∼ Exp(λde*βZ). In this situation the working model is simpler to understand, as T|(Z = 0) ∼ Exp(λd) and T|(Z = 1) ∼ Ex**p(λdβ*)).\n\n\n10.5.0.3 Time to Event Predictor\nThe time to event predictor is qualitatively different than the continuous or dichotomous predictors. Instead of the predictor adjusting the hazard, the time to event predictor is viewed as an offset. The final endpoint is viewed as a sum of a predictor time Z1 and a post-predictor time Z2, where Z1 and Z2 are independent random variables and the final endpoint is thus Z1 + Z2.\nFor the working model, Z1 ∼ *PExp(λ1s * θ1d) and Z2 ∼ Exp(λ2d), with priors λ1s ∼ Gamma(α1s, β1s), λ2d ∼ Gamm**a(α2d, β2d) (with Z1’s control hazard model potentially being piecewise exponential). For imputation, a subject missing both the biomarker and final endpoint times has both Z1 and Z2 imputed, with the final endpoint imputed as the sum. For a subject with a predictor time but no final endpoint, Z*2 is imputed and added to the observed predictor time to impute the final endpoint.", + "objectID": "documentation/v71/userguides/crm.html#treatment-arms", + "href": "documentation/v71/userguides/crm.html#treatment-arms", + "title": "FACTS Dose Escalation CRM", + "section": "7.4 Treatment Arms", + "text": "7.4 Treatment Arms\nOn this tab the number of treatment arms (doses) available to the study is specified. The user can either define a set of specific doses that can be used or a continuous dose range with some granularity.\nSelecting Explicit Doses allows the user to specify the specific doses that can be used on the trial:\n\nA single new dose or multiple doses can be added either by clicking “Add” or “Generate”. Initially each dose is defined by a simple integer name and level. The dose levels and dose names can then be edited on by clicking on them and entering the desired value. The dose level can also be set later on in the Design > Toxicity Response tab.\nThere is also the option to include a control arm. Including a control arm allows the toxicity rate to be relative to the control arm.\n\n\n\n\n\n\n\nFigure 31: The Treatment Arms tab specifying explicit doses\n\n\n\n\n7.4.1 Finely Spaced Doses\nSelecting Finely Spaced Doses allows the user to specify the dose range that can be used on the trial:\n\nThe minimum and maximum dose strength to be used\nThe ‘granularity’ of the actual dose used, either as a fixed delta (Fixed spacing) or a dose ratio (the ratio specified must be greater than 1) (Ratio spacing).\nThe number of ‘bins’ or ‘doses for which to report’ – this is because FACTS will still produce summary statistics in columns, many with a “column per dose” – it is possible to use more doses than it is practical to report on (and a limit in MS Windows of 32K pixels for the width of a table means that the GUI can only display simulation results for a maximum of ~40 doses). However this limitation is only for reporting summary statistics; the dose strengths modeled and allocated in the simulations are unaffected.\n\nSelecting ‘Finely Spaced Doses’ will also affect how some of the other parameters are specified in the FACTS GUI.\n\n\n\n\n\n\nFigure 32: The Treatment Arms tab, specifying a finely spaced dose range", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#non-adaptive-designs", - "href": "documentation/v71/userguides/core.html#non-adaptive-designs", - "title": "FACTS Core User Guide", - "section": "11.1 Non-adaptive designs", - "text": "11.1 Non-adaptive designs\nIf the design is non-adaptive, then on this tab the user simply specifies the fixed allocation ratio to use between all the treatment arms for the duration of the study. The allocation is implemented using a blocking scheme – the block size is the sum of the allocation ratios entered and each arm is given the number of slots in the block corresponding to its allocation ratio. Consequently, the values entered must be integers.", + "objectID": "documentation/v71/userguides/crm.html#variants", + "href": "documentation/v71/userguides/crm.html#variants", + "title": "FACTS Dose Escalation CRM", + "section": "7.5 Variants", + "text": "7.5 Variants\nOn this tab the user can specify that a number of design variants should be created. Currently the only design feature that can be changed is the sample size (maximum number of cohorts).\nIf “multiple variants” is checked then the user can specify that simulations setups should be created for each simulation scenario with versions of the design with different maximum numbers of cohorts.\nThe user enters the number of variants they wish to create. Then in the resulting table, enter different “Max Cohorts” for each variant.\nThese will then appear on the simulations tab.\nIf open enrolment is being used, then the enrolment cap is specified by the number of subjects.\nIf there are two groups then separate caps are specified for each group.\n\n\n\n\n\n\nFigure 33: The Variants tab, specifying 5 variants", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#fixed-allocation", - "href": "documentation/v71/userguides/core.html#fixed-allocation", - "title": "FACTS Core User Guide", - "section": "11.2 Fixed Allocation", - "text": "11.2 Fixed Allocation\nIf allocation is to be fixed, then on this tab the fixed allocation ratios and block size are specified. For each arm in the study allocation ratios are entered as for fixed designs, and allocation uses a block size that is the sum of the ratios. Fixed allocation works identically to the non-adaptive design randomization. The difference is that this Fixed allocation can be performed concurrently with interim analyses being performed.", + "objectID": "documentation/v71/userguides/crm.html#explicitly-defined", + "href": "documentation/v71/userguides/crm.html#explicitly-defined", + "title": "FACTS Dose Escalation CRM", + "section": "8.1 Explicitly Defined", + "text": "8.1 Explicitly Defined\nToxicity profiles may be added, deleted, and renamed using the table and corresponding buttons on the left hand side of the screen in Figure 35. The user enters the toxicity rate to simulate at each dose into the Probability of Toxicity column of the table, and the graphical representation of these toxicity values updates accordingly.\nThis form of toxicity profile is not available if the dose range is “finely spaced” – typically this means there are too many doses for it to be practicable to enter toxicity rates for all of them. When using “finely spaced” doses the toxicity rates to be simulated have to be specified using parametric models (see the next section).\n\n\n\n\n\n\nFigure 34: Explicitly defined toxicity - binary endpoint\n\n\n\nIf the design is using ordinal toxicity, the toxicity response rates can be specified either:\n\nOn the “Toxicity” tab by specifying the category 3 or greater toxicity rate at each dose and then two offsets – one for the category 2 or greater rate and one for the category 4 rate.\nOn the “Ordinal Toxicity” tab by separately specifying the toxicity rates for each category of toxicity at each dose.\n\nSpecifying offsets: to ensure that the specified category 3 rate plus the category 2 offset doesn’t sum to more than 1, or the category 3 rate plus the -ve category 4 offset sum to less than 0, the offsets are applied to the logit of the category 3 toxicity rate.\nThus for the category 2+ rate:\n\\[\nln(\\frac{p_{2+}}{1-p_{2+}}) = ln(\\frac{p_{3}}{1-p_{3}} + \\Delta_2)\n\\]\nwhere:\n\n\\(p_{2+}\\) is the probability of observing a category 2 or greater toxicity at a dose\n\\(p_3\\) is the probability of observing a category 3 or greater toxicity at a dose\n\\(\\Delta_2\\) is the difference in the log odds between the two probabilities\n\nThe offset is defined at the lowest dose and highest dose and then varied linearly with dose strength at the intermediate doses. The plot of the curve can either use Pr(Tox) or Log-odds(Tox) as the y-axis and dose strength or log(dose strength) as the x-axis. A graph is displayed of the toxicity rates that have been entered, and the category 2+ and category 4 toxicity rates if applicable. This graph, as with all graphs in the application, may be copied to the clipboard or to a file using the “right-click” menu.\n\n\n\n\n\n\nFigure 35: Virtual Subject Response – Explicitly-Defined – ordinal endpoint\n\n\n\n\n8.1.1 Explicitly defined – Ordinal Toxicity\nIf simulating ordinal toxicity an alternative option is to explicitly specify the rate at each toxicity level at each dose. This can be done under the Virtual Subject Response > Explicitly Defined > Ordinal Toxicity tab.\n\n\n\n\n\n\nFigure 36: Virtual Subject Response – Explicitly-Defined: Ordinal Toxicity tab\n\n\n\n\n\n8.1.2 Explicitly defined toxicity – when simulating 2 groups\nIf simulating toxicity as a binary outcome, when simulating 2 groups, the tab displays two Pr(Tox) columns, one for each group, and the user enters the toxicity rate to be simulated at each dose for each group.\n\n\n\n\n\n\nFigure 37: Explicitly defined toxicity - 2 groups\n\n\n\nIf simulating 2 groups and ordinal toxicity, then on the explicitly defined tab once again the tab displays two Pr(Tox) columns, one for each group, and the user enters the toxicity rate to be simulated at each dose for each group. As for a single group the Category 2 toxicity and Category 4 (if using) toxicity rates are defined by defining log odds offsets at the lowest and highest dose. Specification is limited to a single set of offsets that are applied to both groups.\n\n\n\n\n\n\nFigure 38: Explicitly defined toxicity - 2 groups and ordinal offsets\n\n\n\nAs in the single group case in addition to the Category 3 toxicity rates that are editable, columns showing the Pr(Tox 2+) and Pr(Tox 4) are shown, but these are not editable and derived from the Pr(Tox) rates and the offsets that have been specified. The ordinal toxicity rates are only shown for group 1.\n\n\n8.1.3 Explicitly defined – Ordinal Toxicity with 2 groups\nIf simulating ordinal toxicity an alternative option is to explicitly specify the rate at each toxicity level at each dose. This can be done under the Virtual Subject Response > Explicitly Defined > Ordinal Toxicity tab.\n\n\n\n\n\n\nFigure 39: Explicitly Defined, Ordinal Toxicity with 2 Groups\n\n\n\n\n\n8.1.4 Efficacy response profiles\nEntering efficacy response profiles is very similar to entering toxicity profiles. FACTS will construct scenarios to simulate of every combination of toxicity and efficacy response profiles.\n\n\n8.1.5 Explicitly Defined – Efficacy\nEfficacy profiles may be added, deleted, and renamed just like toxicity profiles. The user enters the efficacy rate to simulate at each dose into the Probability of Efficacy column of the table, and the graphical representation of these efficacy values updates accordingly.\nAs with toxicity this form of efficacy profile is not available if the dose range is “finely spaced” – typically this means there are too many doses for it to be practicable to enter efficacy rates for all of them. When using “finely spaced” doses the efficacy rates to be simulated have to be specified using parametric models (see the next section).\n\n\n\n\n\n\nFigure 40: Efficacy virtual subject response, explicitly defined\n\n\n\n\n\n8.1.6 Explicitly Defined – Efficacy with two groups\nIf the design included 2 groups, when explicitly defining an efficacy response profile, there is simply a second column of efficacy response rates to enter:\n\n\n\n\n\n\nFigure 41: Explicity defined efficacy response profile with 2 groups", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#arm-dropping", - "href": "documentation/v71/userguides/core.html#arm-dropping", - "title": "FACTS Core User Guide", - "section": "11.3 Arm Dropping", - "text": "11.3 Arm Dropping\nAdaptive arm dropping trials allow accruing data to inform the adaptive design that an arm, or a set of arms, can be dropped, meaning they no longer have subjects randomized to them. FACTS Core supports designs in which some number of arms that are clearly ineffective can be dropped. Designs where at an interim one or more arms are selected to be continued and all other arms are dropped can be simulated using FACTS Staged Designs.\nFor each arm in the study, allocation ratios are entered as for fixed designs. There are options for specifying the arm dropping rules, evaluated at each interim:\n\nThe arm dropping criteria, the user may select any combination of Bayesian “Per Dose” QOIs: Posterior Probabilities or Predictive Probabilities, or a Target Dose QOI. For each criteria selected (at least one must be selected), the user supplies a direction of comparison and probability threshold. If at any interim, any arm meets the specified arm dropping criteria, then that arm becomes a candidate for dropping. After candidates are identified for dropping, the rest of the setup rules determine which, if any, of the candidates will be dropped.\n\n\n\nIn the “Setup” area a number of rules for arm dropping are specified:\n\nThe maximum number of arms that can be dropped – this can be set to from 0 to the number of active arms, the Control and Active Comparator are never dropped. This figure is the ‘maximum number of arms that can be dropped over the duration of the trial’. At any interim any number between 0 and the ’maximum number of arms can be dropped as long as this limit is not exceeded on the overall number of arms that would have been dropped.\n\n\n\nIf the maximum number of arms that can be dropped is set to the number of study drug arms, then if all arms are dropped this is recorded as an “early termination for futility”.\n\n\nArm dropping can be restricted to ‘pruning from the lowest dose’ and/or ‘pruning from the highest dose’. If ‘prune from the lowest dose’ is selected, then until the lowest dose meets the arm dropping criteria the second lowest dose cannot be dropped and so on. At an interim when the lowest dose does meet the arm dropping criteria, and the second dose does too, then the second dose can be dropped as well (and third and fourth …), it does not have to wait until the next interim.\nIf no pruning is selected or pruning from both ends is selected, then the user must select to prioritize the higher or lower dose to cover the instance when more doses are candidates for dropping than allowed by the maximum threshold. If “Prioritize dropping the lowest dose” is selected then when forced to choose between two or more doses to drop, the one with the lowest effective dose strength will be dropped.\n\n\nLastly the user specifies what is to be done with the unused subjects that would have been allocated to an arm that has been dropped. There are three options:\n\nMaintain study size, maintain combined block size of treatments: subjects that would have been allocated to arms that have been dropped are now randomized between all the remaining active treatment arms (excluding control and active comparator) using their original allocation ratios. For example, if the allocation ratio was 2:1:1:1 between Control and D1, D2 and D3, then after dropping D1 the block size remains size 5: 2 to Control and 1 to each of D2 and D3, with the 5th slot being allocated 1:1 between the remaining two study arms D2 & D3. Thus, the overall proportion of subjects on Control (and Active Comparator) is maintained.\nMaintain study size, reduce combined block size of treatments: subjects that would have been allocated to any arms that have been dropped are randomized between all remaining arms (including control) using a reduced total block size. Thus, if the allocation ratio was 2:1:1 between Control and D1 and D2, then after dropping D1 the block size drops to total size three: 2 to Control and 1 to D2.\nDecrease the study size, reduce combined block size of treatments: subjects that would have been allocated to any arms that have been dropped are no longer recruited and the total sample size of the study is reduced; the remaining subjects are recruited using a reduced block. If interims are specified by number of subjects recruited, these interim sizes are reduced proportionally. As an example of this, if an arm that gets 20% of the randomization is dropped when there are 100 subjects enrolled, then if the next interim is scheduled at 200 subjects enrolled, it will actually be performed at 180 subjects enrolled.", + "objectID": "documentation/v71/userguides/crm.html#sec-parametric", + "href": "documentation/v71/userguides/crm.html#sec-parametric", + "title": "FACTS Dose Escalation CRM", + "section": "8.2 Parametric", + "text": "8.2 Parametric\nToxicity scenarios may be added, deleted, and renamed using the table and corresponding buttons on the left hand side of the screen. The user selects the model to use to determine the toxicity rate to simulate at each dose, and specifies the values of the model’s parameters. The graphical representation of these toxicity values updates accordingly.\nThe graph may be copied using the context menu functionality described in the previous section.\nFour models are available:\n\nLogistic: the probability of toxicity at dose x is given by: \\(P_x=\\frac{1}{1+e^{-s(x-x_{50})}}\\) with user specified parameters, \\(s\\) (slope) and \\(x_{50}\\) (the ED50 dose). Note this can be fitted exactly by the two parameter logistic with linear effective doses \\(\\hat{x}=x-x_{ref}\\) when \\(\\beta=s\\) and \\(\\alpha=\\beta*(x_{ref}-x_{50})\\)\nEmax: the probability of toxicity at dose \\(x\\) is given by: \\(P_x=\\frac{x}{x+x_{50}}\\) with user specified parameter \\(x_{50}\\).\nLog Logistic: the probability of toxicity at dose \\(x\\) is given by: \\(P_x=\\frac{1}{1+e^{-s(ln(x)-ln(x_{50}))}}\\) with user specified parameters, \\(s\\) (slope) and \\(x_{50}\\) (the ED50 dose). Note this can be fitted exactly by the two parameter logistic with log effective doses \\(\\hat{x}=ln(\\frac{x}{x_{ref}})\\) when \\(\\beta=s\\) and \\(\\alpha=\\beta*ln(\\frac{x_{ref}}{x_{50}})\\)\nPiecewise linear: with the probability of toxicity specified at a series of knots, with the probability linearly interpolated between knots.\n\n\n\n\n\n\n\nFigure 42: Virtual Subject Response - Parametric Toxicity tab\n\n\n\nIf Ordinal toxicity is being simulated then the category 2 and greater toxicity rates and category 4 toxicity rates are specified using the logit offset methods as on the Explicitly-Defined > Toxicity tab.\n\n\n\n\n\n\nFigure 43: Virtual Subject Response - Parametric Toxicity tab with Ordinal toxicity\n\n\n\nIf Ordinal Toxicity and 2 groups are being simulated then both the Cat 2+ and Cat 4 toxicities and the Group 2 toxicities are defined using the logit offset methods.\n\n\n\n\n\n\nFigure 44: Parametric definition of ordinal toxicity response with 2 groups\n\n\n\n\n8.2.1 Parametric efficacy response\nParametric efficacy response profiles function exactly like toxicity profiles, with the same parametric models to choose from and if 2 groups are present the response of the second group is again defined by 2 log-odds offsets, one at the lowest dose and one at the highest.\n\n\n\n\n\n\nFigure 45: Parametric efficacy response profile", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#adaptive-allocation", - "href": "documentation/v71/userguides/core.html#adaptive-allocation", - "title": "FACTS Core User Guide", - "section": "11.4 Adaptive Allocation", - "text": "11.4 Adaptive Allocation\nIn adaptive allocation, the relative probabilities of assigning each of the doses to a subject may change throughout the trial. The adaptive allocation design that FACTS supports is one where the allocation ratio is modified at each interim to increase the allocation to doses that have the preferred characteristics.\nAn adaptive allocation design has two phases: the “burn-in” before any adaptation takes place and the “adaptive phase”. The burn-in lasts until the first interim occurs, and is defined on the Interims tab. The adaptive phase lasts until the early stopping criteria are met or the maximum sample size is reached.\nThe allocation of subjects in burn-in is specified by entering the allocation ratio to each arm for the burn-in period. Once the first interim is reached the allocation becomes adaptive.\n\nIt is possible to specify that specific treatment arms are not to be allocated to adaptively by specifying a fixed allocation for that arm.\nAdaptive and fixed allocation is combined within an overall blocking scheme, within which some slots are fixed and some are adaptive.\n\n\n\nThe arms to allocate to with a fixed probability are selected by clicking the “Fix Alloc” check box for that arm.\n\n\n\nThe overall block size is set by entering it in the ‘Block size’ field.\nThe number of ‘slots’ in the block to be given to the fixed arms are set by entering the number on the “Post Burn-in Alloc per Block” cell for the fixed arms.\nThe non-fixed arms will be allocated to adaptively and probabilistically in the slots not taken by the fixed allocation (so the Block size must exceed the number of fixed slots being used!)\n\nCommonly, the control arm and active comparator arms are allocated to in this way and the treatment arms are left to be allocated to adaptively. If the Control arm is not given a fixed allocation, it is allocated to with an adaptive probability that is an equal weight to the treatment arm with the highest weight.\nThere are options for specifying the adaptive allocation, evaluated at each interim:\n\n“Probability set to zero for values less than:” - specifies an allocation probability threshold, which if an arms probability of allocation falls below this value then it is set to 0 and the remaining allocation probabilities re-normalized.\nIn the “Adaptive Allocation Weights” the user selects which QOI to use to determine the adaptive allocation, and what relative weight to give them. The user also selects for each target whether the weight to use should be “probability” that the dose is the target or the “information” allocating to the dose would give about the target.\n\n\nAny Bayesian “Per Dose” QOI, or “Target Dose” QOI can be used to determine the adaptive allocation weights. In addition there is the option to use a static weighting – this is of course not adaptive! What it does do is allow an adaptive allocation to be combined with a “guaranteed minimum allocation” (see example discussion below). If a Static target is included, a small table is displayed the specification of the ratio of the division of the static weight between the study arms that are being adaptively allocated to.\n\n\nWhen weighting for probability, the weight is derived simply from the value of the QOI.\nWhen weighting for information, the weight uses the value of the QOI but adjusted by the current variance of the estimate and the number of subjects already allocated to the dose – an estimate of the additional information that would result from adding one more subject to that arm.\nWeighting for probability is ‘more aggressive’ in adapting in pursuit of the target. The risk with a probability-based weighting is never allocating again to an arm where the initial data is so poor that its initial probability of being the target is so low it is never allocated to again. So, it is appropriate when the available sample size is small (and risks must be taken), the number of study arms is small (so it is unlikely an arm will not be allocated to again), or the allocation during the burn-in is large and evenly distributed (so that having unrepresentative data is very unlikely).\nWeighing for information will tend to spread the allocation around the most likely target, reducing the risk of never learning that dose is better than its initial data. If a dose response model is being used, allocation to doses around the target dose will contribute to the accuracy of the estimate of response on the target dose, but compared to the probability weighting will tend to result in fewer subjects allocated to the actual target dose.\nWhichever weighing rule is selected the adaptation can be further ‘sharpened’ or ‘softened’ by adjusting the power to which the allocation probability is raised. Setting the power to 0.5 will significantly soften the allocation, setting it to 2 will significantly sharpen it.\n\n\n\n11.4.1 Weighting and Calculation of Adaptive Allocation Probabilities\nFor a QOI Pi, d that is specified as an Adaptive Allocation Target, if probability weighting is selected, the allocation target for dose d is:\nVd, i* = [Pd, i]γ\nwhere γ is the allocation probability power.\nIf information weighting is selected, then the allocation target for Pi, d is:\n\\[V\\_{d,i}^{\\*} = \\left\\lbrack \\sqrt{\\frac{P\\_{d,i}Var\\left( \\theta\\_{d} \\right)}{n\\_{d} + 1}} \\right\\rbrack^{\\gamma}\\]\nwhere γ is the allocation probability power, nd is the number of subjects on dose d, and θd is the dose-response model mean estimate for arm d.\nIf there are multiple allocation targets used for an adaptive randomization, then these allocation targets are combined to create a single allocation weight Wd. The allocation weight for a dose is the weighted average of the allocation targets for the dose.\n\\[W\\_{d} = \\sum\\_{i = 1}^{I}{w\\_{i}V\\_{d,i}}\\]\nwhere I is the number of allocation targets, wi is the weight of allocation target i, and Vd, i is the value of the allocation target for dose d on target i.\nIf there is only 1 allocation target, then the allocation weight Wd = Vd, 1.\nFinally, for the doses which are adaptively allocated (not fixed or within their burn-in period), these allocation weights are renormalized to sum to the probability remaining after all fixed doses have been allocated.\n\n11.4.1.1 Non-fixed Control Adaptive Allocation\nIf the control allocation ratio is not fixed when performing adaptive allocation, then the control arm gets a randomization ratio that targets matching the number of control subjects to the active arm with the most subjects.\nTo derive the control allocation rate, let Vd for d = 1, 2, …D be the allocation probabilities for each of the D non-control dose arms (these may be obtained by calculating based on the probability or information criteria as described above or the fixed allocation proportion with respect to the block size), and let nd for d = 1, 2, …D be the number of subjects allocated to those arms.\nThen, the allocation to the control arm V0 is:\n\\[V\\_{0} = \\min\\left\\\\ \\sum\\_{d = 1}^{D}{V\\_{d}\\frac{(n\\_{d} + 1)}{(n\\_{0} + 1)},\\\\\\\\max\\\\ V\\_{1},V\\_{2},\\ldots,\\\\V\\_{D}\\\\} \\right\\\\\\]\nFollowing fixing this control rate, the allocation probabilities for the non-fixed doses are renormalized to add up to the total non-fixed probability.\n\n\n11.4.1.2 Zero Out Allocation Probabilities\nIf, at the end of the adaptive allocation probability calculation, any adaptively allocated arms have a randomization probability smaller than the value provided for “Allocation probability set to zero for values less than:”, then the allocation probabilities are adjusted.\nTo adjust the probabilities, first the arm with the smallest randomization probability is given a fixed allocation rate of 0. Then, the remaining adaptively allocated arms have their allocation probabilities re-normalized to sum to the probability remaining after all fixed doses have been allocated. Then, if any doses remain below the zero-out threshold, then this process is repeated. Continue the repetition as necessary. If none of the allocation probabilities are below the threshold, then the allocation probabilities are set.\n\n\n\n11.4.2 Adaptive Allocation Calculation Examples\n\n11.4.2.1 Simple Response Adaptive Randomization Example\nSuppose you have a control and 3 active doses. The control arm is guaranteed 2/6 slots in every block and a fixed 20% probability must be placed on the first active dose (dose A). So, the control arm gets 33.3% of the total allocation probability and dose A gets 20% of the total allocation. Suppose the target QOIs Vd for the three active doses are 0.20, 0.50, and 0.30 and that we’re using probability weighting with weight 1. The second two doses are the only doses with unknown randomization probabilities, so they split the amount of non-fixed allocation probability proportionally based on their Vd.\nThe allocation probability of the second active dose is \\(\\left( 1 - (0.333 + 0.2) \\right)\\*\\left( \\frac{0.5}{0.5 + 0.3} \\right)\\) and the allocation probability of the third active dose is \\(\\left( 1 - (0.333 + 0.2) \\right)\\*\\left( \\frac{0.3}{0.5 + 0.3} \\right)\\).\nThus, the final allocation probabilities for the control and the three active doses are: (0.333, 0.2, 0.292, 0.175).\nIf any of the adaptively allocated probabilities are less than a user specified minimum (“Allocation probability set to zero for values less than….” in the GUI) then these probabilities would be set to zero and the resulting probability is reallocated among the non-fixed probability doses. If all non-fixed doses drop at this point, then the probability is reallocated to the fixed doses.\n\n\n11.4.2.2 Using Static Weighting Example: Ensuring a minimum allocation to all arms\nAs an example of using the static weight to allow adaptive randomization along with a guaranteed minimum allocation of 10% to each of 5 study arms. Let us say that we want the adaptive allocation to be evenly divided between targeting an EDq and MED target.\nAs there are 5 study arms, allocating 10% each amounts to 50% of the total. Thus we could specify weights of 1 to the MED target, 1 to the EDq target, and 2 to the Static target, so the Static target gets 50% of the total weighting.\nHowever, this ignores the possible allocation to a Control arm. What we have achieved above either allocates 10% to each study arm if there is no Control arm, or if there is a Control arm, allocates 10% of the subjects allocated to the study arms, not 10% of the overall.\nLet us say that in addition to the 5 study arms you have a Control that we want to have 20% allocation and we want each study arm to have at least 10% of the overall allocation. The simplest way to specify this is to set a “Post first interim block size” of 10 and that 2 slots are allocated to Control.\nThis leave 8 slots to be allocated across the treatment arms, to ensure a 10% allocation for each of the 5 treatment arms - that takes up 5 more slots in the block – but we don’t want to allocate 1 in the block to each using fixed allocation – because then that’s all they would get. We need to allow them to be allocated to adaptively and use the Static target to ensure they get a minimum of 10%. We can achieve this by giving the static allocation a weight of 5 and divide a weight of 3 between the MED and EDq targets, so they get a weight of 1.5 each.\n\n\n11.4.2.3 Using Static Weighting Example: Ensuring a minimum allocation to top dose\nImagine an early Phase II Proof-of-Concept study that wants to compare 3 doses of the study drug (low, medium and high) to Control, and adaptively allocate to the dose with the maximum response. The study team also wish to ensure a minimum allocation to the top dose as they have a strong prior that it will have the maximum effect. They want to minimize the risk that the adaptive allocation avoids the top dose because of randomly poor results on that dose early on in the trial.\nSolution 1 uses a fixed allocation to Control of 30%. The optimal allocation to control in a multi armed study is approximately √N:1:1:… where N is the number of study arms [Dunnett] and in √3:1:1:1 the proportion on control would be 37%. Here we’ve rounded down to 30% rather than up to 40% to reflect a typical clinical teams desire to get more data on their study drug rather than Control.\nAfter the first Interim, we specify allocation to be in blocks of 10 with the Control allocate 3 slots in each block, the weight on the Static target is 2 and the Weight on the Pr(Max) target is 5. So 50% of the allocation is adaptive targeting the dose with the Maximum response and 20% is fixed and allocated to the top dose by specifying that the static weighting is split 0:0:1.\n\nSolution 2 uses adaptive allocation to Control. Adaptive allocation to Control allocates to control with the same weight as the adaptive allocated arm with the highest weight. Under this scheme the top dose will receive its minimum allocation when there is an arm with close to 100% Pr(Max). If that arm is the top dose, then allocation will be close to 50% to Control and 50% to the top dose, so the 20% minimum allocation requirement is met. If it is a different arm with close to 100% Pr(Max) then, if the allocation to top dose is t and the allocation to Pr(Max) 100 - t, the allocation ratio is (100 – t) : (100 – t) : t, (Control : Best Dose : Top Dose).\nThe total allocation is (200 – t) and we want to select t so that t/(200 – t) ≅ 0.2. So t = 33.3. With the static weight allocated 0:0:1.", + "objectID": "documentation/v71/userguides/crm.html#external", + "href": "documentation/v71/userguides/crm.html#external", + "title": "FACTS Dose Escalation CRM", + "section": "8.3 External", + "text": "8.3 External\nSubject response data may be simulated from a PK-PD model in place of, or in addition to, choosing a response model from FACTS. The importing of subject response data (which must be in the form specified in the System Requirements Document) may be done from the External Files sub-tab depicted below (Figure 46).\nThe supplied data should be in the following format: an ascii file with data in comma separated value format with the following columns:\n\nPatient id\nDose index (1, 2, 3,… if a Control is to be included it should be index 0) this is not the user settable dose name or dose level\nToxicity (0,1)\nEfficacy (0. 1) even if efficacy not being simulated this value must be present\nGroup (*1, 2) only required if groups are being simulated\n\nThe GUI requires that the file name has a “.dat” suffix.\nSimulated subjects will be drawn from this supplied list, with replacement, to provide the simulated response values.\nTo import an external file, the user must first add a scenario to the table. After adding a scenario, the user must click “Browse” to locate the externally simulated data via a standard file browser dialog.\n\n\n\n\n\n\nFigure 46: External Data", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#deterministic-allocation", - "href": "documentation/v71/userguides/core.html#deterministic-allocation", - "title": "FACTS Core User Guide", - "section": "11.5 Deterministic Allocation", - "text": "11.5 Deterministic Allocation\nThe deterministic allocation option allows for the treatment assignments of subjects accrued into the simulated trials to be assigned without randomness based on an uploaded file. The file providing the assignments should be a comma separated .dat file with 2 columns, but no column labels.\nThe first column should be an increasing, unique column of numbers from 1 to at least the maximum number of subjects that can be enrolled in the study. The second column should be the set of treatment assignments in order from 1 to the number of patient IDs. The treatment assignments are used in row order – they do not use the subject ID order. So, the first subject accrued in the study is given the assignment indicated by the first row, second column value, the second subject accrued in the study is given the assignment indicated by the second row, second column value, and so on.\nThe treatment assignments column in the .dat file should always have a minimum value of 1 and a maximum of the number of total arms in the study. If there is a control arm in the study, then treatment assignment 1 corresponds to a control arm randomization. If there is no control arm in the study, then treatment assignment 1 in the .dat file corresponds to a subject randomized to the lowest active dose.", + "objectID": "documentation/v71/userguides/crm.html#x-hats", + "href": "documentation/v71/userguides/crm.html#x-hats", + "title": "FACTS Dose Escalation CRM", + "section": "9.1 X-Hats", + "text": "9.1 X-Hats\nOn this tab the user specifies the reference dose \\(d^*\\) for use in calculating the adjusted dose value (the “x-hat” values). The default value to use is Median dose is reference, this uses the median of the dose range for the reference dose, minimizing the correlation in the sampled values of \\(\\alpha\\) and \\(\\beta\\). Note though that when allocation is restricted to explicit doses it is also recommended that the value of the reference dose is not the same as an actual dose that can be used (at this dose \\(\\hat{x}\\) will be 0 and the data on this dose can have undue weight on the estimate of \\(\\alpha\\)).\nDifferent reference doses can easily be used however – between the two doses thought most likely to be MTD, just below the lowest dose, just above the highest dose. The bi-variate Normal prior for \\((\\alpha, ln(\\beta))\\) will need to be recalibrated to take the change into account.\nX-Hats are log(dose strength) allows the user to select between:\n\nlinear effective dose \\(\\hat{x}_j = d_j - d^*\\)\n\\(log(\\hat{x}_j) = ln(\\frac{d_j}{d^*})\\)\n\nIf you have entered linear dose strengths for the doses (1, 2, 3, 4, … or 100, 150, 200, 250, …) then use the linear effective dose. If however the dose strengths that have been entered are non-linear (12.5, 25, 50, 100, …) but expected to be roughly linear in effect, then use the log of the dose ratio.\n\n\n\n\n\n\nFigure 47: Specifying the dose transformation - the “x-hats”.\n\n\n\n\n9.1.1 The Pro’s & Con’s of using the median dose as the reference dose\nThe reason the median dose is recommended as the reference is that this minimizes the correlation in the fit of \\(\\alpha\\) and \\(ln(\\beta)\\), the parameters of the BLRM, and it maximises the flexibility of the fit of the model over the dose range.\nHowever care needs to be taken that the prior on \\(\\alpha\\) is not more restrictive than that on \\(ln(\\beta)\\) in order to avoid a phenomena observed when preparing tutorials: observing “no toxicities” below the reference dose resulted in a model with increased probability of toxicity above the reference dose compared to observing a toxicity below the reference dose. For a given value of \\(\\alpha\\), higher values of \\(ln(\\beta)\\) correspond to lower toxicity below the reference dose – as the \\(\\hat{x}\\)̂ values are -ve below the reference dose. The fitted curve thus “pivots” about the value of \\(\\alpha\\) at the reference dose.\nThere are two solutions to this:\n\nmove the reference dose, which involves a choice between two options\n\nmoving it to the first dose or below (normally allowing a relatively constrained prior around a low value for \\(\\alpha\\)),\nor to the highest dose or above (with a relatively uninformative prior).\n\nWe have seen both solutions perform well against the chosen scenarios – but the choice needs checking and refining with a full range of scenarios that represent the full uncertainty in the true response.\nor modify the priors on \\(\\alpha\\) and \\(ln(\\beta)\\) making the prior on \\(\\alpha\\) less informative (in particular increase the probability of low values) and make the prior on \\(ln(\\beta)\\) more informative (in particular lower the probability of high values less). Because the prior distribution on \\(\\beta\\), is on \\(ln(\\beta)\\), it is easy to make large values of \\(\\beta\\) more probable than intended.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#cohort-recruitment-fixed-allocation", - "href": "documentation/v71/userguides/core.html#cohort-recruitment-fixed-allocation", - "title": "FACTS Core User Guide", - "section": "11.6 Cohort recruitment – fixed allocation", - "text": "11.6 Cohort recruitment – fixed allocation\nIf allocation is to be fixed the “Early Stopping Only” option should be selected. Then on this tab the fixed allocation ratios and block size are specified – for the first cohort and then for all subsequent cohorts. In each case the user specifies the number of each arm to allocate in each cohort and the sum must equal the size of the cohort.", + "objectID": "documentation/v71/userguides/crm.html#toxicity-response", + "href": "documentation/v71/userguides/crm.html#toxicity-response", + "title": "FACTS Dose Escalation CRM", + "section": "9.2 Toxicity Response", + "text": "9.2 Toxicity Response\nThe parameters that can be specified on this page are:\n\nThe parameters of the bivariate Normal distribution for \\(\\alpha\\) and \\(ln(\\beta)\\). Specifying the mean and standard deviation of \\(\\alpha\\) \\((\\mu_{\\alpha}, \\sigma_{\\alpha})\\), and \\(ln(\\beta)\\) \\((\\mu_{ln(\\beta)},\\sigma_{ln(\\beta)})\\) and the correlation coefficient \\(\\rho\\).\n\nIf ordinal toxicity is being simulated, it is possible to model the ordinal toxicity, specifying the mean and standard deviation of \\(\\alpha_2\\) and \\(\\alpha_4\\). These priors are separate from the \\(\\alpha_3\\) and \\(ln(\\beta)\\) prior, there is no correlation term in the prior. There is the constraint in the model that \\(\\alpha_2 > \\alpha_3 > \\alpha_4\\).\nUse fixed Alpha: the value of Alpha can be fixed to allow the N-CRM model to behave like the traditional CRM models. [Where \\(\\alpha\\) was set to 3 and the reference dose is set above the top of the available dose range]\n\n\nRather than entering the priors directly, they can be derived based on indirect prior information or beliefs, see ‘Deriving the Prior’ below.\n\nThe Minimum and Maximum rates that the model is to be fitted too. The model fits the range \\((0,1)\\), asymptotically approaching each limit as the adjusted dose value tends to \\(-\\infty\\) or \\(+\\infty\\). By specifying an alternative minimum and maximum, inside the range \\((0,1)\\), the user can have the model scaled to fit data to fit event rates where the asymptotic rates are not \\(0\\) or \\(1\\). For instance if the event being observed has a non-zero background rate (probability of being observed in placebo treated subjects), then the model may fit better if the minimum is set to the lower limit of this expected rate. Similarly if, even at the most toxic dose the event being observed is only expected to effect a proportion of subjects, the model may fit better if the maximum is set to the upper limit of this expected rate.\nIf a control arm is present, the user can specify to have this modelled separately, and if so the user specifies the parameters for a prior Beta distribution – in terms of numbers of prior observations on control of subjects with and without a toxicity.\nGroup 2 priors: if a second ‘Group’ is being simulated – whether this is a subset of subjects, or a modified treatment that subjects can be randomized to, then the BLRM is jointly fitted to the responses for both groups, with group 2 having offsets \\(a\\) and \\(b\\) from the first group’s \\(\\alpha\\) and \\(\\beta\\). The priors for \\(a\\) and \\(b\\) can be full bivariate Normal or can use constraints such as \\(b = 1\\), or \\(a > 0\\) or \\(a < 0\\).\n\n\n\n\n\n\n\nFigure 48\n\n\n\n\n9.2.1 Deriving the prior\nThe priors of \\(\\alpha\\) and \\(ln(\\beta)\\), can be specified directly or derived in one of four ways. When entered explicitly, the user specifies the parameters of the prior bivariate-normal distribution for \\(\\alpha\\) and \\(ln(\\beta)\\): the means, standard deviations and the correlation term \\(\\rho\\).\nAlternatively, the user may click the ‘derive prior’ button and select from:\n\nQuantiles at the lowest and highest dose: (based on the “uninformative prior” given in the paper (Neuenschwander, Branson, and Gsponer 2008), for details see this section) - the user specifies the probability of an unacceptable toxicity at the lowest dose, and the probability of under-dosing at the highest dose (0.1 for both is the default, and 0.05 for both is the value used in the paper). Optionally the probability that toxicity is less than the mid-point of the target toxicity band at the median dose can be specified. (Prior to FACTS 6.5 this third data point was not optional and constrained to be at the reference dose, but this had problems if the reference dose was not the media dose – it might also be the lowest dose for example).\nNote this method does not work so well if the reference dose is outside the dose range.\n\n\n\n\n\n\nFigure 49\n\n\n\nScenarios: the model is fitted to each of the toxicity response scenarios (MLE), the parameters of the bivariate normal are then calculated from resulting set of pairs of values for \\(\\alpha\\) and \\(ln(\\beta)\\).\n\n\n\n\n\n\nFigure 50\n\n\n\nSpecific quantiles: The user selects which doses and toxicity rates to provide an expectation – a prior probability that the toxicity rate on the dose will be the specified rate or less. At least 3 such expectations using at least 2 different doses strengths must be supplied. If a large number of specific quantiles are specified (e.g. reproducing the all quantiles method) the large number of different beta distributions sampled from, with the monotonicity constraint applied, results in losing too much variability. So this should only be used quantiles specified at 2-4 doses.\n\n\n\n\n\n\n\nFigure 51\n\n\n\n\nAll quantiles: the user specifies the prior expected toxicity rate at the 2.5%, 50% and 97% quantiles for each dose. (Only available when using explicitly defined doses, not a continuous dose range). Note that using Create Prior with this option will require the facts file to be saved and for there to be at least one virtual subject response profile.\n\n\n\n\n\n\n\nFigure 52\n\n\n\nIn all cases once prior values have been derived they are displayed along with a graph of 100 sampled curves from the prior. The user can accept the values, change derivation method, or cancel the derivation.\nThe plot of the samples can either be viewed as Pr(Tox) or Log-odds(Tox) vs relative dose (“x-hat”).\n\n\n9.2.2 Derivation of the Prior from Quantiles\nDerivation of the parameters of the bivariate Normal prior for \\(\\alpha\\) and \\(ln(\\beta)\\)) in the Quantiles at lowest and highest dose, Specific quantiles and All quantiles cases:\n\nMinimally informative unimodal Beta distributions are fitted for each of the doses where a prior expectation of a toxicity has been specified. For doses where no prior expectation has been specified, the median expected toxicity rate are derived by assuming that the median expected toxicity is linear in log dose on the logit scale, and again a minimally informative unimodal Beta distribution is fitted with the same median.\nPreviously and following (Neuenschwander, Branson, and Gsponer 2008), the parameters of the bivariate Normal distribution were found using a stochastic fit to the prior expectations of toxicity, minimizing the error in the prior toxicity rates at the 2.5%, 50% and 97.5% quantiles. This is still used in the All quantiles and Legacy prior cases. However experience with this method with the standard priors (previously called “uninformative”) showed that it yielded priors with too little uncertainty in the \\(ln(\\beta)\\)) and too high a value for the correlation parameter for many cases and certainly for the prior to be called “uninformative”.\nConsequently, in the Quantiles at lowest and highest dose and Specific quantiles cases, the prior is now derived by sampling from the minimally informative unimodal Beta distributions, and fitting the model to each set of sampled toxicity rates. The parameters of the bivariate normal are then calculated from resulting set of pairs of values for \\(\\alpha\\) and \\(ln(\\beta)\\).\n\nIf a control arm has been included, it may be included in the model, or modelled separately using a beta-binomial model, the user specifies the prior values for the Beta distribution.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Dose Escalation CRM" ] }, { - "objectID": "documentation/v71/userguides/core.html#cohort-recruitment-adaptive-allocation", - "href": "documentation/v71/userguides/core.html#cohort-recruitment-adaptive-allocation", - "title": "FACTS Core User Guide", - "section": "11.7 Cohort recruitment – adaptive allocation", - "text": "11.7 Cohort recruitment – adaptive allocation\nIf allocation is to be adaptive the “Adaptive Allocation” option should be selected and then under “Subsequent Cohort Allocation” the “Allocate cohort by sampling from allocation vector” should be selected. Then on this tab\n\nThe fixed allocation ratios and block size are specified for the first cohort. The user specifies the number of each arm to allocate and the sum must equal the size of the cohort.\nThe user then specifies\n\nThe fixed allocation to control\nThe QOIs to be used to calculate the allocation ratios for the remaining subjects in the cohort as for adaptive allocation (see Adaptive Allocation above).", + "objectID": "documentation/v71/userguides/installation.html", + "href": "documentation/v71/userguides/installation.html", + "title": "FACTS Installation Guide", + "section": "", + "text": "This document describes how to install and verify the installation of the FACTSTM (Fixed and Adaptive Clinical Trial Simulator) software. It is intended for anyone concerned with the installation of the system.\n\n\n\nThis document covers the installation and installation verification FACTS. It is only intended to demonstrate the usage of the software to the extent that it verifies the software will execute properly in the installed environment.\nFor parameter meanings or detail into the internal workings of the design engines or algorithm check the appropriate System Requirements Document. For appropriate guidance on usage check the User Guides.\n\n\n\nThis document is a guide to the FACTS installation, including both the desktop application and the grid components.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#cohort-recruitment-allocate-to-best-dose", - "href": "documentation/v71/userguides/core.html#cohort-recruitment-allocate-to-best-dose", - "title": "FACTS Core User Guide", - "section": "11.8 Cohort recruitment – allocate to best dose", - "text": "11.8 Cohort recruitment – allocate to best dose\nIf allocation is to be adaptive, but at each cohort just Control and the “best dose” are to be allocated to, the “Adaptive Allocation” option should be selected and then under “Subsequent Cohort Allocation” the “Allocate cohort to single treatment (plus control)” should be selected. Then on this tab\n\nThe fixed allocation ratios and block size are specified for the first cohort. The user specifies the number of each arm to allocate and the sum must equal the size of the cohort.\nThe user then specifies\n\nThe fixed allocation to control\nThe QOIs to be used to calculate the allocation weighting to calculate for the non-Control arms, (see Adaptive Allocation above) and all the subjects not allocated to control will be allocated to this arm.", + "objectID": "documentation/v71/userguides/installation.html#purpose-of-this-document", + "href": "documentation/v71/userguides/installation.html#purpose-of-this-document", + "title": "FACTS Installation Guide", + "section": "", + "text": "This document describes how to install and verify the installation of the FACTSTM (Fixed and Adaptive Clinical Trial Simulator) software. It is intended for anyone concerned with the installation of the system.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#continuous-and-dichotomous-endpoints", - "href": "documentation/v71/userguides/core.html#continuous-and-dichotomous-endpoints", - "title": "FACTS Core User Guide", - "section": "12.1 Continuous and Dichotomous Endpoints", - "text": "12.1 Continuous and Dichotomous Endpoints\nInformation can be defined in terms of:\n\nnumber of subjects that have been recruited\nthe number of subjects who have actually completed a specified visit\nthe number of subjects who have had the opportunity to complete a specified visit (includes drop-outs)\ninterims can be by time with the first interim defined by information and time thereafter, or each information can be defined by the amount of information required to trigger the interim..\n\n \nIf defining interims by time, these are defined by frequency (number of weeks between interim) – fractions of weeks can be used for very frequent interims! The first interim is defined in terms of an information threshold, with the type of information selected above.\nIf the accrual completes before the first interim threshold is reached, and the first interim was defined in terms of the number of subjects enrolled, then the interims by time start at full accrual. If the first interim is defined in any other terms (by events, subjects complete or subjects with opportunity to complete) then interims only start when this is reached (which might be never).\nIf defiing interims by information, then each interim is defined individually, by number of patients/observations and iif information is interms of completers, then the week of the visit that is being used to define “complete”. Successive interims must be in terms of the same or more observations at the same or later visit and at least one needs to be “more” or “later”.\nIf interims are governed by time, completers or events there is the option as to whether interims should continue after full accrual, or discontinue.", + "objectID": "documentation/v71/userguides/installation.html#scope-of-this-document", + "href": "documentation/v71/userguides/installation.html#scope-of-this-document", + "title": "FACTS Installation Guide", + "section": "", + "text": "This document covers the installation and installation verification FACTS. It is only intended to demonstrate the usage of the software to the extent that it verifies the software will execute properly in the installed environment.\nFor parameter meanings or detail into the internal workings of the design engines or algorithm check the appropriate System Requirements Document. For appropriate guidance on usage check the User Guides.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#time-to-event-endpoint", - "href": "documentation/v71/userguides/core.html#time-to-event-endpoint", - "title": "FACTS Core User Guide", - "section": "12.2 Time-to-Event Endpoint", - "text": "12.2 Time-to-Event Endpoint\nInformation can be defined in terms of:\n\nnumber of subjects that have been recruited\nthe number of subjects who have observed their predictor endpoint\nthe number of subjects who have had the opportunity to observe their predictor endpoint (includes drop-outs)\nspecified numbers of events have observed (time to event trials only). With early stopping only, or arm dropping designs, the occurrence of the first interim is also specified, with an adaptive allocation design, the first interim is at the end of the burn-in.", + "objectID": "documentation/v71/userguides/installation.html#context-of-this-issue", + "href": "documentation/v71/userguides/installation.html#context-of-this-issue", + "title": "FACTS Installation Guide", + "section": "", + "text": "This document is a guide to the FACTS installation, including both the desktop application and the grid components.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#follow-up", - "href": "documentation/v71/userguides/core.html#follow-up", - "title": "FACTS Core User Guide", - "section": "12.3 Follow-up", - "text": "12.3 Follow-up\nRegardless of endpoint, the Interims tab contains options that control the behaviour should a trial stop at an interim. The option allows the user to specify whether or not to complete the follow-up of subjects who have been accrued, but have not had time to observe their final endpoint.\nThe default options available for Subject Follow-Up are:\n\nContinue follow-up if study stopped for success\n\n\n\nContinue follow-up if study stopped for futility\n\nIf the check box corresponding to an interim decision is checked, then at the time of an interim analysis decision accrual will be stopped, all subjects currently enrolled will be followed-up until they have had the opportunity to observe their final endpoint, and then the final analysis will be performed.\nIf the check box corresponding to an interim decision is not checked, then at the time of an interim analysis decision accrual is stopped, the data is locked, and no follow-up on randomized patients is collected. The interim dataset is the final dataset. The final analysis is then performed using the same data and model as was used for the interim analysis.\n\nIf the allocation method is selected as, “Arm Dropping” then an additional check box is provided in the Subject Follow-up Options box asking whether the user would like to “Continue follow-up if arm dropped.” If the box is checked, then subjects randomized to an arm that is dropped before they have the opportunity to complete their follow-up will have to opportunity to observe their final endpoint for subsequent analyses. If the box is not checked then incomplete subjects on an arm that is dropped will never have future endpoint values observed.", + "objectID": "documentation/v71/userguides/installation.html#desktop-requirements", + "href": "documentation/v71/userguides/installation.html#desktop-requirements", + "title": "FACTS Installation Guide", + "section": "3.1 Desktop Requirements", + "text": "3.1 Desktop Requirements\nFACTS can be run on a standard system laptop or desktop running Windows 10 or 11 with the Windows .NET framework v4 or higher installed and at least 1 GB per core or more memory.\nIn addition:\n\nFACTS is expected to run on a display with a resolution of at least 1024x768 pixels and preferably greater.\n\nUser choice of non-default Windows styles/themes may result in unexpected and impractical foreground and background color combinations.\nFACTS 7.0 targets .NET Framework 4.8. Future versions of FACTS will target the latest available .NET Framework version.\nFACTS is now a 64-bit application and will be installed on the target machine’s Program Files area. Previous to FACTS 6.4 versions of FACTS were 32-bit applications installed on the target machine’s Program Files (x86) area.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#interim-analysis-criteria", - "href": "documentation/v71/userguides/core.html#interim-analysis-criteria", - "title": "FACTS Core User Guide", - "section": "13.1 Interim Analysis Criteria", - "text": "13.1 Interim Analysis Criteria\nOn the success/futility criteria page the user can specify rules for judging the study for futility or success at an interim and at the final evaluation. If the trial has no interims there will be just a tab for the Final Evaluation criteria. If the trial has interim analyses, then there can be tabs that define different early success/futility criteria at the different interims.\nAt the top of the main tab is a control to allow tabs to be created for different interims. In a newly created adaptive design, FACTS will create a tab for interim 1.\nIf early success/futility criteria are specified for an interim, then they will be taken to apply to all subsequent interims until the next one for which criteria are supplied, then those criteria will apply until the next interim for which criteria are applied and so on.\nNote:\n\nEarly stopping for success/futility only occurs at interims.\nThere will be no stopping for success or futility until the first interim for which early stopping criteria have been defined.\nIt is left to the user to ensure that the early stopping criteria at any interim are mutually exclusive and it is not possible to stop for both success and futility at the same time. The FACTS design engines will stop the trial but the user should not rely on one or other outcome taking precedence. It is not considered good practice to have success and futility rules that could both be true, so FACTS does not guarantee a “tie break” rule.\nIn the output files there are columns labeled “Success <QOI>” and “Futile <QOI>” indicating whether any decision criteria became true, and “Success Combined” and “Futile Combined” indicating if all the criteria for a success or futility determination have been met. If both sets of criteria are met simultaneously, FACTS will only flag one of “Success Combined” and “Futile Combined” as being met, corresponding to how the outcome of the trial has been flagged.\n\n\nHaving created a tab to define the early success/futility criteria at an interim, the user has options to delete the tab or to copy criteria that have already been entered on another tab before editing them.\nThe user specifies:\n\nWhether early stopping for futility or success is to be allowed by selecting the “Futility criteria” or “Success criteria”\nThe stopping rules are specified, by selecting the QOI to be tested, the direction of the comparison and the threshold value for the criteria to be met.\nThe user can specify whether, if multiple criteria have been specified, they all need to be meet (Criteria combined using “AND”) or only any one of them needs to be met (Criteria combined using “OR”). These are specified independently for stopping for success and for futility.\nIf stopping is allowed, the user specifies what the minimum amount of information (using the information type specified on the Interims tab). This can be specified both in overall terms and information on specific doses. If multiple minimum-information criteria are specified they must all be met for the QOI criteria to be evaluated.\n\n\nNote that stopping is only assessed at interims, not immediately when these criteria are met.", + "objectID": "documentation/v71/userguides/installation.html#computation-requirements", + "href": "documentation/v71/userguides/installation.html#computation-requirements", + "title": "FACTS Installation Guide", + "section": "3.2 Computation Requirements", + "text": "3.2 Computation Requirements\nFACTS relies on running simulations and these simulations can be very computationally intensive. When running simulations, each simulation can be run separately (they do not depend on the results of other simulations) though to do so can be somewhat inefficient – repeatedly starting new processes and generating separate output files for every simulation that will need to be gathered together in a single “simulations.csv” file and then summarized. Thus FACTS allows the user to specify a “packet size” and the total number of simulations for each scenario to be simulated is divided by this packet size to create a set of independent jobs.\nIf the simulations are run on the users laptop or PC, FACTS will spawn a simulation thread for every core on the local machine up to the maximum number of simulation ‘packets’ that have been requested. The simulations are run at reduced priority so it is possible to continue to use the machine e.g. for email or Word whilst they run. Thus usually 2 or 4 sets of simulations are run in parallel depending on the processor in the laptop or PC.\nThere are a number of options for speeding up the running of FACTS simulations:\n\nThe simplest technically (and the approach we used to take at Berry Consultants) is to have a large multi-core server (say 32 core) remotely accessible to FACTS users and FACTs installed on it. To use, the user copies the “.facts” files to be simulated to a network shared directory which can be accessed from the server. Then after remotely logging into to the server, the user copies these files to a drive on the server, runs the simulations, zips up the results (within the FACTS GUI there is the FACTS File > Export Project menu command to do this) and copies them back to the network shared drive and thence to their local machine.\nUse the FACTS network share folder “grid” interface, implemented using file transfers to and from a shared network drive. On a machine that can act as a client to a grid of compute nodes managed by one of the standard grid management packages (they used to be called “SunGrid” and “Condor” but have metamorphosed over the years) a “sweeper script” runs that transfers jobs to the grid. The jobs automatically transfer their results back to this shared drive. FACTS copies the job to a unique subfolder on the shared network location and then watches for a change in the lock file name - “submitted”, “running”, “complete” that are managed by the sweeper script. Once the simulations are complete FACTS copies the results back to the local machine. The fact that the simulations have been submitted to the grid are stored in the “.facts” file. Whenever that “.facts” file is open in FACTS, FACTS will poll the remote network drive to check if the simulations are complete.\nA more sophisticated FACTS grid interface that uses a web services to communicate between the FACTS client and a Linux server running a web-server (Apache Tomcat) and database (MySQL). The web service is used to submit jobs and they are stored in the database. A database process then submits them to the grid, once again managed by one of the standard grid management packages. The simulation results are then stored in the database for FACTS to download once complete. This provides a more robust and manageable interface, but it more work to set up. We can provide documentation and scripts and we can assist in setting this up. This is the form of grid that we now use in-house at Berry Consultants.\nTechnically as 3. (but for a fee) Berry Consultants can set and manage the grid for you in the cloud. Please contact us to discuss your requirements and for pricing. Therefore FACTS is able to offload the simulations from the desktop to be run by an external system. The interface describing the interactions with the external system is described in the FACTS Grid Interface document. With a FACTS Enterprise License, the command line executable files to run simulations externally under either Windows or Linux environments are available upon request.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#final-evaluation-criteria", - "href": "documentation/v71/userguides/core.html#final-evaluation-criteria", - "title": "FACTS Core User Guide", - "section": "13.2 Final Evaluation Criteria", - "text": "13.2 Final Evaluation Criteria\nOn the Final Evaluation Criteria tab, the user can specify rules for judging the study for final futility or final success at its end. The tab layout is the same as an interim Success/Futility tab except there are no minimum information rules to be specified.\nThe Final Evaluation Criteria are always applied at the time of the final analysis, even if the study stops early for success or futility, and whether or not “Continue follow-up if study stopped for success” or “Continue follow-up if study stopped for futility” are selected. As a result, setting final analysis criteria that are easier to satisfy than interim analysis criteria may result in the labelling of trials that meet the interim analysis criteria but do not satisfy the final analysis criteria as flip-flops.", + "objectID": "documentation/v71/userguides/installation.html#installation-instructions", + "href": "documentation/v71/userguides/installation.html#installation-instructions", + "title": "FACTS Installation Guide", + "section": "4.1 Installation Instructions", + "text": "4.1 Installation Instructions\nThe FACTS Desktop installation package consists of:\nsetup.exe a Windows installation program, Setup.msi the FACTS Microsoft Installer file Examples.zip a Zip file containing example FACTS projects, Documents.zip a Zip file containing the FACTS documentation. Config.xml an XML file containing the local configuration settings. These files are usually made available for download from Berry Consultants Microsoft App Center site. Download instructions are in a separate document. Versions of these files with the standard file extensions (.msi and .zip) modified are available it may have been these versions that were downloaded to circumvent firewall restrictions and these files will need to be renamed prior to use. Installation will take only a few moments. - Ensure that all the files have the correct file extension and are located on a local drive on the machine on which FACTS is to be installed. Windows can treat installs from networked drives as less trustworthy than installs from local drives and this can result in an incomplete installation. - Right click the setup.exe Windows installation program and select “Run as Administrator”. - Follow the instructions on the screen to complete the installation. - During FACTS installation you will have to option to enable FACTS to report Analytics back to the App Center. This allows to see how much FACTS is used and which features in FACTS are being used. It does NOT include any user or license information, we can’t see WHO is doing what, only WHAT is being done. Obviously we’d be grateful if you’d enable them. Analytics are off by default they will only be enabled of you enable them. Once installed analytics can be turned on or off from the FACTS “Settings” menu command.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#state-descriptions", - "href": "documentation/v71/userguides/core.html#state-descriptions", - "title": "FACTS Core User Guide", - "section": "14.1 State descriptions", - "text": "14.1 State descriptions\nFor the purposes of interims, the different states or stages of a trial are:\n\nIn Burn-in / before first analysis. In adaptive allocation designs, the burn-in denotes the initial group of subjects explicitly assigned to treatment arms before probabilistic allocation begins. FACTS prevents the burn-in requiring more subjects than the maximum number of subjects – but the numbers can be equal. Regardless of the interim schedule specified (e.g., frequency, number of subjects or number of events), a) no analyses are performed during this period of time, and b) the first analysis is performed at its conclusion. In arm dropping and early stopping designs the first analysis occurs at the explicitly specified initial interim. Interims are never performed in non-adaptive designs; rather, the first and only analysis occurs when the max subject’s final observation is taken. In all cases, it is possible to reach the maximum number of events prior to the first analysis, making the study complete.\nMid Trial. Interims are performed and all rules assessed. If arms have been dropped, the per-arm posterior probabilities are still calculated for the dropped arms but the drop decision for the arms is absorbing and not re-assessed.\nFully Accrued but not complete. All subjects have been recruited and being followed up. If interims are by subject or ‘interim analysis beyond full accrual’ is set to FALSE, then the only possible next event is ‘last subject final observation’.\nStopped Early but still following up. The study stopping rules are not evaluated, but arm dropping rules are. Interims may still occur.\nComplete. All possible data collected for every enrolled subject.", + "objectID": "documentation/v71/userguides/installation.html#config.xml", + "href": "documentation/v71/userguides/installation.html#config.xml", + "title": "FACTS Installation Guide", + "section": "4.2 Config.xml", + "text": "4.2 Config.xml\nIncluded with the FACTS installation files is a configuration file that can be edited to local settings before the install files are distributed to users. It is also possible to provide an updated copy of the configuration file to users and ask them to update their default configuration, it is also possible for users to locally modify their configuration and revert to the installed configuration details.\nPrior to installation, a configuration file, ‘config.xml’, is available as one of the installation files. This file can be edited to set up a number of default settings for FACTS.\nThe settings are listed between the tags: <configuration> <userSettings> and </userSettings> </configurations>, for example:\n<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<configuration>\n <userSettings>\n <GridLocation>C:\\\\work\\\\grid</GridLocation>\n <GridOpSys>1</GridOpSys>\n <GridListenerDelay>10000</GridListenerDelay>\n <LocalRVersions>\n <value>version=\"3.3.2\" path=\"C:\\\\Program Files\\\\R\\\\R-3.3.2\\\\bin\\\\R.exe\" active=\"1\"</value>\n <value>version=\"RStudio\" path=\"C:\\\\Program Files\\\\RStudio\\\\bin\\\\RStudio.exe\"</value>\n </LocalRVersions>\n <FactsSimulationServicePortURL>http://nowhere.com:8080/axis2/services/FactsSimulationServicePort</FactsSimulationServicePortURL>\n <GridSimMethod>0</GridSimMethod>\n </userSettings>\n</configuration>\nSpecifically, the following values may be adjusted, as desired:\n\nLocalRVersions – a list of available R (or RStudio) versions, each one bracketed by the tags and and composed of two parameters “version” which can contain any string to be used to identify that version of R and “path” which should contain location of “.exe” that should be run when the user requests R to be run or a Design Report to be generated.\nGridSimMethod – 0 or 1, Determines how FACTS tries to connect to the grid, 0 means the network file share & sweeper script method (option 2 above) is to be used, 1 means that the Web Service method (option 3 or 4 above) is to be used\nIf the network file share method is to be used to connect to the grid then:\n\nGridLocation – the network location of the network file share.\nGridOpSys – 0 or 1, the type of the operating system that is running on the nodes of the grid: 0 – Linux, 1 – Windows (the simulation engine executables have different names in the two environments).\nGridListenerDelay – the delay (in milliseconds) between each poll of the network file share for changes in the state of the simulation results.\n\nIf the Web Service grid access method is to be used to connect to the grid then:\n\nFactsSimulationServicePortURL – specifies the URL to the FACTS web-service endpoint.\n\n\nNote, this configuration file is only used on the initial load of FACTS – subsequently, a local user configuration file is created in a location under the AppData folder – e.g.:\nC:\\Users\\<user_id>\\AppData\\Local\\Berry_Consultants_Inc\\FACTS_File_Loader_Url_<Windows unique file id >\\6.1.6.17435\\user.config\nAny changes made to the configuration from the UI (under the ‘Settings’ menu) are saved to this local file. – and the original config file is only used if the options are reset.\nNB, these local configuration are FACTS version and build specific (note the version and build number in the directory) – which means that if a new install is run, local configuration modifications will be lost.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#analysis-trigger-events", - "href": "documentation/v71/userguides/core.html#analysis-trigger-events", - "title": "FACTS Core User Guide", - "section": "14.2 Analysis trigger events", - "text": "14.2 Analysis trigger events\nThe following are the events that trigger interims, stopping or changes of trial state:\n\nLast event is observed (TTE trial with a max number of events – this is the only circumstance that can arise before the end of burn-in / first analysis that can stop the trial).\nA “number of subjects interim” occurs (other than last subject of burn-in / first analysis)\nA “cohort complete” interim occurs (when using cohort enrolment). A cohort complete event is slightly different from a “number of subjects interim” in that after a cohort is fully enrolled the interim does not occur until all the subjects are complete.\nStudy max subject size is reached.\nRecruit last subject of burn-in / first analysis occurs.\nA “time” or “number of events” interim occurs.\nLast subject’s final observation is taken (in a TTE trial this might be that the last subject to have an event has their event, or last subject recruited reaches the end of the maximum follow-up and is censored).", + "objectID": "documentation/v71/userguides/installation.html#notes-on-access-permissions", + "href": "documentation/v71/userguides/installation.html#notes-on-access-permissions", + "title": "FACTS Installation Guide", + "section": "4.3 Notes on access permissions", + "text": "4.3 Notes on access permissions\nFACTS uses the locations C:\\Program Data\\BerryConsultants and <user>\\AppData\\Local\\BerryConsultants, we have seen some IT departments set the default access permissions to deny access to these locations contrary to Microsoft’s intention and the access will need to be granted for FACTS to run. When FACTS runs simulations it spawns one or more simulations processes, and we have encountered environments where these processes do not get permission to write to network drives. If these permissions cannot be changed, it will be necessary for users to save their “.facts” file run in a directory on the local drive before running simulations, so the results can be written there and then copied/moved to the network drive once complete.\n\n4.3.1 License Installation\nWhen FACTS is first run, it may require the license to be entered. The user can choose the file when prompted, or cut and paste the information into the dialog box. Alternatively, the file can be dropped in the application folder and it will be picked up when needed. Note, depending on access permissions, it may be necessary to initially load FACTS with admin rights in order to load the license key from file.\nSubsequent runs, and subsequent installations of mod level updates, will not require the license to be re-entered.", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/userguides/core.html#trial-state-transitions", - "href": "documentation/v71/userguides/core.html#trial-state-transitions", - "title": "FACTS Core User Guide", - "section": "14.3 Trial State Transitions", - "text": "14.3 Trial State Transitions\nNote: the term “study arms” is used to refer to the treatment arms that are not the control or active comparator arm. In an arm dropping design only the study arms can be dropped, and the trial stops if all study arms are dropped.\n\n\n\nFigure 3‑2 Add Posterior Probability QOI dialog\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nState transition table\n\n\n\n\n\n\n\nTriggers\n\n\nProcessed in order …\n\n\n\n\n1: In Burn-in / before first analysis\n\n\n[This is the starting state for adaptive allocation designs]\n\n\n\n\n2: Mid Trial\n\n\n[This is the starting state for arm dropping, early stopping, and non-adaptive designs]\n\n\n\n3: Fully Accrued but not complete\n\n\n\n4: Stopped Early but following up\n\n\n[This state can only be entered if “Continue follow-up if study stopped for success/futility is set]\n\n\n\n\n5: Complete\n\n\n[This is the final state]\n\n\n\n\n\nA: Last event is observed [can only occur in TTE trials]\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\nN/A\n\n\n\n\nB: A “number of subjects” interim occurs\n\n\nN/A\n\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then if “Continue follow-up” for the appropriate decision is selected go to “4: Stopped Early” otherwise a “final evaluation” is output and\n\n\nGo to “5: Complete”\n\n\nIf the interim size = Max subjects then go to “3: Fully Accrued”\n\n\nOtherwise stay in “2: Mid Trial”\n\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nC: A “cohort complete” interim occurs [for trials using cohort enrolment]\n\n\n\n[Can only occur when the final observation of a burn-in cohort is observed]\n\n\nAn interim is output.\n\n\nIf stopping conditions are met a “final evaluation” is output and go to “5: Complete”.\n\n\nOtherwise go to “2: Mid Trial”.\n\n\n\n\nAn interim is output.\n\n\nIf stopping conditions are met a “final evaluation” is output and go to “5: Complete”.\n\n\nIf the interim size = Max cohort or the max cohort size is reached then a “final evaluation” is output and go to “5: Complete”.\n\n\nOtherwise stay in “2: Mid Trial”\n\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nD: Study max subject size is reached\n\n\n\n[Can only occur if Burn-in / first interim size = Max subjects]\n\n\nGo to “3: Fully Accrued”.\n\n\n\nGo to “3: Fully Accrued”\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nE: Recruit last subject of burn-in / first analysis\n\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then ff “Continue Follow-up if study stopped“ for the appropriate decision is set go to “4: Stopped Early but following up” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\nOtherwise go to “2: Mid Trial”\n\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\n\n\nF: A “time” or “number of events” interim occurs\n\n\nN/A\n\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then ff “Continue Follow-up if study stopped“ for the appropriate decision is set go to “4: Stopped Early but following up” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\nOtherwise stay in “2: Mid Trial”\n\n\n\n\nIf “Discontinue interim analysis after full enrollment” is set, then there is no output. Stay in “3: Fully Accrued”\n\n\nOtherwise:\n\n\nAn interim is output.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf stopping conditions are met or all study arms dropped then ff “Continue Follow-up if study stopped“ for the appropriate decision is set go to “4: Stopped Early but following up” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\nOtherwise stay in “3: Fully Accrued”\n\n\n\n\nIf “Discontinue interim analysis after full enrollment” is set then there is no output, stay in “4: Stopped Early”\n\n\nOtherwise:\n\n\nAn interim only checking arm-dropping is output. Stopping conditions not checked.\n\n\nIf arm dropping, check not yet dropped arms to see if any should be dropped and flag those that are.\n\n\nIf all study arms are dropped then if “Continue follow-up if arm dropped” is set stay in “4: Stopped Early” otherwise a “final evaluation” is output and go to “5: Complete”\n\n\n\nN/A\n\n\n\n\nG: Last subject’s final observation is taken\n\n\nN/A\n\n\nN/A\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\n\nA “final evaluation” is output.\n\n\nGo to “5: Complete”\n\n\n\nN/A\n\n\n\n\nFigure 3‑2 Add Posterior Probability QOI dialog", + "objectID": "documentation/v71/userguides/installation.html#installation-verification", + "href": "documentation/v71/userguides/installation.html#installation-verification", + "title": "FACTS Installation Guide", + "section": "4.4 Installation Verification", + "text": "4.4 Installation Verification", "crumbs": [ "Documentation", "Version 7.1", "User Guides", - "FACTS Core User Guide" + "FACTS Installation Guide" ] }, { - "objectID": "documentation/v71/examples/CRM/example2.html", - "href": "documentation/v71/examples/CRM/example2.html", - "title": "Example 2", + "objectID": "documentation/v71/examples/CRM/example1.html", + "href": "documentation/v71/examples/CRM/example1.html", + "title": "Example 1", "section": "", - "text": "Second example", + "text": "First example", "crumbs": [ "Documentation", "Version 7.1", "Examples", "CRM", - "Example 2" + "Example 1" ] }, { - "objectID": "documentation/v71/examples/Staged/example2.html", - "href": "documentation/v71/examples/Staged/example2.html", - "title": "Example 2", + "objectID": "documentation/v71/examples/Staged/example1.html", + "href": "documentation/v71/examples/Staged/example1.html", + "title": "Example 1", "section": "", - "text": "Second example", + "text": "First example", "crumbs": [ "Documentation", "Version 7.1", "Examples", "Staged", - "Example 2" + "Example 1" ] }, { - "objectID": "documentation/index.html", - "href": "documentation/index.html", - "title": "Documentation", + "objectID": "documentation/glossary.html", + "href": "documentation/glossary.html", + "title": "Glossary", "section": "", - "text": "Home page for Documentation.\nTable 1 gives an overview of the acronyms and abbreviations used in the documentation.\n\n\n\nTable 1: List of terms used in the user guides\n\n\n\n\n\n\n\n\n\nName\nDefinition\n\n\n\n\nCap\nA limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap.\n\n\nControl\nIs the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\n\n\nCore\nFACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\n\n\nCRM\nContinual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\n\n\nDE\nDose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\n\n\nED\nEnrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications.\n\n\nFACTS\nFixed and Adaptive Clinical Trial Simulator.\n\n\nFinal Endpoint\nThe final value, or state, of a subject’s endpoint.\n\n\nGUI\nGraphical User Interface, the part of the FACTS application that the user interacts with.\n\n\nMethod\nIn the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\n\n\nModel\nIn the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\n\n\nMTD\nThe dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD).\n\n\nMTD+\nThe dose most likely to be the MTD+ – the dose with the highest Pr(MTD+).\n\n\nPr(MTD)\nA dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses.\n\n\nPr(MTD+)\nA dose’s probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range.\n\n\nProfile\nA profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nScenario\nA scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include: -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups -) the properties of subjects’ early responses and the correlation with their final outcome -) the rate at which subjects are recruited into the trial -) the rate at which subjects drop out of the trial.\n\n\nSPEC\nThe Design Engine Specification, describes the system algorithms, and meaning of parameters.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nSubject\nSomeone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\n\n\nTreatment Arm\nSubjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\n\n\nUG\nThe User Guide; describes how to use the system.", + "text": "Abbreviations\nTable 1 gives an overview of the acronyms and abbreviations used in the documentation.\n\n\n\nTable 1: List of terms used in the user guides\n\n\n\n\n\n\n\n\n\nName\nDefinition\n\n\n\n\nCap\nA limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap.\n\n\nControl\nIs the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness.\n\n\nCore\nFACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator.\n\n\nCRM\nContinual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD).\n\n\nDE\nDose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed.\n\n\nED\nEnrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications.\n\n\nFACTS\nFixed and Adaptive Clinical Trial Simulator.\n\n\nFinal Endpoint\nThe final value, or state, of a subject’s endpoint.\n\n\nGUI\nGraphical User Interface, the part of the FACTS application that the user interacts with.\n\n\nMethod\nIn the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below.\n\n\nModel\nIn the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this.\n\n\nMTD\nThe dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD).\n\n\nMTD+\nThe dose most likely to be the MTD+ – the dose with the highest Pr(MTD+).\n\n\nPr(MTD)\nA dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses.\n\n\nPr(MTD+)\nA dose’s probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range.\n\n\nProfile\nA profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nScenario\nA scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include: -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups -) the properties of subjects’ early responses and the correlation with their final outcome -) the rate at which subjects are recruited into the trial -) the rate at which subjects drop out of the trial.\n\n\nSPEC\nThe Design Engine Specification, describes the system algorithms, and meaning of parameters.\n\n\nResponse\nThe change in a subject’s endpoint compared to their baseline state.\n\n\nSubject\nSomeone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers.\n\n\nTreatment Arm\nSubjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared.\n\n\nUG\nThe User Guide; describes how to use the system.", "crumbs": [ - "Documentation" + "Documentation", + "Glossary" ] }, { @@ -1782,7 +1833,7 @@ "href": "concepts/facts/LinearRegressionLMPriors.html#sec-priorSpecWidget", "title": "Linear Regression Multiple Imputation Model", "section": "Prior Specification Widget", - "text": "Prior Specification Widget\n\nInterpretation of parameters\n\n\\(\\alpha_{t}\\)\n\nThe expected response on the final endpoint when the early visit \\(t\\) has a response of 0\n\n\\(\\beta_{t}\\)\n\nIf \\(\\alpha=0\\), then \\(\\beta\\) is how many times larger the final endpoint response is than the early endpoint at visit \\(t\\). If \\(\\beta=0\\), then no matter what the early visit response is, the expectation for the final visit is \\(\\alpha\\). If \\(\\beta=1\\), then for any early response the expectation of the final response is the \\(\\text{early response} + \\alpha\\). A \\(\\beta \\lt 1\\) generally implies that the final endpoint is expected to regress towards 0 (when \\(\\alpha=0\\)), and a \\(\\beta \\gt 1\\) implies that the final response is expected to keep growing relative to the early visit response.\n\n\\(\\lambda_{t}\\)\n\nThe standard deviation around the expectation of the final visit response. This dictates how close the imputed final endpoint responses are to the mean response for a subject given \\(\\alpha\\) and \\(\\beta\\). Lower \\(\\lambda_t\\) implies higher correlation between the early visit response and final visit response.\n\n\n```tpptxlgagaafd #| standalone: true #| viewerHeight: 1000\nlibrary(shiny) library(DT) library(ggplot2) library(htmltools)\nalignCenter <- function(el) { htmltools::tagAppendAttributes(el, style=“margin-left:auto;margin-right:auto;” ) }\nsketch = htmltools::withTags(table( class = ‘display’, thead( tr( th(rowspan = 2, ’‘), th(rowspan = 2, style = “border-right: solid 1px;”,’Observed Visit Data’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘B1 priors’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘B2 priors’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘BB priors’) ), tr( th(“mean”), th(style = “border-right: solid 1px;”, “SD”), th(“mean”), th(style = “border-right: solid 1px;”, “SD”), th(“center”), th(style = “border-right: solid 1px;”, “weight”), ) ) ))\nui <- fluidPage( tags\\(head(\n # Note the wrapping of the string in HTML()\n tags\\)style(HTML(” .my_col_class { align-content: center; }“) ) ),\ntitlePanel(h1(“Linear Regression LM Priors”, align = “center”)), alignCenter(sliderInput(“numVisits”, “Number of visits:”, min = 2, max = 20, value = 5, step = 1)), DTOutput(“dataInputTable”), h5(“Double click on a cell to edit.”, align = “center”), br(), titlePanel(h2(“Plot a subject’s prior predictive”, align = “center”)), fluidRow( #column(5, offset = 1, uiOutput(“slider”)), column(5, offset = 1, uiOutput(“slider”)), column(6, fluidRow( column(6, offset = 2, checkboxInput(“fixAlpha”, “Fix alpha at its mean?”, value = FALSE, width = “100%”)), column(6, offset = 2, checkboxInput(“fixBeta”, “Fix beta at its mean?”, value = FALSE, width = “100%”)), column(6, offset = 2, checkboxInput(“removePredictive”, “Remove endpoint prior predictive?”, value = FALSE, width = “100%”)) )) ), fluidRow( column(6, plotOutput(“visitToFinalPlot”)), column(6, plotOutput(“priorPredictive”)) )\n)\ngetLowerMedianUpper = function(earlyVisitVal, alpha = c(0,1), beta = c(0,1), lambda = c(1,1)) { distMeanFinal = c(alpha[1] + beta[1]earlyVisitVal, sqrt(alpha[2]^2 + beta[2]^2earlyVisitVal^2))\ndeviates = rnorm(10000) deviates = (deviates - mean(deviates))/(sd(deviates))\nif(any(is.na(lambda))) { samps = (deviatesdistMeanFinal[2] + distMeanFinal[1]) } else { samps = (deviatesdistMeanFinal[2] + distMeanFinal[1]) + rnorm(10000, 0, sd = sqrt(1/rgamma(10000, lambda[2]/2, lambda[1]^2*lambda[2]/2))) }\ndistValueFinal = c(mean(samps), sd(samps))\nreturn(list(“meanFinal” = data.frame(lower = distMeanFinal[1] + qnorm(.025)distMeanFinal[2], median = distMeanFinal[1], upper = distMeanFinal[1] + qnorm(0.975)distMeanFinal[2]), “predictionFinal” = data.frame(lower = quantile(samps,.025), median = median(samps), upper = quantile(samps,.975)))) }\nserver <- function(input, output, session) {\ndf = data.frame(VisitResponse = c(2,5,3,7,11), alphaPriorMean = 0, alphaPriorSD = 2, betaPriorMean = 1, betaPriorSD = 2, lambdaPriorCenter = 5, lambdaPriorWeight = 3) df[5,] = c(5, NA, NA, NA, NA, NA, NA) row.names(df) = paste(“Visit”, 1:5)\n## Render DF to actually change output\\(dataInputTable = renderDT(datatable(df,\n options = list(\n pageLength = 20,\n dom = \"t\",\n autoWidth = TRUE,\n columnDefs = list(list(className = 'dt-center', orderable = FALSE, width = '75px', targets = 0:7),\n list(width = \"150px\", targets = 0:1))\n ),\n container = sketch,\n rownames = TRUE,\n # escape = FALSE,\n selection = 'none',\n editable = list(target = \"cell\")\n ) |> formatStyle(c(1,3,5,7), `border-right` = \"solid 1px\") |>\n formatRound(1, digits = 4) |> formatRound(2:7, digits = 2) |>\n formatStyle(0,\n target = \"row\",\n backgroundColor = styleEqual(paste(\"Visit\",input\\)lastVisitWithData), “lightblue”, ‘white’)) )\n## Update from Conditional proxy = dataTableProxy(‘dataInputTable’)\nobserveEvent(input\\(dataInputTable_cell_edit, {\n info = input\\)dataInputTable_cell_edit i = info\\(row\n j = info\\)col v = info$value\nif(i < nrow(df) | j == 1) {\n df <<- editData(df, info)\n} else {\n df[i,j] <<- NA\n}\nreplaceData(proxy, df) \n})\nobserve({ nv = input$numVisits if(nv > nrow(df)) { tempd = df for(i in 1:(nv-nrow(df))) { tempd = rbind(tempd, setNames(data.frame(c(tempd[nrow(tempd),])), names(tempd))) rownames(tempd)[nrow(tempd)] = paste(“Visit”, nrow(tempd)) tempd[nrow(tempd)-1,-1] = tempd[nrow(tempd)-2,-1] } df <<- tempd } else if(nv < nrow(df)) { df <<- df[1:nv,] df[nv,-1] <<- NA } replaceData(proxy, df) })\nsliderParams <- reactiveValues(max = 5, value = 3) output\\(slider <- renderUI({\n sliderInput(\"lastVisitWithData\", \"Last complete visit:\", min = 1, max = sliderParams\\)max, value = sliderParams\\(value, step = 1)\n })\n observeEvent(input\\)numVisits, { sliderParams\\(max = input\\)numVisits if(!is.null(input\\(lastVisitWithData)) {\n sliderParams\\)value <- min(input\\(lastVisitWithData, input\\)numVisits) } else { sliderParams$value = 3 } })\noutput\\(priorPredictive = renderPlot({\n req(input\\)lastVisitWithData) input$dataInputTable_cell_edit\nlvIndex = input$lastVisitWithData\nfinalVisitIndex = input$numVisits\ntempDF = df\ndataToPlot = getLowerMedianUpper(tempDF[lvIndex,1],\n alpha = c(tempDF[lvIndex,2], ifelse(input$fixAlpha, 0, tempDF[lvIndex,3])),\n beta = c(tempDF[lvIndex,4], ifelse(input$fixBeta, 0, tempDF[lvIndex,5])),\n lambda = c(tempDF[lvIndex,6], tempDF[lvIndex,7]))\n\ntempDF$RowVisitIndex = 1:nrow(tempDF)\ntempDF$visitKnown = \"included\"\ntempDF$visitKnown[tempDF$RowVisitIndex > lvIndex] = \"excluded\"\n\n# tempDF = rbind(setNames(data.frame(c(tempDF[1,])), names(tempDF)), tempDF)\n# tempDF[1,1] = 0\n# tempDF$RowVisitIndex[1] = 0\n# rownames(tempDF)[1] = \"Baseline\"\n\np1 = ggplot() + \n geom_point(dat = tempDF, aes(x = RowVisitIndex, y = VisitResponse, color = visitKnown), size = 3) + \n scale_color_manual(breaks = c(\"included\", \"excluded\"), values = c(\"black\", \"gray70\"), guide = \"none\") +\n coord_cartesian(xlim = c(0, finalVisitIndex)) + \n scale_x_continuous(breaks = 0:finalVisitIndex, labels = c(\"Baseline\", 1:finalVisitIndex)) +\n xlab(\"Visit\") + ylab(\"Response\") + ggtitle(\"Predicting Final Endpoint of a Subject\") +\n theme_bw() + \n theme(plot.title = element_text(size = 20), text = element_text(size = 16), legend.justification = \"left\", legend.position = \"bottom\", legend.direction = \"vertical\")\n\nif(lvIndex < finalVisitIndex) {\n if(!input$removePredictive) {\n p1 = p1 + \n geom_segment(data = dataToPlot[[2]], aes(x = finalVisitIndex, y = lower, yend = upper), color = \"darkgreen\", linewidth = 2.5) +\n annotate(geom = \"point\", x = finalVisitIndex, y = dataToPlot[[2]]$median, color = \"darkgreen\", size = 3, shape = 18) +\n geom_ribbon(data = NULL, aes(x = c(lvIndex, finalVisitIndex),\n ymin = c(tempDF$VisitResponse[lvIndex], dataToPlot[[2]]$lower),\n ymax = c(tempDF$VisitResponse[lvIndex], dataToPlot[[2]]$upper),\n fill = \"preds\"), color = NA, alpha = .2)\n }\n p1 = p1 +\n geom_segment(data = dataToPlot[[1]], aes(x = finalVisitIndex, y = lower, yend = upper), color = \"darkblue\", linewidth = 1.5) +\n annotate(geom = \"point\", x = finalVisitIndex, y = dataToPlot[[1]]$median, color = \"darkblue\", size = 3, shape = 18) +\n annotate(geom = \"segment\", x = lvIndex, xend = finalVisitIndex, y = tempDF$VisitResponse[lvIndex], yend = dataToPlot[[1]]$median, linetype = \"dashed\", color = \"darkblue\")+\n geom_ribbon(data = NULL, aes(x = c(lvIndex, finalVisitIndex),\n ymin = c(tempDF$VisitResponse[lvIndex], dataToPlot[[1]]$lower),\n ymax = c(tempDF$VisitResponse[lvIndex], dataToPlot[[1]]$upper)),\n fill = \"darkblue\", color = NA, alpha = .4)\n} else {\n p1 = p1 + annotate(geom=\"text\", label = \"Final Visit Value Known\",\n alpha = .5, size = 10, x = (finalVisitIndex)/2, y = Inf, vjust = 1.3)\n}\n\np1 = p1 + scale_fill_manual(NULL, breaks = c(\"preds\"), limits = c(\"preds\"), values = c(\"darkgreen\"), labels = c(\"Prior predictive distribution for final endpoint of subject.\"))\n# guides(fill = guide_legend(override.aes = list(limits = c(\"darkgreen\", \"darkblue\"), labels = c(\"Prior distribution for mean of imputed value.\", \"Prior predictive distribution for final endpoint of subject.\")))) \n\np1\n})\noutput\\(visitToFinalPlot = renderPlot({\n input\\)dataInputTable_cell_edit req(input$lastVisitWithData)\nlvIndex = input$lastVisitWithData\nfinalVisitIndex = input$numVisits\n\ntempDF = df\n\nmin_s = ifelse(min(tempDF$VisitResponse, na.rm = TRUE) < 0, (min(tempDF$VisitResponse, na.rm = TRUE)+1)*1.1, 0)\nmax_s = ifelse(max(tempDF$VisitResponse, na.rm = TRUE) > 0, (max(tempDF$VisitResponse, na.rm = TRUE)+1)*1.1, 0)\n\ns = seq(min_s-5, max_s+5, length.out = 101)\n\nmeanDist_mean = tempDF$alphaPriorMean[lvIndex] + tempDF$betaPriorMean[lvIndex]*s\nif(!input$fixAlpha & !input$fixBeta) {\n meanDist_sd = sqrt(tempDF$alphaPriorSD[lvIndex]^2 + tempDF$betaPriorSD[lvIndex]^2*s^2)\n} else if(input$fixAlpha & !input$fixBeta) {\n meanDist_sd = sqrt(tempDF$betaPriorSD[lvIndex]^2*s^2)\n} else if(!input$fixAlpha & input$fixBeta) {\n meanDist_sd = rep(sqrt(tempDF$alphaPriorSD[lvIndex]^2), length(s))\n} else {\n meanDist_sd = rep(0, length(meanDist_mean))\n}\n\nplotDF = data.frame(earlyVis = s,\n lower = meanDist_mean + qnorm(0.025)*meanDist_sd,\n median= meanDist_mean,\n upper = meanDist_mean + qnorm(0.975)*meanDist_sd)\n\nif(lvIndex < finalVisitIndex) {\n if(!input$removePredictive) {\n numSamps = 2500\n \n deviates = rnorm(numSamps)\n deviates = (deviates - mean(deviates))/(sd(deviates))\n normigsamps = rnorm(numSamps, 0, sd = sqrt(1/rgamma(numSamps, tempDF$lambdaPriorWeight[lvIndex]/2, tempDF$lambdaPriorCenter[lvIndex]^2*tempDF$lambdaPriorWeight[lvIndex]/2)))\n \n distVals = matrix(NA, ncol = 2, nrow = length(s))\n for(i in 1:length(s)) {\n distVals[i,] = quantile((deviates*meanDist_sd[i] + meanDist_mean[i] + normigsamps), c(0.025, 0.975))\n }\n \n plotDF$lowerPred = distVals[,1]\n plotDF$upperPred = distVals[,2]\n }\n \n p2 = ggplot(data = plotDF) + geom_abline(aes(slope = tempDF$betaPriorMean[lvIndex], intercept = tempDF$alphaPriorMean[lvIndex]), color = \"darkblue\", linewidth = 1.5) + \n geom_ribbon(aes(x = s, ymin = lower, ymax = upper, fill = \"means\"), color = NA, alpha = 0.4)\n \n if(!input$removePredictive) {\n p2 = p2 + geom_ribbon(aes(x = s, ymin = lowerPred, ymax = upperPred), fill = \"darkgreen\", color = NA, alpha = 0.2) \n }\n p2 = p2 +\n coord_cartesian(xlim = c(min_s, max_s)) +\n xlab(\"Early Visit Known Value\") + ylab(\"Expectation of Final Visit Response\") + ggtitle(\"Expectation of Final Visit Given Early Visit\") +\n theme_bw() + \n theme(plot.title = element_text(size = 20), text = element_text(size = 16), legend.justification = \"right\", legend.position = \"bottom\", legend.direction = \"vertical\")\n} else {\n p2 = ggplot(data = NULL) + geom_abline(aes(fill = \"means\"), slope = 1, intercept = 0, color = \"darkblue\", linewidth = 1.5) + \n coord_cartesian(xlim = c(min_s, max_s), ylim = c(min_s, max_s)) +\n annotate(geom=\"text\", label = \"Final Visit Value Known\",\n alpha = .5, size = 10, x = (max_s + min_s)/2, y = Inf, vjust = 1.3) +\n xlab(\"Early Visit Known Value\") + ylab(\"Expectation of Final Visit Response\") + ggtitle(\"Expectation of Final Visit Given Early Visit\") +\n theme_bw() + \n theme(plot.title = element_text(size = 20), text = element_text(size = 16), legend.justification = \"right\", legend.position = \"bottom\", legend.direction = \"vertical\")\n}\np2 = p2 + scale_fill_manual(NULL, breaks = c(\"means\"), limits = c(\"means\"), values = c(\"darkblue\"), labels = c(\"Prior distribution for mean of imputed value.\")) \np2\n}) }\nshinyApp(ui = ui, server = server)```", + "text": "Prior Specification Widget\n\nInterpretation of parameters\n\n\\(\\alpha_{t}\\)\n\nThe expected response on the final endpoint when the early visit \\(t\\) has a response of 0\n\n\\(\\beta_{t}\\)\n\nIf \\(\\alpha=0\\), then \\(\\beta\\) is how many times larger the final endpoint response is than the early endpoint at visit \\(t\\). If \\(\\beta=0\\), then no matter what the early visit response is, the expectation for the final visit is \\(\\alpha\\). If \\(\\beta=1\\), then for any early response the expectation of the final response is the \\(\\text{early response} + \\alpha\\). A \\(\\beta \\lt 1\\) generally implies that the final endpoint is expected to regress towards 0 (when \\(\\alpha=0\\)), and a \\(\\beta \\gt 1\\) implies that the final response is expected to keep growing relative to the early visit response.\n\n\\(\\lambda_{t}\\)\n\nThe standard deviation around the expectation of the final visit response. This dictates how close the imputed final endpoint responses are to the mean response for a subject given \\(\\alpha\\) and \\(\\beta\\). Lower \\(\\lambda_t\\) implies higher correlation between the early visit response and final visit response.\n\n\n```ddqkfmcfhjlyc #| standalone: true #| viewerHeight: 1000\nlibrary(shiny) library(DT) library(ggplot2) library(htmltools)\nalignCenter <- function(el) { htmltools::tagAppendAttributes(el, style=“margin-left:auto;margin-right:auto;” ) }\nsketch = htmltools::withTags(table( class = ‘display’, thead( tr( th(rowspan = 2, ’‘), th(rowspan = 2, style = “border-right: solid 1px;”,’Observed Visit Data’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘B1 priors’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘B2 priors’), th(colspan = 2, class=” dt-center”, style = “border-right: solid 1px;”,‘BB priors’) ), tr( th(“mean”), th(style = “border-right: solid 1px;”, “SD”), th(“mean”), th(style = “border-right: solid 1px;”, “SD”), th(“center”), th(style = “border-right: solid 1px;”, “weight”), ) ) ))\nui <- fluidPage( tags\\(head(\n # Note the wrapping of the string in HTML()\n tags\\)style(HTML(” .my_col_class { align-content: center; }“) ) ),\ntitlePanel(h1(“Linear Regression LM Priors”, align = “center”)), alignCenter(sliderInput(“numVisits”, “Number of visits:”, min = 2, max = 20, value = 5, step = 1)), DTOutput(“dataInputTable”), h5(“Double click on a cell to edit.”, align = “center”), br(), titlePanel(h2(“Plot a subject’s prior predictive”, align = “center”)), fluidRow( #column(5, offset = 1, uiOutput(“slider”)), column(5, offset = 1, uiOutput(“slider”)), column(6, fluidRow( column(6, offset = 2, checkboxInput(“fixAlpha”, “Fix alpha at its mean?”, value = FALSE, width = “100%”)), column(6, offset = 2, checkboxInput(“fixBeta”, “Fix beta at its mean?”, value = FALSE, width = “100%”)), column(6, offset = 2, checkboxInput(“removePredictive”, “Remove endpoint prior predictive?”, value = FALSE, width = “100%”)) )) ), fluidRow( column(6, plotOutput(“visitToFinalPlot”)), column(6, plotOutput(“priorPredictive”)) )\n)\ngetLowerMedianUpper = function(earlyVisitVal, alpha = c(0,1), beta = c(0,1), lambda = c(1,1)) { distMeanFinal = c(alpha[1] + beta[1]earlyVisitVal, sqrt(alpha[2]^2 + beta[2]^2earlyVisitVal^2))\ndeviates = rnorm(10000) deviates = (deviates - mean(deviates))/(sd(deviates))\nif(any(is.na(lambda))) { samps = (deviatesdistMeanFinal[2] + distMeanFinal[1]) } else { samps = (deviatesdistMeanFinal[2] + distMeanFinal[1]) + rnorm(10000, 0, sd = sqrt(1/rgamma(10000, lambda[2]/2, lambda[1]^2*lambda[2]/2))) }\ndistValueFinal = c(mean(samps), sd(samps))\nreturn(list(“meanFinal” = data.frame(lower = distMeanFinal[1] + qnorm(.025)distMeanFinal[2], median = distMeanFinal[1], upper = distMeanFinal[1] + qnorm(0.975)distMeanFinal[2]), “predictionFinal” = data.frame(lower = quantile(samps,.025), median = median(samps), upper = quantile(samps,.975)))) }\nserver <- function(input, output, session) {\ndf = data.frame(VisitResponse = c(2,5,3,7,11), alphaPriorMean = 0, alphaPriorSD = 2, betaPriorMean = 1, betaPriorSD = 2, lambdaPriorCenter = 5, lambdaPriorWeight = 3) df[5,] = c(5, NA, NA, NA, NA, NA, NA) row.names(df) = paste(“Visit”, 1:5)\n## Render DF to actually change output\\(dataInputTable = renderDT(datatable(df,\n options = list(\n pageLength = 20,\n dom = \"t\",\n autoWidth = TRUE,\n columnDefs = list(list(className = 'dt-center', orderable = FALSE, width = '75px', targets = 0:7),\n list(width = \"150px\", targets = 0:1))\n ),\n container = sketch,\n rownames = TRUE,\n # escape = FALSE,\n selection = 'none',\n editable = list(target = \"cell\")\n ) |> formatStyle(c(1,3,5,7), `border-right` = \"solid 1px\") |>\n formatRound(1, digits = 4) |> formatRound(2:7, digits = 2) |>\n formatStyle(0,\n target = \"row\",\n backgroundColor = styleEqual(paste(\"Visit\",input\\)lastVisitWithData), “lightblue”, ‘white’)) )\n## Update from Conditional proxy = dataTableProxy(‘dataInputTable’)\nobserveEvent(input\\(dataInputTable_cell_edit, {\n info = input\\)dataInputTable_cell_edit i = info\\(row\n j = info\\)col v = info$value\nif(i < nrow(df) | j == 1) {\n df <<- editData(df, info)\n} else {\n df[i,j] <<- NA\n}\nreplaceData(proxy, df) \n})\nobserve({ nv = input$numVisits if(nv > nrow(df)) { tempd = df for(i in 1:(nv-nrow(df))) { tempd = rbind(tempd, setNames(data.frame(c(tempd[nrow(tempd),])), names(tempd))) rownames(tempd)[nrow(tempd)] = paste(“Visit”, nrow(tempd)) tempd[nrow(tempd)-1,-1] = tempd[nrow(tempd)-2,-1] } df <<- tempd } else if(nv < nrow(df)) { df <<- df[1:nv,] df[nv,-1] <<- NA } replaceData(proxy, df) })\nsliderParams <- reactiveValues(max = 5, value = 3) output\\(slider <- renderUI({\n sliderInput(\"lastVisitWithData\", \"Last complete visit:\", min = 1, max = sliderParams\\)max, value = sliderParams\\(value, step = 1)\n })\n observeEvent(input\\)numVisits, { sliderParams\\(max = input\\)numVisits if(!is.null(input\\(lastVisitWithData)) {\n sliderParams\\)value <- min(input\\(lastVisitWithData, input\\)numVisits) } else { sliderParams$value = 3 } })\noutput\\(priorPredictive = renderPlot({\n req(input\\)lastVisitWithData) input$dataInputTable_cell_edit\nlvIndex = input$lastVisitWithData\nfinalVisitIndex = input$numVisits\ntempDF = df\ndataToPlot = getLowerMedianUpper(tempDF[lvIndex,1],\n alpha = c(tempDF[lvIndex,2], ifelse(input$fixAlpha, 0, tempDF[lvIndex,3])),\n beta = c(tempDF[lvIndex,4], ifelse(input$fixBeta, 0, tempDF[lvIndex,5])),\n lambda = c(tempDF[lvIndex,6], tempDF[lvIndex,7]))\n\ntempDF$RowVisitIndex = 1:nrow(tempDF)\ntempDF$visitKnown = \"included\"\ntempDF$visitKnown[tempDF$RowVisitIndex > lvIndex] = \"excluded\"\n\n# tempDF = rbind(setNames(data.frame(c(tempDF[1,])), names(tempDF)), tempDF)\n# tempDF[1,1] = 0\n# tempDF$RowVisitIndex[1] = 0\n# rownames(tempDF)[1] = \"Baseline\"\n\np1 = ggplot() + \n geom_point(dat = tempDF, aes(x = RowVisitIndex, y = VisitResponse, color = visitKnown), size = 3) + \n scale_color_manual(breaks = c(\"included\", \"excluded\"), values = c(\"black\", \"gray70\"), guide = \"none\") +\n coord_cartesian(xlim = c(0, finalVisitIndex)) + \n scale_x_continuous(breaks = 0:finalVisitIndex, labels = c(\"Baseline\", 1:finalVisitIndex)) +\n xlab(\"Visit\") + ylab(\"Response\") + ggtitle(\"Predicting Final Endpoint of a Subject\") +\n theme_bw() + \n theme(plot.title = element_text(size = 20), text = element_text(size = 16), legend.justification = \"left\", legend.position = \"bottom\", legend.direction = \"vertical\")\n\nif(lvIndex < finalVisitIndex) {\n if(!input$removePredictive) {\n p1 = p1 + \n geom_segment(data = dataToPlot[[2]], aes(x = finalVisitIndex, y = lower, yend = upper), color = \"darkgreen\", linewidth = 2.5) +\n annotate(geom = \"point\", x = finalVisitIndex, y = dataToPlot[[2]]$median, color = \"darkgreen\", size = 3, shape = 18) +\n geom_ribbon(data = NULL, aes(x = c(lvIndex, finalVisitIndex),\n ymin = c(tempDF$VisitResponse[lvIndex], dataToPlot[[2]]$lower),\n ymax = c(tempDF$VisitResponse[lvIndex], dataToPlot[[2]]$upper),\n fill = \"preds\"), color = NA, alpha = .2)\n }\n p1 = p1 +\n geom_segment(data = dataToPlot[[1]], aes(x = finalVisitIndex, y = lower, yend = upper), color = \"darkblue\", linewidth = 1.5) +\n annotate(geom = \"point\", x = finalVisitIndex, y = dataToPlot[[1]]$median, color = \"darkblue\", size = 3, shape = 18) +\n annotate(geom = \"segment\", x = lvIndex, xend = finalVisitIndex, y = tempDF$VisitResponse[lvIndex], yend = dataToPlot[[1]]$median, linetype = \"dashed\", color = \"darkblue\")+\n geom_ribbon(data = NULL, aes(x = c(lvIndex, finalVisitIndex),\n ymin = c(tempDF$VisitResponse[lvIndex], dataToPlot[[1]]$lower),\n ymax = c(tempDF$VisitResponse[lvIndex], dataToPlot[[1]]$upper)),\n fill = \"darkblue\", color = NA, alpha = .4)\n} else {\n p1 = p1 + annotate(geom=\"text\", label = \"Final Visit Value Known\",\n alpha = .5, size = 10, x = (finalVisitIndex)/2, y = Inf, vjust = 1.3)\n}\n\np1 = p1 + scale_fill_manual(NULL, breaks = c(\"preds\"), limits = c(\"preds\"), values = c(\"darkgreen\"), labels = c(\"Prior predictive distribution for final endpoint of subject.\"))\n# guides(fill = guide_legend(override.aes = list(limits = c(\"darkgreen\", \"darkblue\"), labels = c(\"Prior distribution for mean of imputed value.\", \"Prior predictive distribution for final endpoint of subject.\")))) \n\np1\n})\noutput\\(visitToFinalPlot = renderPlot({\n input\\)dataInputTable_cell_edit req(input$lastVisitWithData)\nlvIndex = input$lastVisitWithData\nfinalVisitIndex = input$numVisits\n\ntempDF = df\n\nmin_s = ifelse(min(tempDF$VisitResponse, na.rm = TRUE) < 0, (min(tempDF$VisitResponse, na.rm = TRUE)+1)*1.1, 0)\nmax_s = ifelse(max(tempDF$VisitResponse, na.rm = TRUE) > 0, (max(tempDF$VisitResponse, na.rm = TRUE)+1)*1.1, 0)\n\ns = seq(min_s-5, max_s+5, length.out = 101)\n\nmeanDist_mean = tempDF$alphaPriorMean[lvIndex] + tempDF$betaPriorMean[lvIndex]*s\nif(!input$fixAlpha & !input$fixBeta) {\n meanDist_sd = sqrt(tempDF$alphaPriorSD[lvIndex]^2 + tempDF$betaPriorSD[lvIndex]^2*s^2)\n} else if(input$fixAlpha & !input$fixBeta) {\n meanDist_sd = sqrt(tempDF$betaPriorSD[lvIndex]^2*s^2)\n} else if(!input$fixAlpha & input$fixBeta) {\n meanDist_sd = rep(sqrt(tempDF$alphaPriorSD[lvIndex]^2), length(s))\n} else {\n meanDist_sd = rep(0, length(meanDist_mean))\n}\n\nplotDF = data.frame(earlyVis = s,\n lower = meanDist_mean + qnorm(0.025)*meanDist_sd,\n median= meanDist_mean,\n upper = meanDist_mean + qnorm(0.975)*meanDist_sd)\n\nif(lvIndex < finalVisitIndex) {\n if(!input$removePredictive) {\n numSamps = 2500\n \n deviates = rnorm(numSamps)\n deviates = (deviates - mean(deviates))/(sd(deviates))\n normigsamps = rnorm(numSamps, 0, sd = sqrt(1/rgamma(numSamps, tempDF$lambdaPriorWeight[lvIndex]/2, tempDF$lambdaPriorCenter[lvIndex]^2*tempDF$lambdaPriorWeight[lvIndex]/2)))\n \n distVals = matrix(NA, ncol = 2, nrow = length(s))\n for(i in 1:length(s)) {\n distVals[i,] = quantile((deviates*meanDist_sd[i] + meanDist_mean[i] + normigsamps), c(0.025, 0.975))\n }\n \n plotDF$lowerPred = distVals[,1]\n plotDF$upperPred = distVals[,2]\n }\n \n p2 = ggplot(data = plotDF) + geom_abline(aes(slope = tempDF$betaPriorMean[lvIndex], intercept = tempDF$alphaPriorMean[lvIndex]), color = \"darkblue\", linewidth = 1.5) + \n geom_ribbon(aes(x = s, ymin = lower, ymax = upper, fill = \"means\"), color = NA, alpha = 0.4)\n \n if(!input$removePredictive) {\n p2 = p2 + geom_ribbon(aes(x = s, ymin = lowerPred, ymax = upperPred), fill = \"darkgreen\", color = NA, alpha = 0.2) \n }\n p2 = p2 +\n coord_cartesian(xlim = c(min_s, max_s)) +\n xlab(\"Early Visit Known Value\") + ylab(\"Expectation of Final Visit Response\") + ggtitle(\"Expectation of Final Visit Given Early Visit\") +\n theme_bw() + \n theme(plot.title = element_text(size = 20), text = element_text(size = 16), legend.justification = \"right\", legend.position = \"bottom\", legend.direction = \"vertical\")\n} else {\n p2 = ggplot(data = NULL) + geom_abline(aes(fill = \"means\"), slope = 1, intercept = 0, color = \"darkblue\", linewidth = 1.5) + \n coord_cartesian(xlim = c(min_s, max_s), ylim = c(min_s, max_s)) +\n annotate(geom=\"text\", label = \"Final Visit Value Known\",\n alpha = .5, size = 10, x = (max_s + min_s)/2, y = Inf, vjust = 1.3) +\n xlab(\"Early Visit Known Value\") + ylab(\"Expectation of Final Visit Response\") + ggtitle(\"Expectation of Final Visit Given Early Visit\") +\n theme_bw() + \n theme(plot.title = element_text(size = 20), text = element_text(size = 16), legend.justification = \"right\", legend.position = \"bottom\", legend.direction = \"vertical\")\n}\np2 = p2 + scale_fill_manual(NULL, breaks = c(\"means\"), limits = c(\"means\"), values = c(\"darkblue\"), labels = c(\"Prior distribution for mean of imputed value.\")) \np2\n}) }\nshinyApp(ui = ui, server = server)```", "crumbs": [ "Concepts", "FACTS Tips and Tricks", @@ -1867,25 +1918,5 @@ "title": "FACTS 7.1.1 Release Notes", "section": "", "text": "1 Introduction\n\n\n2 FACTS Core and Staged Improvements\n\nIn Staged design, conditional power of current stage 2 when no control arm is carried to stage 2 is handled correctly." - }, - { - "objectID": "concepts/index.html#what-youll-find-here", - "href": "concepts/index.html#what-youll-find-here", - "title": "Concepts", - "section": "What You’ll Find Here", - "text": "What You’ll Find Here\n\nBasics of Clinical Trials: Learn the essentials, terminology, and best practices that define the clinical trial landscape. From study design and data collection to regulatory considerations, we’ll walk you through the elements that matter most.\nStatistical & Mathematical Fundamentals: Uncover the foundational concepts in statistics and mathematics that empower you to make data-driven decisions. Understand key analyses, Bayesian approaches, and appreciate why certain metrics and models are essential to reliable results.\nTips & Tricks for Using FACTS: Gain insider know-how that helps you work smarter and faster.", - "crumbs": [ - "Concepts" - ] - }, - { - "objectID": "concepts/index.html#how-to-make-the-most-of-this-section", - "href": "concepts/index.html#how-to-make-the-most-of-this-section", - "title": "Concepts", - "section": "How to Make the Most of This Section", - "text": "How to Make the Most of This Section\nUse the Concepts section as a springboard to build your expertise, whether you’re new to clinical trials or looking to refine your analytical skills. By solidifying your grasp of fundamentals and strengthening your analytical toolkit, you’ll be better equipped to understand results and ask the right questions. Check back often as we continue expanding these resources to support your growth.", - "crumbs": [ - "Concepts" - ] } ] \ No newline at end of file diff --git a/documentation/glossary.qmd b/documentation/glossary.qmd new file mode 100644 index 0000000..983d60a --- /dev/null +++ b/documentation/glossary.qmd @@ -0,0 +1,35 @@ +--- +title: "Glossary" +--- + +# Abbreviations + +@tbl-crmterms gives an overview of the acronyms and abbreviations used in the documentation. + +| Name | Definition | +|:-----------------------------------|:-----------------------------------| +| Cap | A limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap. | +| Control | Is the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness. | +| Core | FACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator. | +| CRM | Continual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD). | +| DE | Dose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed. | +| ED | Enrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications. | +| FACTS | Fixed and Adaptive Clinical Trial Simulator. | +| Final Endpoint | The final value, or state, of a subject’s endpoint. | +| GUI | Graphical User Interface, the part of the FACTS application that the user interacts with. | +| Method | In the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below. | +| Model | In the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this. | +| MTD | The dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD). | +| MTD+ | The dose most likely to be the MTD+ – the dose with the highest Pr(MTD+). | +| Pr(MTD) | A dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses. | +| Pr(MTD+) | A dose's probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range. | +| Profile | A profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations. | +| Response | The change in a subject’s endpoint compared to their baseline state. | +| Scenario | A scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include:
    -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups
    -) the properties of subjects’ early responses and the correlation with their final outcome
    -) the rate at which subjects are recruited into the trial
    -) the rate at which subjects drop out of the trial. | +| SPEC | The Design Engine Specification, describes the system algorithms, and meaning of parameters. | +| Response | The change in a subject’s endpoint compared to their baseline state. | +| Subject | Someone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers. | +| Treatment Arm | Subjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared. | +| UG | The User Guide; describes how to use the system. | + +: List of terms used in the user guides {#tbl-crmterms .striped .hover tbl-colwidths="\[15,85\]"} \ No newline at end of file diff --git a/documentation/index.qmd b/documentation/index.qmd index 0385852..3ccec65 100644 --- a/documentation/index.qmd +++ b/documentation/index.qmd @@ -1,36 +1,18 @@ --- title: "Documentation" -subtitle: "FACTS 7.1.1" +subtitle: "Your Comprehensive Resource for Understanding and Using Our Software" --- -Home page for Documentation. +Welcome to the Documentation section — your go-to repository of in-depth user guides and practical examples that illuminate every aspect of FACTS. Whether you’re just getting started or delving into advanced functionalities, these resources are designed to help you navigate our software with confidence and ease. -@tbl-crmterms gives an overview of the acronyms and abbreviations used in the documentation. +## What You’ll Find Here + +- User Guides: Access detailed manuals covering the full range of our engines. From foundations to advanced features, learn how to set up your desired trial design, learn about best practices and obtain focused understanding of the subject matter, and troubleshoot common issues. +- Installation Instructions: Get up and running quickly with clear guidance. Our installation resources walk you through every phase—downloading the software, deploying it in various environments, and start FACTSing! +- Examples: Explore a range of constructed and real-world studies that demonstrate our software’s capabilities in action and discover strategies to optimize performance. + +## How to Get the Most Out of This Section + +This section contains resources for the current and past versions of FACTS, which you can choose in the sidebar. If necessary, begin by reviewing the installation guides. Later, you may consult engine-specific user manuals for deeper insights, and explore our curated examples to bring theory into practice. With these resources at your fingertips, you’ll gain a richer, more informed understanding of FACTS and maximize your potential for success. -| Name | Definition | -|:-----------------------------------|:-----------------------------------| -| Cap | A limit on the number of subjects recruited. In FACTS N-CRM users can specify a cap on the overall number of subjects to be recruited in the trial (the ‘Overall Cap’) and specify stopping rules to define when the trial should stop before it reaches cap. | -| Control | Is the treatment arm with which the novel treatment(s) are principally being compared. Control may be placebo, or some existing standard of care, or therapy, against which the novel treatment has to be benchmarked in order to determine its likely usefulness. | -| Core | FACTS Core: A mode of FACTS for designing trials where multiple treatments, (possibly different doses of a novel treatment) are tested against a control and optionally an active comparator. | -| CRM | Continual Reassessment Method – a dose escalation design where the dose-toxicity is estimated using a simple Bayesian model, and the resulting estimates used to control the dose escalation and estimate the Maximum Tolerated Dose (MTD). | -| DE | Dose Escalation: a mode of FACTS where subjects are treated in cohorts and dose escalation is determined by the number of toxicities observed. | -| ED | Enrichment Designs: a mode of FACTS for designing trials where the same treatment is testing in different settings for example different sub-populations or different but related indications. | -| FACTS | Fixed and Adaptive Clinical Trial Simulator. | -| Final Endpoint | The final value, or state, of a subject’s endpoint. | -| GUI | Graphical User Interface, the part of the FACTS application that the user interacts with. | -| Method | In the FACTS documentation we try to reserve the term ‘method’ for the algorithms used in the simulation (as opposed to the analysis) part of the program. In the analysis part we use the term ‘Model’, see below. | -| Model | In the FACTS documentation we try to reserve the term ‘model’ for the statistical models used in the analysis of the trial data (in the ‘design’ section of the FACTS user interface). Where mathematical algorithms are used for other purposes in FACTS (for instance in the generation of the simulated data) we try to use the term ‘method’. We have found that initially it is very easy for users to be confused between these two parts of FACTS and we feel that using distinct terminology may help to reduce this. | -| MTD | The dose most likely to be the Maximum Tolerated Dose (MTD) – the dose with the highest Pr(MTD). | -| MTD+ | The dose most likely to be the MTD+ – the dose with the highest Pr(MTD+). | -| Pr(MTD) | A dose’s probability of being MTD is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable toxicity band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. This estimate of MTD is constrained to select one of the available doses. | -| Pr(MTD+) | A dose's probability of being the MTD+ is the probability that it is the dose with the highest probability of having a toxicity rate in the acceptable band, and (if a threshold has been specified) does not have a probability of excess or unacceptable toxicity above the threshold. Unlike Pr(MTD), Pr(MTD+) includes estimating whether a dose below or a dose above the range of those being tested is more likely to have a toxicity in the acceptable band than any of the doses in the range. | -| Profile | A profile is a specification of one aspect of a scenario. A scenario is made up of one profile of each of the required types for the type of trial being simulated. FACTS allows the user to specify multiple profiles of each type and then presents all the possible combinations of profiles as scenarios that can be used to drive simulations. | -| Response | The change in a subject’s endpoint compared to their baseline state. | -| Scenario | A scenario is the complete specification of the unknown external factors that determine the data observed on the trial and its timing. The exact factors depend on the type of trial being simulated but typically include:
    -) the distribution of the final change from base line, or probability of response or rate of events in the different treatment groups
    -) the properties of subjects’ early responses and the correlation with their final outcome
    -) the rate at which subjects are recruited into the trial
    -) the rate at which subjects drop out of the trial. | -| SPEC | The Design Engine Specification, describes the system algorithms, and meaning of parameters. | -| Response | The change in a subject’s endpoint compared to their baseline state. | -| Subject | Someone recruited onto a clinical trial for the purposes of learning about the properties of a treatment. Depending on the type of trial they might be patients or they might be healthy volunteers. | -| Treatment Arm | Subjects on entering the study are randomized to different ‘treatment arms’. Subjects randomized to the same arm receive the same treatment and the responses of the subjects in the arm analyzed to determine the expected response to that treatment, allowing the expected responses to the different treatments to be compared. | -| UG | The User Guide; describes how to use the system. | -: List of terms used in the user guides {#tbl-crmterms .striped .hover tbl-colwidths="\[15,85\]"} diff --git a/releaseNotes/index.qmd b/releaseNotes/index.qmd index 99176c1..0abb43a 100644 --- a/releaseNotes/index.qmd +++ b/releaseNotes/index.qmd @@ -1,6 +1,6 @@ --- title: "Release Notes" -subtitle: Stay Informed About New Features, Improvements, and Fixes +subtitle: "Stay Informed About New Features, Improvements, and Fixes" --- Welcome to our section on FACTS Release Notes — your go-to source for detailed information on what’s new in each version of FACTS. Whether you’re curious about the latest capabilities, need to verify that a known issue has been resolved, or just want to keep a pulse on how our solution is evolving, this is the place to start.