Phoenix WinNonlin Va.. - Pharsight Corporation

Computer System Validation Discussion 

July 2010

Why Do I Need to Validate WinNonlin (or anything else)? 

21 CFR Parts 210 & 211 - cGMP regulations, effective in the 1960’s: 

211.68(a) - “Computers….shall be routinely calibrated, inspected, or 

checked according to a written program designed to assure proper 

performance.” 211.68(b) - “[with computerization or other automated 

processes], a written record of the program shall be maintained along 

with appropriate validation data.” 

21 CFR Part 820 - Quality System regulation (applicable to software used in 

devices and any part of the quality system) effective 01 June 1997: 

“When computers or automated data processing systems are used as part 

of production or the quality system, the [user] shall validate computer 

software for its intended use according to an established protocol.” 

21 CFR Part 11 - Electronic records, electronic signatures regulation effective 

20 March 1997: 11.10(a) - Computer systems used to create, modify, and 

maintain electronic records and to manage electronic signatures must be 

“validated to ensure accuracy, reliability, consistent intended 

performance, and the ability to discern invalid or altered records.”

Why Validate? - continued 

Guidance for Industry: Computerized Systems Used in Clinical Trials 

- effective April 1999: VIII.B.1. - “The sponsor or contract 

research organization should have documentation (either original 

validation documents or on-site vendor audit documents) of this 

design level validation by the vendor, and should have itself 

performed functional testing (e.g., by use of test data sets) and 

researched known software limitations, problems, and defect 

corrections.” 

ICH regulatory guidelines - 

• Good Clinical Practice (GCP) (E6) 

• Statistical Principles for Clinical Trials (E9)

Why Validate? - continued 

The FDA offers a guidance document (a document which describes the 

FDA’s current thinking on a topic, but which is not law): 

General Principles of Software Validation; Final Guidance for Industry 

and FDA Staff, Issued 11 January 2002 by the FDA Center for Devices 

and Radiological Health 

Because it makes good business sense by ensuring quality, timeliness, and 

efficiency, and by effectively addressing business risks. 

• “A documented requirements specification represents the user’s needs and 

intended uses. The goal of computer system validation is to demonstrate that the 

computer system meets all documented requirements.” 

• “Computer system validation is a critical tool used to assure the quality of a 

computer system. Validation can increase the usability and reliability of the 

computer system. Validation can also reduce long term costs by making it easier 

and less costly to reliably modify software and revalidate software changes.”

Validation Terminology - General Principles of Software 

Validation guidance document 

“Software verification provides objective evidence that the design outputs 

of a particular phase of the software development life cycle meet all of 

the specified requirements for that phase. Software verification looks for 

consistency, completeness, and correctness of the software and its 

supporting documentation, as it is being developed, and provides support 

for a subsequent conclusion that software is validated.” 

“For purposes of the guidance document, FDA considers software validation 

to be "confirmation by examination and provision of objective evidence 

that software specifications conform to user needs and intended uses, 

and that the particular requirements implemented through software 

can be consistently fulfilled.” Since software is usually part of a larger 

hardware system, the validation of software typically includes evidence 

that all software requirements have been implemented correctly and 

completely and are traceable to system requirements.”

Validation Terminology – Background - General Principles of 

Software Validation guidance document 

“For many years, both FDA and regulated industry have attempted to 

understand and define software validation within the context of 

process validation terminology. For example, industry documents 

and other FDA validation guidance sometimes describe user site 

software validation in terms of installation qualification (IQ), 

operational qualification (OQ) and performance qualification 

(PQ).” 

“While IQ/OQ/PQ terminology has served its purpose well and is one 

of many legitimate ways to organize software validation tasks at 

the user site, this terminology may not be well understood among 

many software professionals, and it is not used in the guidance 

document. However, both FDA personnel and device[/software] 

manufacturers need to be aware of these differences in 

terminology as they ask for and provide information regarding 

software validation.”

Validation Terminology - FDA Office of Regulatory Affairs Glossary of 

Computerized System and Software Development Terminology 

Installation Qualification (IQ): (FDA) Establishing confidence that process 

equipment and ancillary systems are compliant with appropriate codes 

and approved design intentions, and that manufacturer's 

recommendations are suitably considered. 

Operational Qualification (OQ): (FDA) Establishing confidence that process 

equipment and sub-systems are capable of consistently operating within 

established limits and tolerances. 

Process Performance Qualification (PQ) - (FDA) Establishing confidence that 

the process is effective and reproducible. 

Product Performance Qualification (PQ) – (FDA) Establishing confidence 

through appropriate testing that the finished product produced by a 

