The Phoenix Reporter

A Compendium of Insightful Information for Our Phoenix Community, Vol. 3

Welcome to The Phoenix® Reporter. In this e-newsletter, we will share informative educational content along with practical, implementable resources with our Phoenix user community.

This issue provides an overview of the new features and enhancements in Phoenix 8.0, the newest version of our PK/PD software:

  1. Phoenix WinNonlin 8.0—Taking NCA to a New Level
  2. Validation Suite 8.0—Integrated and Fast Validation for WinNonlin Implementation
  3. Phoenix NLME 8.0—Automatic Parallelization and Distributed Delay Function for Modeling Delayed Outcomes
  4. Phoenix Workbench—Easier PK/PD Analysis and New QA/QC Features

Phoenix WinNonlin 8.0—Taking NCA to a New Level

Based on valuable input from our Phoenix community, significant advances have been made to the Phoenix WinNonlin® NCA engine, including the addition of new business rules for terminal slope (Lambda Z) calculation and acceptance flags based on terminal slope quality assessments. In addition, many commonly calculated NCA parameters for plasma and urine have been added to the standard output, and the ability to define custom NCA parameters. These new features minimize post-processing work and increase transparency with analysis.

New Business Rules for Lambda Z Best Fit Calculation

The Lambda Z best fit rules have been implemented directly in the updated NCA engine. The new rules include the ability to specify the maximum number of points to include in the regression and the earliest time for samples to be taken. These rules are only applicable for the pharmacokinetic estimation of Lambda Z and not for the drug effect model. Settings are retained and can be reviewed for compliance with organization policies and procedures.

Lambda Z Best Fit—Setting “Start Time Not Before”

As shown in the above plot on the left, when no rule is set for Start Time Not Before, the slope extends all the way back to the 45 minute time point. On the right, when the Start Time Not Before is set to 120 minutes, the slope stops at the set time point. This feature might be useful when you have a modified or extended release formulation and you want to ensure that the terminal slope is only calculated after a drug has been completely absorbed or absorption has stopped.

Lambda Z Acceptance Criteria

Another new business rule for Lambda Z calculation is the ability to flag values that are related to the Lambda Z that may or may not meet the SOP criteria including:

  • the adjusted R2
  • the observed or predicted % extrapolated AUC
  • Span (sampling interval/t1/2)

When acceptance criteria are set, a new “flag” column is created in the output that indicates the status of the parameter as either Accepted—criterion was met, Not Accepted—criterion was not met, Insufficient Data, or Missing—not calculated.

Setting the Acceptance Criteria

The acceptance criteria display provides the ability to easily filter out the subjects, or the profiles, that either meet or don’t meet the acceptance criteria.

New PK and User-defined Parameters

New PK parameters for plasma and urine have been added to the standardized output, and several existing parameters have been renamed for clarity. In addition, users now have the ability to define their own parameters—as a function of NCA final parameters (default or preferred names) and Carry Column, Dose, and Tau (from external worksheets)—with the option to merge Final Parameters outputs.

New PK Parameters

Plasma Matrix

  • Swing
  • Swing_Tau
  • %Fluctuation
  • %Fluctuation_Tau
  • Clast_pred
  • Ctau (obs and pred)
  • Span
  • AUClast_D
  • AUC_Tau_D
  • AUC_Tau_%Extrap
  • Lambda_z_intercept
  • N_Samples
  • Dose
Urine Matrix

  • Rate_last_pred
  • AURC_last_D
  • N_samples
  • Dose

Validation Suite 8.0—Integrated and Fast Validation for WinNonlin Implementation

As required by US FDA’s 21 CFR Part 11, International Conference on Harmonization of Technical Requirements (ICH), EudraLex Annex 11, and other regulatory agency guidance documents, computer systems used in the pharmaceutical industry and output from software used in regulatory submissions must be validated to assure proper performance. This necessitates companies to invest significant time and resources to manually write and perform the validation steps used in software execution. Phoenix WinNonlin Validation Suite 8.0 provides objective evidence of Phoenix WinNonlin 8.0 functionality. It streamlines the validation process through automated tests accessed through a graphical user interface and validation document templates.

Prior to the current launch of Phoenix 8.0, Validation Suite for WinNonlin was available only as a standalone application. Validation Suite is now fully integrated into the Phoenix application, eliminating the need for a separate installation. Validation Suite has been updated to significantly reduce the runtime to execute a validation. A separate license is still required to run the Validation Suite for WinNonlin, but once the license is obtained, the validation menu can be accessed directly within Phoenix.

