ORACLE Validation Plan

XXX Company

Document #:

PREPARED BY:

PRINTED NAME TITLE SIGNATURE / DATE

APPROVED BY:

PRINTED NAME TITLE SIGNATURE / DATE

ORACLE Validation Plan
____________________________________________________________________________

Table of Contents

1. Objective.....................................................................................................................3
2. Business Areas Involved.........................................................................................3
3. System Scope...........................................................................................................4
3.1 ORACLE Application........................................................................................... 4
3.2 Platform................................................................................................................ 5
3.3 Software Modifications and Customizations....................................................5
3.4 Third Party Software...........................................................................................9
4. Gap Analysis.............................................................................................................9
4.1 Procedure for the Preparation of Checklist of GAP Analysis..........................9
5. Risk Assessment....................................................................................................11
5.1 Risk Assessment Process................................................................................11
6. Validation Approach...............................................................................................14
6.1 Document User Requirements.........................................................................16
6.2 Develop Validation Plan....................................................................................16
6.3 Develop Protocols............................................................................................. 16
6.3.1 Installation Qualification (IQ)..................................................................17
6.3.2 Operational Qualification (OQ)...............................................................18
6.3.3 Performance Qualification (PQ)..............................................................18
6.4 Execute Protocols............................................................................................. 18
6.5 Develop Summary Report................................................................................19
7. Deliverables and Responsibilities.........................................................................19
8. Validation and Production Environments............................................................20
9. Standard Operating Procedures............................................................................20
10. Acceptance Criteria................................................................................................21
10.1 Acceptance Criteria........................................................................................... 21
11. Validation of Changes............................................................................................21
12. Requalification and/or Revalidation......................................................................21
12.1 Requalification Criteria.....................................................................................22
13. SYSTEM RETIREMENT...........................................................................................23
14. Glossary of Terms and Acronyms.............................................................................23

____________________________________________________________________________

Document #: Page 2 of 25
ORACLE Validation Plan
____________________________________________________________________________

1. Objective
XYZ is validating the ORACLE Process Manufacturing computer system, Version 11.5.9 to
comply with the Good Manufacturing Practices (GMP) for finished pharmaceuticals and to
comply with XYZ’s computer system validation master plan (Reference number VMP 10,
Revision 2.1).

2. Business Areas Involved

The ORACLE Process Manufacturing (OPM) Computer System is used throughout XYZ to
automate purchasing and manufacturing functions related to its production and quality
system. Currently, XYZ operates the ORACLE system in its headquarters in Tenth of
Ramadan City, Egypt. OPM Computer System automates the functions in the following
departments:
 Central Planning
 Purchasing
 Production
 Production Planning
 Quality Assurance
 Quality Control
 R&D
 Receiving & Stores
Some of the uses of the OPM Computer system affect XYZ's quality system and others do
not. The figure below depicts the GMP areas that are automated by the OPM Computer
system (underlined).

Finished Pharmaceuticals GMP Areas (21 CFR 211)

Areas Automated By Computer Systems

Equipment Cleaning and Use

Personnel Qualifications (211.25) (211.182)
Consultants (211.34) Component, Container, Closure and
Equipment Cleaning and Maint. (211.67) Labeling Records (211.184)
Automated Equipment (211.68)* Master Production Records (211.186)
Written Procedures (211.100) Batch Production Records (211.188)
Materials Examination and Usage (211.122) Production Record Review (211.192)
Packaging and Labeling Oper. (211.130) Laboratory Records (211.194)
Drug Product Inspection (211.134) Distribution Records (211.196)
Distribution Procedures (211.150) Complaint Files (211.198)
Reserve Samples (211.170) Returned Drug Products (211.204)
Records and Reports (211.180) Drug Product Salvaging (211.208)

____________________________________________________________________________

Document #: Page 3 of 25
ORACLE Validation Plan
____________________________________________________________________________

3. System Scope
The OPM Computer system is comprised of two major component areas, the platform and
the application. The figure below depicts these areas, each of which are further described
below.
ORACLE Process Manufacturing System

ORACLE Process
Manufacturing
Application

Platform
Windows 2000 Server
IBM xSeries 235 & xSeries 220

3.1 ORACLE Application

The ORACLE eBusiness Suite (version 11.5.9) consists of a set of commercial software
programs (called modules) that are licensed from ORACLE Egypt Limited 1 . The table
below identifies the standard ORACLE modules that have been installed for XYZ.

