Master Validation Plan

PharmaReady 4.1 Release

DMS, TRMS, eCTD, & SPL Modules

Introduction

The PharmaReady product suite encompasses four modules; a document management module (DMS), training record management module (TRMS), electronic common technical document submission module (eCTD), and structured product label authoring module (SPL). PharmaReady is targeted for use within business areas regulated by FDA and other federal laws, and is technically compliant with the regulations of 21 CFR Part 11 and the predicate rules which govern the use of computerized systems for managing data related to clinical trials.

This Master Validation Plan outlines the activities and deliverables required to develop, test, and deploy the PharmaReady application.

Scope

Overview

The master validation plan covers all activities for the PharmaReady 4.1 release, which encompasses additional features and maintenance to all modules.

Specifically, the plan is intended to ensure:

All requirements found in the PharmaReady 4.1 Business Requirements documents are incorporated into the application.

All specifications found in the PharmaReady 4.1 Functional Specifications documents are incorporated into the application.

All specifications found in the PharmaReady 4.1 Functional Specifications documents are tested and passed.

All 4.1 bugs are fixed and unit tested.

All 4.1 bug fixes are tested and passed.

During the testing phase, all high-level defects detected are resolved.

All defects other than high-level are resolved or deferred to a later release.

Only the PharmaReady Life Sciences teams in the Raleigh, NC and Chennai India facilities fall within the scope of this project:

Organizational Structure

This section describes the roles and responsibilities of the project team members.

Project Manager

Phillip Mosely (US) and Sampathraj Mathurperumal (India):

Project planning

Control of project activities and resources

Monitor progress of teams

Ensure issues are correctly addressed and resolved

Enforce project objectives

Work with Quality Assurance to ensure compliance

Technical Lead, Sr. Developer, Developer

Ken Stamper, Todd Andrews, Jim Beck (US) and Kamal Menon, Ganesan Durairaj, Jegan Raman, Selvabharathi Raman, Rajnish Kumar, Elangovan Parasuraman, Gyaneshwar Kumar (India):

Ensure software is coded according to functional specifications document

Create unit test cases

Execute unit test cases

Create, review and approve validation documents

Work with Quality Assurance to ensure compliance

Quality Assurance

Dawn Staniewicz, Jon Schweitzer (US) and Lakshmi Ramasamy, Sharon Anita, Vamsi Krishna Reddy (India):

Write functional and bug test cases

Execute all test cases

Ensure software is tested according to functional specifications document

Ensure all assigned bugs are tested and passed

Create, review and approve validation documents

Ensure software compliance

Business Analyst

Jay Johnson (US):

Ensure software is current with industry standards and regulations

Create Business Requirements, Functional Specifications, and Traceability Matrixes for all modules

Assist Quality Assurance in testing

Create, review and approve validation documents

Ensure software compliance

Work with Quality Assurance to ensure compliance

Technical Writer

Ellen Lofton (US):

Create user documentation (user guides, training workbooks)

Work with Quality Assurance to ensure compliance

Implementation and Support

Tricia Miller (US) and Vijay Srinivasin (India):

Manage customer implementations

Provide customer support

Create, review and approve validation documents

Work with Quality Assurance to ensure compliance

Information Technology

Edwin Rodriguez (US):

Install software

Provide customer support

Create, review and approve validation documents

Risk Assessment

The PharmaReady 4.1 maintenance release has changes which affect all four modules. The majority of the functional changes are within the DMS, eCTD, and SPL modules. The level of testing will include updating applicable developer unit test cases, updating applicable functional test cases with new changes, testing all bugs fixed in the release, updating all Installation Qualification and Operational Qualification documents, and updating regression test cases. The application will need to be revalidated to qualify the installation and basic operations.

Validation Strategy

PharmaReady 4.1 maintenance release has changes which affect the majority of the functionality.

Lifecycle

The V model will be used for lifecycle.

Business Requirements High-level design - contains business needs of software.

Functional Requirements Detail-level design - contains functional design of application.

Development - Coding by the developers as per the functional specification. Code Review is performed to ensure that code is created as per the coding standards.

Unit Testing Performed in the Development Server by the developer to ensure that program works per the functional requirements.

Application Testing / Integration Testing - This is to ensure that programs work along with other components that might get affected. The test cases are created separately.

Product Testing / Load Testing - Performed with large datasets to check if the system / product can handle production scenarios in terms of memory and performance.

Final Implementation in Production Create installation disc and assemble validation package for customer installations.

Support - Any further defects will be recorded as a bug fix or enhancement and will be carried out as a part of a future release.

Plan Responsibilities

Overall responsibility of developing and executing the Validation Plan deliverable documents will be that of the following groups.

ROLES / RESPONSIBILITIES C=Create, A=Approve
	PM	Tech L	S.DEV	DEV	QA	BA	TW	SUP	MISC