specified process meets all release requirements for functionality and 

safety.

Software Validation vs. Computer System Validation 

As a provider of software that is used by FDA-regulated customers, Pharsight 

Corporation develops software products in accordance with a documented 

software development life cycle (SDLC). In each of the phases of this life 

cycle, documentation deliverables are created, including Software 

Requirements Specifications, Design Specifications, Test Plans, Test 

Cases, and Traceability Matrices. These documents serve to document 

the development and testing of individual software products and contain 

proprietary information. At the end of the SDLC, Quality Assurance 

approval of the Release Approval/Validation Completion form completes 

Pharsight’s validation of the software product. 

Pharsight customers use Pharsight software products in the implementation of 

computer systems in FDA-regulated environments. To be compliant with 

FDA expectations, customers must validate the computer system, of which 

the software is but one component, along with the hardware (servers and 

workstations), network and operating systems environment, interfaces 

with other computer systems, and policies/standard operating 

procedures. Validation of the computer system must occur in the user’s 

environment and must account for the user’s unique set of user and 

functional requirements.

Computer System Validation - General Principles of Software 


From a customer’s point-of-view, Pharsight software is not validated. 

In order to be compliant with FDA expectations, companies must validate computer 

systems, of which the software is but one component. Validation of the computer 

system must occur in the user’s environment and must account for the user’s 

unique set of user and functional requirements. 

“When the software is developed by someone other than the [user] (e.g., off-the-shelf 

software), the software developer may not be directly responsible for compliance 

with FDA regulations. In that case, the party with regulatory responsibility (i.e., 

the [user]) needs to assess the adequacy of the off-the-shelf developer’s activities 

and determine what additional efforts are needed to establish that the software is 

validated for the [user’s] intended use.” 

“The [user] is responsible for ensuring that the product development methodologies 

used by the off-the-shelf software developer are appropriate and sufficient for the 

[user’s] intended use of the software. The [user] should consider auditing the 

vendor.”

How Do I Perform Computer System Validation? 

The FDA offers a guidance document (a document which describes 

the FDA’s current thinking on a topic, but which is not law). 

General Principles of Software Validation; Final Guidance for Industry and FDA 

Staff, Issued 11 January 2002 by the FDA Center for Devices and Radiological 

Health: Applicable to the validation of medical device software or the validation 

of software used to design, develop, or manufacture medical devices. Based on 

generally recognized software validation principles and, therefore, can be applied 

to any software. No final guidance documents issued by CDER or CBER. 

Outlines a Validation Life Cycle similar to a Software Development Life Cycle: 

“[Customers] should develop a validation life cycle model that is appropriate for 

their computer systems and organization.” Validation activities will be governed 

by a customer’s Corporate Quality System Policy, Corporate Validation Policy, 

System Implementation Policy, etc.

Validation Life Cycle Activities 

A typical validation life cycle would include the following activities, with associated 

deliverables: 

• Validation planning - Validation Plan*, aka Validation Master Plan, Project Plan, System Plan, 

others? 

• Requirements definition – Requirements Specification*, aka User Requirements Specification, 

Functional Requirements Specification, System Requirements Specification, others? 

• Design definition – probably not applicable for PHX WNL, Connect, NLME 

• Configuration/construction of custom code – probably not applicable for PHX WNL, Connect, 

NLME 

• Testing (User Site Testing, aka System Testing, Functional Testing, Site Validation, 

Installation Qualification, Operational Qualification, Performance Qualification, Installation 

Testing, Installation Verification, User Acceptance testing, Site Acceptance Testing, Validation 

Testing, others?) - Test Plan*, aka Installation Qualification Protocol, Operational 

Qualification Protocol, Performance Qualification Protocol, Validation Protocol; Test 

Scripts**, aka Test Cases; Run Report***, aka Testing Summary Report, Installation 

Qualification Report, Operational Qualification Report, Performance Qualification Report, 

others?; Traceability Document, Traceability Matrix. 

• Implementation - Validation Summary Report*, aka System Acceptance Report, others? 

* - template included in the Validation Suite 

** - test scripts, mostly automated, included in and executed by the Validation Suite 

*** - produced by the Validation Suite after execution of test scripts

Validation Misconceptions - General Principles of Software 


“I can’t use validation information from a vendor” - “A [user] may 

conduct a validation using their own personnel or may depend 

upon a third party such as the equipment/software vendor or a 

consultant. In any case, the [user] retains the ultimate 

responsibility for ensuring that the software is validated.” 

“I have to validate all of the functionality in a product” - “A [user] 

“I have to validate all of the functionality in a product” - “A [user] 