Module Name In Use General Function2 QS Validate

Impact(s)
Oracle Process Yes Manages the overall process of Yes Yes
Manufacturing planning and manufacturing.
Manufacturing No Manages report generation and is in Yes No
Intelligence built in the system
Purchasing Yes Manages the overall purchasing Yes Yes
function
Oracle Internet No Helps in report generation which is Yes No
Developer Suite defined by the user.

1
Software License Agreement effective date15-5-2002
2
Refer to the User Requirements and Functional Specifications (document # SRS12806) for more
details.
____________________________________________________________________________

Document #: Page 4 of 25
ORACLE Validation Plan
____________________________________________________________________________

Module Name In Use General Function QS Validate

Impact(s)
Oracle Discoverer No Helps in ad hoc queries by end users Yes No
Desktop Edition

3.2 Platform
The platform consists of the operating system software and hardware that supports the
ORACLE application software. The hardware includes two IBM xseries 235 servers, one
for test environment and other for production and a domain server IBM xseries 220. The
software includes MS Windows 2000 Server, MS Visual C++ version 6.0 + service
pack3, MKS Toolkit version 7.0 and gnu make version 3.77. User workstations and
printers also form part of the hardware. The ORACLE application runs on an ORACLE
database and Windows 2000 operating system software. System users connect to the
application server using client Windows 98/2000/XP desktops with MS IE. The
installation and operational capabilities of these platform components will be challenged
as part of this validation study.

3.3 Software Modifications and Customizations

XYZ has made certain modifications to certain existing ORACLE programs and has
created new programs that extend the system's function. A list of these programs was
analyzed to determine which impact quality system areas. The programs affecting
quality system functions are listed in the table below. These will be tested as part of this
validation effort.

Sr. Function Purpose GMP Criticality?

No. (Yes / No)
OPM Inventory
1. Item Inquiry To get information about item stock No
availability in OPM system.
2. Transaction To get list of all transaction performed No
Inquiry during whole year in OPM system.
3. Create To create receipt of material which are Yes
Immediate received without PO.( for signal RM /
PK item)
4. Create Journal To create receipt of material which are Yes
received without PO.( for multiple
RM / PK items)
5. Adjust Immediate To adjust stock of single RM / PK item Yes
6. Adjust Journal To adjust stock of multiple RM / PK Yes
items
7. Post Journal To post after completion of receipt Yes
____________________________________________________________________________

Document #: Page 5 of 25
ORACLE Validation Plan
____________________________________________________________________________

without PO
8. Lot Genealogy To get list of batches where particular Yes
lot of item is used
9. Move Journal To transfer multiple items from Yes
storage location to storage location
10. Move Immediate To transfer single item from storage Yes
location to storage location
11. Create Lot To create lot after receipt of material. Yes
12. Transfer – Move To transfer product from production Yes
immediate line to FG Store after completion of
production.
13. Transfer – Move To transfer products from production Yes
journal line to FG store after completion of
production
14. Stock locator To create location in warehouse Yes
15. Inventory To open and close period of different Yes
calendar functions
16. Warehouse To create warehouse in OPM system Yes
Purchasing Buyer
17. Universal In-Box Information about status of Purchase Yes
orders
18. Purchase order To get information about Purchase No
summary order
19. Purchase orders  To create new purchase order Yes
 To change existed purchaser
order
 To release purchase order
 To close purchaser order
 To display existed purchase order
20. Suppliers To create and change supplier Yes
masters
Formulator
21. Item master  To create new record of item Yes

____________________________________________________________________________

Document #: Page 6 of 25
ORACLE Validation Plan
____________________________________________________________________________

master
 To modify existed item master
record
 To deactivate existed item master
record
 To display existed item master
record
22. Formula  To create new formula Yes
 To change existed formula
 To display existed formula
23. Recipe  To create new recipe Yes
 To change existed recipe
 To display existed recipe
Production Supervisor Module
24. Batches  To create new batch for item and Yes
for product
 To change existed batch record
 To release batch for production
 To complete batch after
production
 To display existed batch record
 To view batches by product
 To receipts items from receipt
area to warehouse
 To allocate qty. against planned
qty. in warehouse

25. Batches  To enter stock after completion of Yes

production
 To return items from production to
warehouse
26. Print of Batch To take print out of created batch Yes
record record
27. Stock report To get information about current stock Yes
____________________________________________________________________________

Document #: Page 7 of 25
ORACLE Validation Plan
____________________________________________________________________________

of item like required qty., physical

stock, allocated qty., free stock and on
order stock
28. Print additional To take print out of additional item Yes
item issue order issue order from warehouse for
production
29. Print item return To take print out of item return slip Yes
slip from production to warehouse
30. Print item receive To take print out of item receipt slip Yes
slip from cost from cost center
center
31. Print item return To take print out of return slip from Yes
slip to cost center production to cost center
32. Print inquiry for To take print out of issue record of No
issue item
33. Print inquiry for To take print out of return record of No
return items from production to warehouse
34. Print work in To take print out for stocks of items No
progress report which are under production
Purchasing Receiver
35. Receipts To receive items from supplier to plant Yes
36. Returns To return items to supplier after Yes
rejection from QA
37. Receipt To get summary for receive and return No
transaction transactions of specific item
summary
38. Change To switch between RM and PK type No
organization – receipt form
MRP
Raw Purchasing Receiver
39. Receiving To receive RM and PK from receipt Yes
transaction area to warehouse.
Production Operator

____________________________________________________________________________

Document #: Page 8 of 25
ORACLE Validation Plan
____________________________________________________________________________

40. Batches  To calculate potency of active RM Yes

 To pick up qty. of ingredients and
product
 To issue items to production
41. Print Pick List To take print out of Pick List Yes
42. Print Dispense To take print out of Dispense label Yes
Label
Process Engineer
43. Set up – To create different operation class to No
Operation class attach in routing.
44. Set up – To create different activities for attach Yes
Activities with operation of routing.
45. Set up – To create operation for attach in Yes
Operations routing.
46. Set up – To create plant resource for routing Yes
Resource
47. Routing  To create new routing record Yes
 To change existing routing record
Quality Manager
48. Set up – Test To create test methods Yes
Methods
49. Set up – Actions To create actions taken after Yes
completion of quality inspection
50. Set up – Test To create class for specifications Yes
classes
51. Set up – To create sampling plan for sampling Yes
Sampling plan activity
52. Set up – Tests To create tests, for which item are Yes
tested during inspection in QC
53. Specifications  To create specification of items Yes
and product for result recording
after inspection
 To change existed specifications

____________________________________________________________________________

Document #: Page 9 of 25
ORACLE Validation Plan
____________________________________________________________________________

 To deactivate existed
specifications
54. Samples  To create record for sampling qty. Yes
from each lot
 To change existed sample record
55. Results  To record results of specification Yes
after completion of inspection
 To change existed results
56. Specification To compare two specifications No
comparison
57. Lot Genealogy To get all details of specific lot of item No
or product
58. Sample storage To obtain summary of storage of No
summary sample qty.

3.4 Third Party Software

N/A

4. Gap Analysis
To identify the gaps of implemented OPM Computer system, application software and IT
infrastructure (Platform).

4.1 Procedure for the Preparation of Checklist of GAP Analysis

During GAP analysis, checklist shall be prepared for the system. Also, the Checklist
shall be reviewed before the analysis, evaluation and observation. Following points (but
not limited to) shall be covered for the preparation of checklist for GAP analysis:

 Review the following validation documents for existing application software.

o Master Validation Plan

o User Requirement Specification
o Functional Specification

 Review the following design and technical documents:

o System schematic diagram

o System operation manual
____________________________________________________________________________

Document #: Page 10 of 25
ORACLE Validation Plan
____________________________________________________________________________

o System maintenance and support contract

o Source code of the customized application
o Operation training records

 Review the following documents for Standard operating procedures of the

system:

o System operation
o Hardware/ software change / control
o System operation and maintenance training
o Software backup and restore

 Process GAP for individual process function wise.

 System hardware design and installation

o System hardware and software

o Software and data backup restore
o Disaster management

 Network Infrastructure GAP

o System network component

o Disaster management

Following parameters/ contents are to be considered and examined during the

execution of the checklist for the GAP analysis:

 Content to be verified in validation documents.

o Review the documents availability, approval and representation of the

installed system.
o Necessary, basic and technical information are incorporated in the
system.

 Content to be verified in design documents :

o Document identification no., revision name, approval and correctness

o Appropriate Technical Information

 Content to be verified in Standard operating procedures :

o Document identification no., revision name, approval and correctness

o Contents should be as per the process requirements

 Process functionality

oCritical field requirement for particular transaction.

 Source of record
 Type of record (Mandatory record, Optional Record, Changeable
record)
____________________________________________________________________________

Document #: Page 11 of 25
ORACLE Validation Plan
____________________________________________________________________________

o Pre and Post Process flow requirement.

o Authorization
 Type of functionality and rights
o Standard Operating Procedure (SOP) for individual process transaction.
 Document identification no., revision name, approval and correctness
 Contents should be as per the process requirements
o Existing record
 New created record document
 Change record document
 Delete and release record document
 Training and audit trail record document

Following action to be taken for identified Gaps in GAP analysis report:

 When the negative results of the spot checks are realized, determine if Gaps are
due to improper configuration / implementation (in case of system is capable).
Note down the actual observation and intimate to validation core team to correct
the same.

 When the negative results of the spot checks are realized, determine if Gaps are
due to system’s incapability to satisfy the requirements, than note down the
observations and suggest implementing immediate manual procedure to control
the system’s requirement and informing to core/technical team to implement the
same through system control.

 When the negative results of the spot checks are realized, determine if Gaps are
related to non availability of documents/records, than note down the
observations and intimate to project coordinator to define further action plan.

5. Risk Assessment
The focus of the risk assessment is to assess those risks associated with the
system/process operation of the system. The risk assessment process allows users to
identify and minimize the impact of adverse events, while at the same time providing the
necessary justification for the validation approach taken to support the system
qualification.

Risk assessment is a part of the overall responsibility of the validation team members;
however each member may take on a different role during the assessment exercise.

The system owner is responsible for the operation of a system and the data reading from
the system. It’s a responsibility of system owner to investigate and evaluate those risks,
which are identified as part of the GMP requirements. Individual system module wise
department shall be system owner for this assessment

IT personnel are responsible to review the system design, evaluate and identify program
configuration risks.

Quality assurance personnel are responsible to identify those risks that are going to
affect regulatory requirements and maintaining company quality standards and policies.

____________________________________________________________________________

Document #: Page 12 of 25
ORACLE Validation Plan
____________________________________________________________________________

5.1 Risk Assessment Process

I) Process Identification