Master Validation Plan (VP)					C, A	A
PharmaReady Validation Plan (PRVP)					C, A	A
Project Team list	C				A
Business Requirements Document (BRD)					A	C		A
Functional Specifications Document (FSD)					A	C		A
Traceability Matrix					A	C		A
Company Org Chart					A				C
Installation Qualification Protocol (IQ)		C, A	C, A	C, A	A
Operation Qualification Protocol (OQ)					C, A	A
Performance Qualification Protocol (PQ)		A	C	A	A
PQ Execution and Summary		A	C	A	A
Developer Unit Test Cases		C, A	C	C	A
Problem Tracker Summary	C				A			A
Production Release Form	C				A
Release Notes					A	A		C
Test Execution Summary					C,A
Training Manuals					A	A	C	A
Training Session Descriptions					A	A	C	A
System Admin User Guides					A	A	C	A
DMS Doc Management Guide					A	A	C	A
eCTD User Guide					A	A	C	A
SPL User Guide					A	A	C	A
Technical Manuals		C, A	A	A	C, A
PharmaReady Validation Summary Report					C, A	A
List of documents					C, A
Master Validation Summary Report (VSR)					C, A

Project Timeline

The timeline for the project is:

Traceability

The Traceability Matrix demonstrates that the system meets the defined Business and Functional Requirements. All requirements will be traceable to successfully executed test cases.

Manual testing or successful execution of automated test scripts will demonstrate that all requirements have been met.

Testing Tools

All test cases are written and executed manually. When all manual test cases pass, if time permits, the test case will be recorded for reuse using Quick Test Pro by the India QA Team.

Validation Approach

The general approach to validating the system will be to integrate the validation activities with the development and quality activities.

Validation Deliverable Documentation

The validation documentation will be created during the development, testing, and deployment phases. All electronic validation document deliverables will be uploaded into OSPRey, the TAKE Solutions Document Management System. The OSPRey DMS application has Edit, Review, Approve, Publish and Distribute workflow functions to maintain strict version control of documents and protect against accidental destruction.

Hardcopies of executed validation documents (such as test cases) will be retained in the PharmaReady filing cabinet in the Raleigh, NC office.

Business Requirements

The business requirements documents (BRD) capture the high-level functions desired by the user community (customer) to be implemented in the system. The PharmaReady business requirements are created separately for each of the four modules. Each BRD must be sufficient to establish requirements that are verifiable or testable.

Hardware, Software and Infrastructure Requirements

The hardware, software, and infrastructure requirement document (HSIR) is produced to specify the required system hardware, software, and infrastructure components necessary to install and run the PharmaReady servers.

Functional Specifications

The functional specification documents (FSD) capture the high-level design functions in the system. The PharmaReady functional specifications are created separately for each of the four modules. Each FSD must provide a page-by-page representation of the module, detailing the user interface, fields and columns, active elements, access rules, and field validation. Each FSD item must be verifiable or testable.

Traceability Matrix

The traceability matrix document demonstrates that the system meets the defined Business and Functional Requirements. All requirements will be traceable to successfully executed test cases. The PharmaReady traceability matrixes are created separately for each of the four modules.

Project Team Lists

The project team list is a listing of all members on the PharmaReady development, quality assurance, and support teams in both the United States and Chennai, India offices.

Installation Qualification Validation Protocols

The IQ validation protocol is used to install the software and all components associated with the PharmaReady application. The IQ protocol is written by the development and information technology teams. The IQ New install, Upgrade, and Client Workstation documents must be approved prior to the release of the software as well as prior to execution at a customers site. An acceptance criterion is listed in the IQ document, which must be met to demonstrate the systems readiness for the next phase of validation. Approval of the IQ protocols by the Development Manager, Information Technology, and Quality Assurance shall constitute approval for initiation of the Operational Qualification phase.

Operational Qualification Validation Protocols

The OQ validation protocol is used to demonstrate the effectiveness and reproducibility of the system as a fully integrated system and all major functional areas of the system.

The OQ protocols are written by the quality assurance team.

New Installation

For new installs, each module has a separate OQ protocol which consists of two documents, an admin and a workflow document.

Upgrades

For upgrade installs, each module has a separate OQ protocol which consists of two documents, an admin upgrade and a workflow upgrade document.

Standalone Modules New Installation

Two modules, eCTD and SPL, are available in a standalone version. Each new install for the standalone modules has a separate OQ protocol which consists of two documents, an admin and a workflow document.

Standalone Modules Upgrade

Each new upgrade install for the standalone modules have a separate OQ protocol which consists of two documents, an admin and a workflow document. Each OQ document must be approved prior to the release of the software as well as prior to execution at a customers site. An acceptance criterion is listed in the OQ document, which must be met to demonstrate the systems readiness for the next phase of validation. Approval of the OQ protocols by the Development Manager, Business Analyst, and Quality Assurance shall constitute approval for the Operational Qualification phase.

Performance Qualification Validation Protocols

The PQ validation protocol is used to demonstrate load on the system for a specified number of concurrent users and total number of documents in the system. The PQ protocol is written by the development and information technology teams. The PQ execution will be performed on the final release of the software. An acceptance criterion is listed in the PQ document, which must be met to demonstrate the systems meet the specified performance benchmarks. Approval of the PQ protocols by the Development Manager and Quality Assurance Manager shall constitute approval.