who chooses not to use all the vendor-supplied capabilities of the 

software only needs to validate those functions that will be used 

and for which the [user] is dependent upon the software results as 

part of production or the quality system.

Walk Through Phoenix ® WinNonlin ® Validation Suite 

© Tripos, L.P. All Rights Reserved

Phoenix ® Validation Suite 

Pharsight has developed a new Validation 

Suite framework for the Phoenix platform 

that will deliver transparent and 

customizable test packages, quickly, for all 

products developed internally or externally. 

© Tripos, L.P. All Rights Reserved Slide 14

What is the Phoenix ® WinNonlin ® Validation Suite ? 

Phoenix ® WinNonlin ® Validation Suite is a desktop application that 

contains a set of detailed test scripts for use in the validation of 

Phoenix ® WinNonlin ® version 6.1. 

The Phoenix ® WinNonlin ® Validation Suite automatically drives 

Phoenix ® WinNonlin ® using the same UI controls a user does. It 

compares the generated output to verified reference output, and 

reports the results in Microsoft Word. 

The current release of the Phoenix ® WinNonlin ® Validation Suite 

contains 184 automated validation routines for use in the validation 

of Phoenix ® WinNonlin ® version 6.1. 

Tests plans can be created using a subset of the 184 supplied scripts 

and/or custom (client defined) scripts. 


Key Benefits 

● 

● 

● 

● 

● 

● 

Ensures that your Phoenix ® WinNonlin ® is functioning as intended 

Saves time and reduces errors with automated testing 

Reduces labor for validation personnel as test scripts, input 

datasets, reference output, and validation life cycle document 

templates are all included 

Allows for customized test plans and/or test scripts giving testing 

personnel full control of the testing process 

Upgrading is free for all customers who have paid for their 

current maintenance agreements 

• Easier re-validation when you upgrade to new versions of Phoenix WinNonlin 

Monitors validation status in real-time and notifies the user if any 

“material” changes have occurred (optional) 


Document Templates provided with 

Phoenix ® WinNonlin ® Validation Suite 

Four Microsoft Word templates are included with Phoenix ® WinNonlin ® 

Validation Suite as a starting point for common validation life cycle 

documents. 

These include: 

• Validation Plan template 

(PHX WNL Val Suite 2.0 Validation Plan Template.doc) 

• Phoenix ® WinNonlin ® 6.1 Requirements Specification template 

(Phoenix WinNonlin 6.1 Requirements Specification template.doc) 

• Test Plan template (PHX WNL Val Suite 2.0 Test Plan Template.doc) 

• Validation Summary Report template 

(PHX WNL Val Suite 2.0 Validation Summary Report Template.doc) 

These documents are located at: 

C:\Program Files\Pharsight\Validation Suite 2.0\WNL Package\Documentation 


How It Works 

1. Start the application 

Start>All Programs>Pharsight>Validation Suite 2.0> WNL Package>WNL 6.1 Validation 


How It Works 

2. If first time using 

the Validation suite, 

one must add a 

license. 

3. Select 

Tools>Options and 

either select a 

Network license or 

click on Install Node 

License and enter a 

license code 


How It Works 

4. Open a test package via File > Open Test Package 

5. Select WNL.pjs (c:/program files>pharsight/Validation Suite 

2.0/WNL Package/WNL.pjs) 


How It Works 

6. You can also set file location Options or Suite Variables that will 

affect the performance of the Validation Suite (Tools>Suite 

Variables) 

A multiplier used to increase the wait time 

between automation events. 

Saves Phoenix projects after test completion. 

Location where logs are written during test runs. 

Number of times to retry a test if it fails 

Location where temp files are saved 

Cannot be changed 

Controls ability to select or clear test check boxes. 

Location where reports are saved 

Controls ability to take screenshots during runs. 

Milliseconds to wait until a GUI interface is displayed 

Location where screenshots are saved 

Run in debug mode. 

Suite Variables changes must be done before execution of a 

package 


How It Works 

7. The test package displays 

all the scripts available to 

run. The user can select 

the scripts that should be 

executed. The computer 

cannot be used during the 

execution. 

8. Environment_Setup> 

VS2_WNL_SETUP test set 

(IQ) must be run at least 

once before executing any 

other script. 


How It Works 

9. When a Test package or Plan is loaded, or when all required 

validation tests are selected, users can run the validation tests. 

10. Click the Run button to run the validation tests. 

Do not use the test computer during a validation run. The Phoenix WinNonlin Validation Suite 

automates Phoenix WinNonlin processes that are sensitive to keystrokes and mouse clicks. 