The basis for the Risk assessment will be the final requirement specifications. These
documents are used to identify the system functions and their sub-functions, including
the dependencies between them.

II) Risk Assessment Associated With Computerised systems

a) Identify GMP risk

System functions, parameters should be evaluated and identified whether they

represents a risk when assessed against a series of cGMP criteria’s.

Following types of risks are mainly identified during Risk Assessment Process.
 Access control
 Identification of transaction records
 Master records
 Pre process and post process
 Date validation
 Linkage of records
 Process parameters such as quantity, storage location, material group, bill of
material etc.
 Calculation and results
 Code numbering system
 Failure of hardware conditions and basic software

b) Identify risk scenarios

Having determined that a particular function may have a GMP risk associated with
it, the assessment should proceed to identify the various risk scenarios i.e. the
events that identify the risks associated with use of the system.

c) Assess likelihood

Determine the likelihood (frequency or probability) of an adverse event occurring.

User should consider the likelihood of the adverse event occurring per a quantity
of transactions, and assigning a value to that estimate. Ranking of likelihood
methods are defined as follows:

The processes which are internally controlled by software (user can’t modify) and
those are tested thoroughly during software development, may fall in ranking of
likelihood 1 to 3. For example: Display parameters, print records.

The processes which are controlled by users and due to possibility of human error
and non-availability of system control may fall in ranking of likelihood 4 to 6. For
example: Create/ change/ release/delete records.