Previous versions of Validation Suite could take up to 48 hours to fully execute. In addition, the application would completely tie up the computer on which the validation was being executed. Validation Suite 8.0 now completes a validation in less than 30 minutes and allows other applications, eg, Microsoft® Office, email, and web browsers, to be used simultaneously. Validation history reports are stored as Microsoft Word documents in Phoenix 8.0 and immediately accessible for easy reference.

Detailed test scripts are automatically executed, ensuring rapid, consistent, and error-free testing of WinNonlin 8.0 functionality

Phoenix NLME 8.0—Automatic Parallelization and Distributed Delay Function for Modeling Delayed Outcomes

Two major enhancements have been made in Phoenix NLME: automatic parallelization on remote grids, and the addition of a distributed delay function. The new parallelization feature is for almost all run modes and offers the ability to run on powerful remote compute platforms, reducing run times from days to minutes. The new distributed delay function, useful for modeling delayed outcomes in therapeutic areas such as oncology, diabetes, and arthritis, simplifies coding delays in PK/PD models.

Run Faster Models with Automatic Parallelization

In Phoenix 7, we introduced the ability to run Phoenix NLME jobs on remote grids for two scenarios directly from the desktop application. In Phoenix NLME 8.0, we have expanded the capability to execute all scenarios in parallel across the maximum possible cores, and supports all NLME run modes except Sim/Predictive Check. Two types of parallelization are also included: between model parallelization, which allows for running all models simultaneously in parallel on different processors and, within model parallel action using computation grids. In this scenario, the analysis work for one model can be divided between several CPUs. For example, if you have a single estimation run and want to parallelize that and use 20, 30 or more cores to run one estimation model, you can use computation grids with hundreds of processors to get analysis done in a fraction of the time. The two types of parallelization approaches can also be combined, enabling models to be run in parallel and on multiple cores, reducing model run times by 80-90%. This enables completion of analysis and scientific exploration in real time, allowing scientists to revise their hypothesis, if necessary, and move on to the next step.

Regardless of approach, no intervention or user input is needed to execute a model on a grid—Phoenix will automatically determine the optimal number of cores needed to run the model in the minimal amount of time. Phoenix NLME calculates the number of cores to use by taking the smaller value of either the number of cores or the number of subjects in a model, divided by three. For example, in a simple, no sort run mode, if you have a 360-core grid and are running a model with a dataset having 300 subjects, the estimation run will be parallelized across 100 cores (300 divided by three). For any run mode, Phoenix NLME considers type of run mode (simple +/- sort, scenarios +/- sort, covariate search, boot-strap), the number of subjects, models and the number of available cores, to determine the optimal core utilization.

Phoenix NLME Parallelization Remote Grids

Run Mode No. of Subjects No. of Models No. of Cores Utilization of Cores
Simple, No Sort 300 360 1 x 100 Cores (300/3)
Simple 400/Sort 3 Unique Sorts 360 120 Cores/Sort (360/3)
Scenarios, No Sort 300/Scenario 6 Scenarios 360 60 Cores/Scenario (360/6)
Scenarios, 3 Sort Keys 200/Sort/Scenario 18 (6 Scenarios & 3 Sort Keys) 360 20 Cores/Sort/Scenario (360/(3*6))
Covariate Search, Forward Addition 300 Round 1–9 (Base + 8 Covariates) 360 40 Cores/Covariate (360/9)
Covariate Search, Backward Deletion 300 3 Covariates (From Final Model) 360 100 Cores/Covariate (300/3)
Covariate Search, Shotgun 300 6 Covariates/Parameter Relationships 360 5 Cores/Model (360/26)
Boot-strap 200 500 Replicates 360 66 Cores First Run, 1 Core/Replicate

Phoenix NLME can also be paired with Certara’s Burstable Compute Grid, which offers access to up to 1,800 cores with just one click, accelerating model runs affordably and without IT support. Projects that took days, can now be completed in hours or even minutes.

NLME Distributed Delay Function

In Phoenix 7, we added simplified coding to allow discrete delays to occur. In NLME 8.0, we’ve expanded this and added an additional parameter to allow for distribution of the delay time as opposed to a discrete delay time. This methodology can be used to replace transit compartments, dual absorption models, effect compartment models, or even indirect response models, providing a more accurate evaluation of these models. The fully integrated discrete and distributed delay functions are fully automated, eliminating the need to add complex lines of code. A delay function can be added with a single Phoenix Modeling Language (PML) command, avoiding inefficient workarounds and approximations.