Note that one can stop validation runs but they cannot be paused. 

Click the Stop button or press SHIFT+F3 to stop the test script 

execution. 

If a validation run is stopped, users MUST RUN the tests again. 


The Console Panel 

The Console tab lists all the actions taken by Validation Suite users. 


The Results Panel 


The Show Log Panels 






The Summary Results Panel 


The Microsoft Word Run Report 

Select Location and Name of the report 


(Optional) Test Plans 

1. Optionally, the user can create a customized test plan to test the 

functionality of Phoenix ® WinNonlin ® that is intended to be 

used. A test plan can consists of any subset of the 184 scripts 

provided by Pharsight and/or also include customized scripts. 

2. To create a test plan the user selects the scripts to be included in 

a test plan and then selects Save in the File menu 

3. In the Save As dialog, name the Test Plan. Test Plans are saved 

with the extension .vstp. 

4. To use a test plan, in the File menu select Open Test Plan. Select 

the Test Plan file in the Open File dialog.

(Optional) Test Plans 

5. Users can create their own 

tests/scripts. Individual 

tests can be exported and 

edited (3 rd -party software 

required) and then run 

within the Val Suite. 

Any of the supplied test scripts can be exported, edited, and run allowing 

users the ultimate control over what they choose to validate. 


The Validation Suite Monitor 

The Validation Suite also contains a tool that can be 

optionally used. This tool (Validation Suite Monitor) 

constantly monitors the state of validated computer 

systems to determine if any element of the computer's 

configuration has changed since it was validated. If a 

material change (as defined by the user) has taken place, 

a flag in the computer's system tray will alert the user. 



The Validation Suite Monitor components are included during installation and 

the executable is placed in the “Start Up” menu. However, if you do NOT 

want to use this service select “Entire feature will be unavailable” during the 

installation process. 



The Validation Suite Monitor (VSM) is used to 

monitor the computer’s environment and 

report any changes. 

The environment is a core set of files that 

should not change after a validation run. If 

the environment changes after a validation 

run, then the system may need to be 

validated again. 

Only administrators can configure the VSM for 

use by non-administrators. 

On a validated system, the VSM scans the 

“environment” when Phoenix ® WinNonlin ® is 

launched and will alert the user if the 

environment is found to have changed since 

the system was last validated. 

State unknown or 

being recorded 

State unchanged since 

Validation 

State has changed since 

Validation 



Opens configuration file in 

Notepad containing xml tags that 

can be edited to select which 

components of the environment 

VSM should monitor. 

The user environment must be 

recorded before the VSM can 

monitor the environment for 

changes. This step should be done 

prior to running the validation 

suite 

Check Environment: compares the current environment to the one recorded 

(on demand). 

Open Log: Displays the log of the monitoring (see next screenshot) 


The Validation Suite Monitor Log 


Phoenix ® WinNonlin ® Validation Suite Licensing 

Free upgrade for current WNL validation suite users. 

A validation suite license must be purchased for each license of 

Phoenix ® WinNonlin ® that is to be validated. Licenses are locked to 

each individual computer. 

Node and float licenses are available. 

The licensing for Phoenix ® WinNonlin ® Validation Suite is based on the 

number of seats of Phoenix ® WinNonlin ® that a customer has 

installed. 

• For node licenses, a seat or license is defined as a computer that has a 

Phoenix application. 

• For float licenses the number of seats or licenses is equivalent to the 

number of float licenses of WinNonlin. This definition includes 

deployment in a Citrix environment because the Citrix environment 

requires float licenses. 


Contacts & Follow-Up: Thank you! 

North America 

Christopher Smith 

+1-919-852-4685 

sales@pharsight.com 

Europe 

Edward Dix 

+49 (89) 45103036 

sales@pharsight.com 


Proprietary Notice 

• All contents Copyright © 2010, Tripos, L.P. All Rights Reserved 

• No part of this document may be reproduced or transmitted in any form 

or by any means, electronic or mechanical, including photocopying, for 

any purpose, without the express written permission of Pharsight, A 

Certara Company. 

• Phoenix , Phoenix WinNonlin, Phoenix Connect, WinNonlin, WNL, NLME, 

AutoPilot, Trial Simulator, TS2, Pharsight Knowledgebase Server, PKS, 

Drug Model Explorer, DMX, and Pharsight are trademarks or registered 

trademarks of Tripos, L.P. 

• All other brand and product names are trademarks or registered 

trademarks of their respective holders.

Phoenix WinNonlin Va.. - Pharsight Corporation

Create successful ePaper yourself

Delete template?

Save as template?