____________________________________________________________________________

Document #: Page 13 of 25
ORACLE Validation Plan
____________________________________________________________________________

Adverse events occurred due to systematic faults may fall in ranking of likelihood
7 to 10.

d) Assess the severity of impact

Risk Assessment requires not only the identification of the immediate effects of
the risk but also the long-term impact on the business of those effects. These
effects must take into account a wide variety of issue including impact on
regulatory compliance, financial impact and company reputation with customers
and suppliers. The impact of risk occurring may be described as follows:

The processes which are not affecting directly to product quality and used for
business supporting functions may fall in ranking of severity 2 to 4. For example:
purchase info record, invoice, vendor records.

The processes which are used in initial stage of operation, however it may be
affect product quality but those are not used for final decision may fall in ranking 5
to 6 of severity. For example: Create records, change records, wrong data entry,
non-availability of SOP.

The processes which are used in final stage of operation and are used for final
decision for product release and stock updation may fall in ranking 7 to 10 of
severity. For example: Release records, Goods receipt and goods issue, deletion
of records, usage decision, Finish goods transfer notification, label printing,
display records, cancellation of record.

e) Assess probability of detection

Identify if the adverse event can be recognized or detected by other means in the
system. Adverse event having high probability of detection, may not pose serious
threat because it can be recognized quickly and suitable corrective action taken
to mitigate its impact. If adverse event has a low probability of detection, then the
risk condition need to seriously consider a review of the design or the
implementation of alternative procedures to avoid the event.