Phoenix Workbench—Easier PK/PD Analysis and New QA/QC Features

Several enhancements have been made to the Phoenix workbench making it easier to conduct PK/PD analysis and help reduce errors. The new framework features applied across the Phoenix applications—WinNonlin, NLME, IVIVC—include the ability to lock workflows, increased flexibility to work with object settings, and integrated local license activation that no longer requires having to use a licensing wizard.

Maintain Consistency and Facilitate QC Efforts

QC and QA efforts for Phoenix templates are simplified with the ability to apply a password to lock workflow objects. Locked workflows can be executed but not modified. This new feature safeguards against changes being made and eliminates the painstaking QC process that was previously required. In addition, locking standardized analyses prevents not only prevents them from being changes, but also ensures that the same techniques were used every time without having to go back and do the tedious checking of all the feature sets.

The ability to load and save object settings is now available and represents a new “take” on how individual templates for objects were set in previous versions of Phoenix. This new setting—renamed Object Settings—is accessed directly from an object settings window. For example, a library of settings for each operational object can be created, eg, a specific set of customized models in Phoenix modeling, or plots that have been labeled in a certain font size and direction, can be saved and pulled up with a single click. Users can also add, remove, share, or rename saved settings.

The final advance made to the Phoenix framework is the ability to conveniently install and activate licenses within Phoenix 8.0 without having to install a helper application or install wizard. This feature is applicable if you have a local license installed on the same computer that Phoenix is installed.

Want to learn more about Phoenix 8.0? Check out our scientific webinar given by Dr. Nathan Teuscher that provides an overview and a demo of all the new features in Phoenix 8.0. Interested in getting Phoenix? Download now >


Tips of the Trade

Here are some tips for Phoenix NLME users on how delay differential equations can be used as a new pharmacometrics tool. Learn More >


Following is a compendium of scientific articles and information to augment your knowledge on topics highlighted in this issue.

Published Articles

  1. Krzyzanski, W. (2014).Interpretation of transit compartments pharmacodynamic models as lifespan based indirect response models. J Pharmacokinet Pharmacodyn 38:179-204.
  2. Koch G, Krzyzanski W, Pérez-Ruixo JJ, & Schopp J. (2014). Modeling of delays in PKPD: classical approaches and a tutorial for delay differential equations. J Pharmacokinet Pharmacodyn 41:291-318.
  3. Mo G, Gibbons F, Schroeder P, & Krzyzanski W. (2014). Lifespan based pharmacokinetic-pharmacodynamic model of tumor growth inhibition by anticancer therapeutics. PLoS ONE 9 (10): e109747.
  4. US Department of Health and Human Services, Food and Drug Administration. (2014, December). Providing regulatory submissions in electronic format: standardized study data. Guidance for the industry.
  5. Liu X & Wang Y. (2016). Comparing the performance of FOCE and different expectation maximization methods in handling complex population physiologically-based pharmacokinetic models. J Pharmacokinet Pharmacodyn 43:359-370.
Blog Posts

Upcoming Webinars

Archived Webinars

Community Forum

Become a member of the Phoenix Forum, a site dedicated for our Phoenix software community. In the forum, members can pose questions to our experts and interact with their peers – it is an excellent source to gain and share knowledge, experience and ideas. The forum is also a site to download software, check on licensing, and submit Phoenix software support requests.

Resource Library

Your source for all Certara information including case studies, white papers, blog posts, webinars, articles, posters, brochures, and press releases. Visit the Library >

Information from Certara on topics contained in this issue:

Learn from the Best

Become a “More Valuable Player” by enrolling in a Certara University pharmacometrics course:
8 modeling and simulation course topics
On-site courses given in over 15 cities
Online, e-learning course library
See the full schedule >
Phoenix Modeling Language (PML) School is a complementary webinar tutorial program that features topics submitted to our Phoenix Forum by users interested in developing custom PK/PD models. Join our instructors and guest lecturers for this educational series.

Upcoming PML School Presentations

Introduction to NONMEM-NLME Comparison
February 8, 2018
10am ET
Presenter: Bernd Wendt
February 22, 2018
10am ET
Presenter: Bernd Wendt
March 8, 2018
10am ET
Presenter: Venkateswari Muthukrishnan
TMDD Model Translated from NONMEM (NM-TRAN) to Phoenix NLME (PML)
March 22, 2018
10am ET
Presenter: Loan Pham, Camargo
See the full schedule and learn how to access prior tutorials >

Previous Issues

Learn More LinkedIn Twitter Facebook Email