Testing Documents

Testing is the process of checking the system to verify it satisfies all requirements and operates as expected. Testing documentation includes:

Test Plan A plan which outlines the testing timeline.

Functional Test Cases Step-by-step instructions to verify all specifications in the system are included and work properly.

Bug Test Cases Step-by-step instructions to test a specific defect or issue in the system.

Functional Test Case Execution Summary Report listing each functional test case, when it was tested, and a result of pass or fail. If a test case fails, it needs to be re-executed in a subsequent build until it passes.

Bug Test Case Execution Summary Report listing each bug test case, when it was tested, and a result of pass or fail. If a test case fails, it needs to be re-executed in a subsequent build until it passes.

Release Notes

The Release Notes document includes a description of new functionality included in the new release, each bug that is fixed in the new release, and any known issues.

Training Workbooks and User Guides

The Training workbooks and User Guides provide information on how to use the system. The training workbooks are designed to teach specific objectives within multiple lessons and are tailored on a module basis. The user guides are designed to give information on a page or functional level on a module basis.

Validation Summary Report

At the end of the validation activities, a Validation Summary Report will be written describing the results of the executed testing and any deficiencies that were observed and their appropriate resolution. The validation report will include the status of all testing activities, any deviations from the planned validation activities, and validation status. The report also includes any outstanding issues, a list of documentation, and the location of all project deliverables.

Validation Environment

Validation Environment

The Validation/Testing Environment describes the environments in which the unit cases, functional test cases, bug test cases, OQ protocols, use cases, and regression test cases were executed.

The development code was produced in a development environment.

The current development/build version of the PharmaReady application was deployed on one of two QA testing environments (PR41A and PR41B) using the Installation Qualification.

Each subsequent QA build was deployed to the other QA server in a rotating fashion.

An additional QA environment was added in July for testing the software in an upgraded state.

Pre-Execution Validation Process

The following steps outline the pre-execution process.

The development environment must be in place and available for developing code.

Visual Source Safe must be in place for source code control.

Testers will print all test case documents.

Testers will complete all necessary validation documents in blue or black ink.

Validation Execution Process

The following steps outline the validation execution phase.

Development team must execute all unit and IQ test cases.

Quality Assurance team must execute all functional, bug, use case, and OQ test cases.

Document observed results on the validation document pages while testing.

Indicate the result of the Test Step/case is Pass, Pass with Error, or Fail.

A test step will Pass if no defect or software irregularity is encountered.

A test step/case will Pass with Errors if only minor, cosmetic defects or software irregularities are encountered.

A test case will Fail if major defects or software irregularities are encountered.

During the Validation Execution phase, all errors are documented in ProblemTracker.

Validation Execution Process

During the Validation Execution phase, the error resolution process is:

While executing the unit cases, functional test cases, bug test cases, OQ protocols, use cases, and regression test cases, all defects or irregularities will be logged into the ProblemTracker application for tracking and assignment to a subsequent build for deployment.

All defects or irregularities will be logged on the respective test case.

All issues will be assigned a severity level of High, Medium, or Low.

All High-level defects will be corrected.

Medium and Low-level defects can be deferred to a later release.

If applicable, the Software Configuration Manager will push a new version of the application to the validation environment

Tester will re-execute failed documents.

The Error Resolution cycle will continue until all test cases pass.

Post-Execution Validation Process

The following steps outline the process after the validation documents are executed.

All electronic versions of validation documents are retained in TAKE Solutions internal PharmaReady application, OSPRey.

All hardcopies of executed validation documents will be retained in the PharmaReady filing cabinet.

Unit test case

Functional test cases

Bug test cases

For customer implementation, customer retains original documents while TAKE Solutions retains copies of the documents.

Prepare a Validation Summary Report summarizing the results.

Acceptance Criteria of Validation

The Validation will be deemed complete when all of the following are satisfied:

All coding is completed.

All unit test cases are created, executed, and passed.

All QA functional and bug test cases are created, executed, and passed.

All IQ and OQ documents are created, executed, and passed.

All issues determined to be High Level are corrected.

All issues determined to be Medium or Low Level are either resolved or deferred for future releases.

Validation Summary Report is completed.

Training

The PharmaReady Training Records Management module is used to facilitate employee training records tracking. All Standard Operating Procedures (SOPs) and Work Instructions (WIs) are distributed to Life Science employees and read via PharmaReady. Each employee is responsible for reading SOPs and WIs based on their job title. A Training Matrix is maintained listing all required training by job title.

Glossary

The following abbreviations or terns were used throughout this document.

Document Control

Approval

Change History

The following table describes significant content changes made to Master Validation Plan 4.1 Release document. The version number denotes where changes were introduced.

Related Documents

The following documents are related to this Master Validation Plan 4.1 Release document:

Installation Qualification

Operational Qualification Admin (for each installed module)

Operational Qualification Workflow (for each installed module)

Validation Summary Report