Adverse event is detected at final stage of product or after release of product or

may not be detected may fall in ranking 6 to 10 of probability of detection. For
example: Non-availability of SOP, usage of SOP, Training, use of wrong record,
Display record.

The processes with adverse events are advanced to next stage of operation;
however that adverse event can track down before final release of product may
fall in ranking 4 to 5 of probability of detection. For examples: Create records,
modification of records, and release of records.

The processes with adverse events which are identified by system and
highlighted with error message may fall in ranking 1 to 3 of probability of
detection. For example: Deletion master of records, selection of wrong data.

f) Overall priority

____________________________________________________________________________

Document #: Page 14 of 25
ORACLE Validation Plan
____________________________________________________________________________

Overall priority is calculated using multiplication of the all three assessment

ranking and decided based on following table:

Overall priority Overall priority calculation result

Low < 60
Medium < 180
High > 181

g) Appropriate measure for risk

Prioritize the fault conditions associated with each adverse event based upon
those areas of greatest vulnerability. The risk priority of the fault conditions
should be used to select the appropriate risk measure. By concentrating upon
such an area the overall probability of failure is reduce and quality is built into the
system.

6. Validation Approach
A prospective validation approach will be taken when validating the OPM Computer system.
The following diagram depicts the overall validation efforts. As the system is already been
implemented, the model considered in SILC- Software Implemented Life Cycle.

____________________________________________________________________________

Document #: Page 15 of 25
ORACLE Validation Plan
____________________________________________________________________________

Determine
System
Categorization
Repeat the activities, as required

Assess Impact of System

High
Medium
Impact
Low Impact Identify Requirements
Identify Requirements
Impact Or Functionality Functionality and
Hazard

Perform Risk
Assessment
And Hazard Analysis

Select Good Practices Select Controls Determine Test

Priority
and Select Controls

Perform testing
and
Implement
Control

Monitor Effectiveness
Of Controls and
testing

____________________________________________________________________________

Document #: Page 16 of 25
ORACLE Validation Plan
____________________________________________________________________________

The level of detail to be followed will depend on the nature of system as per GAMP
categorisation as well as risk assessment results. The extent of validation to be performed
shall be determined based on risk assessment report.

Validation requirements are typically categorised by the verification of the systems dealing
with Good Manufacturing Practices (GMPs), compliance evidence is essential for the
following aspects and activities related to OPM Computer system.

 Data Input (capture and integrity), data filing, data-processing, networks and monitoring,
electronic records, archiving, retrieval, printing, access, change management, audit trails
and decisions associated with any GMP related activity.
 In this context, examples of GMP related activities may include, but not limited to,
regulatory submissions, procurement, manufacturing, assembly, testing, quality control,
quality assurance, inventory control, storage and distribution, training,
contracts/technical agreements and associated records and reports.

6.1 Document User Requirements

A User Requirements document will be developed as part of this validation effort. This
version-controlled document will formally specify XYZ’s intended uses for the ORACLE
Process Manufacturing (OPM) system.

A URS document for OPM Business System Requirements dated 2 nd June 2001 has
been prepared by XYZ originally. Based on that present implanted system will be verified
and changes from original specifications will be identified and noted for inclusion in
currently applicable requirement specifications.

6.2 Develop Validation Plan

A validation plan will be developed (this document) to describe the objectives, scope,
approach and responsibilities for the OPM Computer System validation. The validation
plan shall be approved before any of the protocols are approved.

6.3 Develop Protocols

Three types of protocols will be developed to validate this system. The objective of each
protocol type is summarized below.

 Installation Qualification (IQ) Protocol - Confirms that system components

have been installed according to the manufacturer's guidelines and XYZ
specifications
 Operational Qualification (OQ) Protocol - Confirms that system
components operate correctly within specified tolerances and operating
ranges
 Performance Qualification (PQ) Protocol - Confirms that the complete
system performs as intended according to user requirements

____________________________________________________________________________

Document #: Page 17 of 25
ORACLE Validation Plan
____________________________________________________________________________

6.3.1 Installation Qualification (IQ)

An installation qualification (IQ) is associated with the installation of the application

software, its hardware systems and their interfaces. Functions to be verified through
defined procedures and support documentation, the hardware and system software are
installed in accordance with design and vendor documentation.

IQ protocol shall be developed to verify and document that all critical aspects of the
systems functions shall be installed in accordance with the approved system
specifications, manufacturer's specifications and as-built documentation.

Tests to be performed will be described in detail in respective protocol of the system.

Following tests shall be performed under Installation qualification.

 Identification of system hardware and verify its installation.

 Verify availability of master documents.
 Verify quality of Power utilities and its circuit protection
 Verify software installation
 Review software backup
 Review of Standard operating procedures.
 Verify environment condition.

Network Verification

Network verification is associated with the network infrastructure of the OPM Computer
system.
NQ protocol shall be developed to verify and document that all critical aspects of the
systems functions shall be installed in accordance with the approved system
specifications, manufacturer's specifications and as-built documentation.

Tests to be performed will be described in detail in respective protocol of the system.

Following tests shall be performed under network qualification.

 Identification of system hardware and verify its installation.

 Verify availability of master documents.
 Verify quality of Power utilities and its circuit protection
 System connectivity and its operation.
 Verify the security system of network infrastructure.
 Verify network failure and restore condition.
 Review of Standard operating procedures.
 Verify environment condition.

____________________________________________________________________________

Document #: Page 18 of 25
ORACLE Validation Plan
____________________________________________________________________________

6.3.2 Operational Qualification (OQ)

OQ protocol will be developed to verify proper system functionality with functional testing
throughout all anticipated ranges and modes of operation. The operational tests will be
designed to challenge and demonstrate the system's ability to operate in accordance
with the approved system specifications. The design and structure of OQ testing will be
consistent with the strategy of the software application.

The operational qualification (OQ) is a documented verification that the system or

system performs as intended throughout representative or anticipated operating ranged.
Following is the brief description of each test to be performed under operational
qualification.

 Verify application software security and access control.

 Verify the software basic function.
 Verify software function
 Perform software function challenge test.
 Verify the training record and preventive maintenance procedure.

6.3.3 Performance Qualification (PQ)

PQ protocol will be developed to verify proper system functionality with observation of

actual performance. The performance tests will be designed to challenge and
demonstrate the system's ability to perform in accordance with the approved system
specifications. The design and structure of PQ testing will be consistent with the strategy
of the software application.

The performance qualification (PQ) is a documented verification that the system

performs as intended throughout representative or anticipated operating ranged.
Following is the brief description of each test to be performed under operational
qualification.

 Verify application software security and access control.

 Verify the software basic function.
 Verify software function and operation record
 Verify operational SOP

The tests within each qualification document each contain an objective, step-by-step
instructions, and an expected result. Protocols will be approved by management prior to
their execution. The specific protocols that will be developed are identified in section 6.
The protocols will contain a section that links each test to one or more user
requirements.

____________________________________________________________________________

Document #: Page 19 of 25
ORACLE Validation Plan
____________________________________________________________________________

6.4 Execute Protocols

Each qualification document will be pre-approved before it is executed. Tests will be
executed by one or more persons and subsequently verified by someone other than the
test executor. Actual test results will be recorded using objective evidence (e.g.
attached screen prints and reports) where practical. Each test result will be signed and
dated by the test executor and the reviewer. Non-conformances (e.g., cases where
actual results do not match expected results) will be identified in the summary section of
the qualification document. After executing all tests in a qualification document, the
results will be reviewed and approved by management.

The qualification documents will be executed in the following order: 1) IQ, 2) Application
OQ, and 3) System PQ. The IQ must be fully executed before the Application OQ. The
Application OQ must be executed before the System PQ. Each qualification document
must be post-approved after all tests are successfully executed.

6.5 Develop Summary Report

Once all protocol test results have been approved, a Validation Summary Report will be
developed. This document summarizes the results of the testing, summarizes the non-
conformances, and provides a conclusion statement. Once the Validation Summary
Report is reviewed and approved by management, the validation deliverables are
assembled into binders and retained in a controlled location. Approval of the Validation
Summary Report constitutes approval of the validation.

7. Deliverables and Responsibilities

This validation effort will produce the deliverables identified in the table below. The general
responsibilities are identified for each deliverable. Specific individuals will subsequently be
identified and documented within each deliverable.

Document Title Document Prepare Pre- Execute Post-

Number Approve Approve
OPM Computer System Validation Plan N/A* N/A*
OPM Computer System Gap Analysis
Report
OPM Computer System Risk
Assessment
OPM Computer System Modified User N/A* N/A*
Requirements Specifications
OPM Computer System Platform
Installation Qualification
OPM Computer System Application
Operational Qualification
OPM Computer System Performance
Qualification
OPM Computer System Validation N/A* N/A*
Summary Report

____________________________________________________________________________

Document #: Page 20 of 25
ORACLE Validation Plan
____________________________________________________________________________

Document Title Document Prepare Pre- Execute Post-

Number Approve Approve
OPM Computer System Traceability N/A* N/A*
Matrix
* N/A - this action is not applicable to this deliverable

8. Validation and Production Environments

The OPM Computer system currently operates in a production environment. A separate
validation environment will be necessary for executing certain qualification documents. This
should be done to avoid corrupting the production environment with the test data used
during the validation. The table below summarizes the environment where each of the
qualification documents will be executed.

Qualification Document Environment

OPM Installation Qualification Production
OPM Application Operational Qualification Test Server/Test
Environment
OPM Performance Qualification Validation

The validation environment will contain a copy of the production data and will use the same
programs that are used in the production environment.

9. Standard Operating Procedures

A number of SOPs will be developed for the IT operations that support the OPM Computer
system during this validation study. The IQ/OQ will contain tests to confirm that these
SOPs are approved and in use. Each SOP is summarized briefly below.

System Security - Describes how critical system components are physically

secured in the computer room; Describes how ORACLE user security is
administered on the IBM xseries server and within the ORACLE application including
system access security, shared network resources.
 Change Control - Describes how changes to the IBM xseries platform server and
changes to the ORACLE application shall be reviewed, tested and approved to
ensure the on-going validated state of the ORACLE system.
 Record Retention – Describes types of records to be retained, retention period for
each records and use of authenticated copies; also describes protection of records
from preventing loss, damage, and unauthorized changes.
 Data Backup, Archiving and retrieval - Describes how ORACLE data is routinely
backed up and archived to storage media; Describes how ORACLE data can be
restored from the backup and archive media
 Disaster and Recovery Planning - Describes what actions will be taken to recover
and restore ORACLE system functions in the event of a major disruption or disaster.
 User Administration policy – Describes various actions that will be assigned to
different users of the OPM system. It should typically describe user roles and rights
____________________________________________________________________________

Document #: Page 21 of 25
ORACLE Validation Plan
____________________________________________________________________________

for operation of the system.

 Password policy – Describes the creation, retention, control and frequency of
changes for passwords assigned to various users of the ORACLE system.
 Periodic Review – Describes the management of the Periodic review and
evaluations of ORACLE system. Covers method for performing individual system
reviews.
10. Acceptance Criteria
Criteria For Qualification Approval

 Verify all tests required by various protocols are completed, reconciled and attached
to the protocols as documentary evidence.
 Verify if any amendments and discrepancies are documented, approved and
attached to this protocol.
 If all tests in the qualification protocol have been reviewed and found to be
acceptable, sign the corresponding block in the qualification completion and approval
form.

10.1 Acceptance Criteria

Each of the tests within a protocol contains a protocol description and an expected
result. The protocol description defines the acceptance criterion for the test. The
expected result identifies the means by which this criterion is verified. The OPM system
will be considered validated after all protocol tests have been successfully performed,
any non-conformances have been initiated, and the Validation Summary Report has
been approved.

 All required qualification has been performed and all corresponding data collecting
forms are completed. Completion of data collection forms indicates that actual
installation, operational and integration conditions have been compared to specified
conditions.
 All test equipments used during the qualification have been calibrated and certified
using standards traceable to the NIST or similar agency.
 All amendments and discrepancy have been adequately resolved and approved by
all individuals listed by title on the qualification completion and approval.
 The hardware and software shall be installed in accordance with design
specifications, installation drawings, and manufacturer specifications.
 The application system software and hardware will control the intended process as
required by process specifications and will provided consistently and repeatedly
reproduce the processing cycle. Process specifications can be found in the
supporting documentation.

11. Validation of Changes

Following validation of the OPM Computer System, changes to the system will be
documented and evaluated following established change control procedures.

____________________________________________________________________________

Document #: Page 22 of 25
ORACLE Validation Plan
____________________________________________________________________________

12. Requalification and/or Revalidation

The validated state of OPM Computer System should be checked periodically or after
major change. Periodic revises are conducted as internal audits and this type of review
is not further described. Checking after major changes is done through re-verification.

Changes to validated systems must follow change procedure in accordance with the
Standard Operating Procedure. Every change should follow the risk assessment process
and criticality of that change is identified as low, medium or high. Based on that need for
retesting of associated functions shall be determined. All those steps shall be
documented as governed by this VMP and as identified elsewhere in this document. Re-
verification shall prove that the Systems remain in a validated state as a whole after the
change.

12.1 Requalification Criteria

Major or GMP critical changes, or refurbishments, should be accompanied by verification

activities analogous to those used for the prospective validation. This includes
developing new version of VMP, functional and technical requirement specifications,
detailed design specifications, test protocols and final report. These new versions would
incorporate all changes to the system that were handled under change control from the
time of the initial production release until the revalidation takes place and would
supersede the previous versions.

Depending on the change, potentially impacted areas shall be re-validated. The OPM
Computer System administrator defines the areas and the scope in the installation
qualification and operational qualifications plans.

The following type of verification activities are recommended, depending on the change.

 Updating/upgrading system software or hardware

 Installation according to suppliers’ instructions
 Accompanying supplier documentation describing corrected faults or known
limitations
 Updated hardware and software documentation e.g. manuals, inventories
 Safe storage of system software
 User staff training
 Test start/restart
 Test of changed system functions
 Test of critical functions
 Test of communication with neighboring systems
 Realistic disaster recovery scenario, e.g. power failure, Communication
failure

Following major, also structure impacting changes (major changes)

 Following change control procedure

 Updated hardware and software documentation
 Safe storage of application software
 Support staff training
 User staff training
____________________________________________________________________________

Document #: Page 23 of 25
ORACLE Validation Plan
____________________________________________________________________________

 Test of changed system function/areas

 Test of critical function
 Test communication with neighboring system/interfaces

Following major system faults

 Follow system failure procedure

 Support staff training
 Test start/restart
 Test of critical functions
 Test of communication with neighboring systems
 Realistic disaster recovery scenario, e.g. power failure, communication failure

Following changes to the environmental or operational conditions:

 Follow change control procedure

 Adherence to supplier specifications
 Monitoring the changes to the environmental or operational conditions
 Updated hardware documentation
 User staff training
 Test of changed system function/areas
 Test of critical functions
 Test communication with neighboring systems

Depending on the scope, Installation and Operational Qualification can be planned and
executed independently or concurrently.

13. SYSTEM RETIREMENT

When systems/components are retired, a plan shall be put in place to ensure that the
application can run on the new system and data generated on the old OPM Computer
system work on the new system.

Steps include –

 Decision of decommissioning should be done in consultation with the vendor.

Regulatory or other requirements for the preservation of electronic records should be
carefully considered.
 Create a documentary evidence of actions taken during decommissioning and
retirement of system is to be retained.
 GxP records are to be maintained with their required retention periods and list out
the records which are destroyed.
 An archive report should be generated describing the archive approach and listing
documents raw data and electronic records archived. Check if the new system
generates the same results from raw data as the old system.
 It should be possible to retrieve the data even if the original hardware is not
available. This data should be retained as required by relevant regulations and
company policy.

____________________________________________________________________________

Document #: Page 24 of 25
ORACLE Validation Plan
____________________________________________________________________________

14. Glossary of Terms and Acronyms

Platform - the software, hardware and networks that support the software applications and
systems in production
ORACLE OPM - Oracle Processing Manufacturing; a software application that is designed
to track inventory and process purchasing and manufacturing transactions for
pharmaceutical manufacturers
ERP - Enterprise resource planning
GMP - Good Manufacturing Practices
GAMP - Good Automated Manufacturing Practices
URS - User requirement specifications
FS - Functional specifications
VMP - Validation master plan
IQ - Installation qualification
OQ - Operational qualification
PQ - Performance qualification
IT - Information technology
QA - Quality assurance
GUI - Graphical user interface
LAN - Local area network
WAN - Wide area network

____________________________________________________________________________

Document #: Page 25 of 25