Computer System Validation Master Plan Information Technology Essay

1.0 Abstract

Many questions those had been raised across the pharmaceutical industry regarding need of computer system validation and its requirements. There is a big question that how much validation we should do and what activities we should do to carry out successful validation. This document represents history of computer system validation, why it is necessary to do, regulatory requirements for computer system validation and last but not least validation master plan which is a very important for successful completion of computer system validation. Here in these papers, main focus is on what is validation master plan, contents of validation master plan with regards to different validation life cycle models and risk based approach to minimize the risks associated with computer system validation.

2.0 Introduction

In 21st century use of computer system is spreading everywhere in the world. Pharmaceutical Industries are using computer system in most of areas to make each and every task fast, automatic and accurate. As computer is a human made machine, it might make a mistake so correct functioning of the system is very important to get higher efficiency of the system in terms of accuracy, reliability and consistency. Therefore, validation of the computer system becomes a necessary task to check its performance ability. As Planning and scheduling plays a major role in any project, computer system validation master plan is very important to carry out all validation activities with positive outcomes. Purpose of this term paper is to share our thoughts and understanding to develop Computer system validation Master Plan. Contents of validation master plan give whole framework of the computer system, how its design, installation and performance will be evaluated, how it will be validated and how its validated state will be maintained till its retirement.

If you do not document then it proves that you did not do anything so, documentation is very critical part of any project. Therefore, final validation report is the final and very important activity during computer system validation. Computer System Validation Master Plan includes all kinds of documentation regarding validation activities performed during validation, planning of validation process, change control management and system maintenance documentation as well.

3.0 History of Validation

Validation was 1st introduced by two FDA officers Ted Byers and Bud Loftus, in the mid 1970’s to improve quality of pharmaceutical products. There is a big problem or an issue behind each new technology; validation concept has also emerged from some major problems happened in pharmaceutical market. It was implemented in response to problems in the sterility of LVPs in pharmaceutical manufacturing. In earlier times, validation was done only for main production process but later on it was done in some additional areas also like environmental control, media fill, equipment sanitization and purified water production.

4.0 Why Computer System Validation??

Testing an entire system at the end is not considered proper and sufficient evidence that every component within a system fulfills the required specification. Appropriate computer system Validation Master Plan (VMP) will provide a high degree of assurance that all steps and processes are included in validation process which are essential to evaluate and implement computer system.

5.0 Requirements for Computer System Validation

Section 211.68 of the US cGMP regulations states Specific requirements for computer system.

Mechanical, automatic, electronic or other types of equipment, including computers or related to computer systems should perform their functions satisfactorily. These instruments or equipments may be used in the manufacture, processing, packing, and holding of a drug product. If this sort of equipment or instrument is used, it shall be calibrated, inspected, or checked on regular basis as per the written program in order to ensure proper performance of the system. There shall be maintained written records of those calibration checks and inspections.

Only authorized personnel shall be accessible and responsible for changes in master production and control records or other records exercised over computer or related systems.

Authorized personnel shall be assigned for checking formulas or other records or data input to and output from the computer or related system for accuracy.

Complexity and reliability of the computer or related system shall be the basis to decide the frequency and degree of input/output verification

There shall be maintenance of a backup file of data entered into the computer or related system except certain data including calculations which are performed in connection with laboratory analysis are excluded by computerization or other automated processes. Along with appropriate validation data, a written record of the program shall be maintained in such cases.

For assurance that backup data are precise and complete and to ensure that backup data are secure from alteration, inadvertent erasures or loss, hard copy or alternative systems (For example; duplicates, tapes, or microfilm) shall be designed and maintained.

Some specific guidance documents have been developed by the FDA for computer system applications in other FDA regulated areas. The Industry Guide is one of the most important from them, which includes general principal of Software Validation that deals with development and validation of software used in medical devices. Draft guidance on computer systems used in clinical studies is more recently released by FDA. This draft guidance states FDA’s expectations related to computer systems and to electronic records generated during clinical studies.

Computer system validation issues are taken into consideration by several industry organizations and private authors because of their special importance.

Guidelines for computer validation has been developed by the Good Automated Manufacturing Practices Forum (GAMP)

A validation reference book for the validation of computerized analytical and networked systems has been published by Huber

A technical paper comprises of validation of laboratory data acquisition system has been developed by the Parenteral Drug Association (PDA)

6.0 Validation Master Plan

The Validation Master Plan is a document that describes how the validation program will be executed in a facility. Even though it is not mandatory, it is the document that outlines the principles involved in the qualification of a facility, defines the areas and systems to be validated and to provide a written program for achieving and maintaining a qualified facility with validated processes. It is the foundation for the validation program and should include process validation, facility and utility qualification and validation, equipment qualification, cleaning and computer validation. The regulations also set out an expectation that the different parts of the production process are well defined and controlled, such that the results of that production will not substantially change over time.

All validation activities should be described in a validation master plan which should provide a framework for thorough and consistent validation. A validation master plan is officially required by Annex 15 to the European GMP directive. FDA regulations and guidelines don’t mandate a validation master plan, however, inspectors want to know what the company’s approach towards validation is. The validation master plan is an ideal tool to communicate this approach both internally and to inspectors. It also ensures consistent implementation of validation practices and makes validation activities much more efficient.

7.0 Contents of Computer System Validation Master Plan

Purpose & Scope

Roles & Responsibilities

Validation Approach

Risk Based Approach

System Acceptance Criteria

Vendor selection & Assessment

Computer System Validation Steps

Configuration Management and Change Control Procedures

Back-up and Recovery

Error Handling & Corrective Actions

Contingency Planning and Disaster Recovery

Maintenance and Support

System Retirement

Validation Deliverables & Documentation

Templates & Validation Examples

7.1 Purpose and Scope

7.1.1 Purpose:

In 21st century development and manufacturing of each and every medicinal product utilize computer system. Therefore proper functioning and performance of software and computer systems play critical role to maintain consistent, reliable and accurate data. US FDA and other major regulatory agencies have specified regulations and guidelines to ensure that computer system is suitable for its intended purpose.

To perform computer system validation in an efficient way with positive outcomes, development of validation master plan early in the system development life cycle is very important. Computer System Validation Master Plan includes the system developer, information technology group, end user and regulatory or compliance unit. System owner or sponsor should develop validation master plan, document and approve it for successful completion of validation. Organization management must have adequate control over each validation activity and performer to achieve desired validation goal with use of available resources in defined time duration.

7.1.2 Scope:

Computer system validation master plan covers complete system development life cycle which includes validation during system design and development until system will retire.

Moreover, it wraps all aspects of validation process with consideration of vendor, end user, application, hardware and software, interfaces to other systems, personnel training, documentation and system management as well as validation itself after the system is put into use.

7.2 Roles and Responsibilities

There is no regulation in FDA Guidance Document for roles and responsibilities to perform computer validation. Specific organizational structure is responsible for proper distribution of work to achieve the validation target.

Various departments involved in computer system validation:

System User

Validation groups

Quality assurance

IT Department

Regulatory affairs

Documentation department

Vendors of commercial of the shelf systems

7.2.1 Responsibilities of End Users: Out of all above departments end users are more responsible for validation of computer system to have better control over the system performance. They should write the specifications, create test cases and perform on-going testing with support of validation groups and QA people.

7.2.2 Responsibility of Validation Groups

Management of validation activities based on business objectives, applicable federal and international regulations, industry standards that pertain to the validation of GXP system.

7.2.3 Responsibilities of QA

All validation activities are monitored by QA. QA is the leader for vendor assessment, documentation & verification of validation activities with compliance of applicable regulations. QA has authority to review and approve validation documents such as requirement specifications, SOPs for planning & development of VMP, test plans, test results and final validation reports.

An additional important role: Leader to initiate to do necessary tasks if tasks don’t happen as they should do.

7.2.4 Responsibilities of IT Department

Design, development & installation of network infrastructure involves IT department. They are not responsible for validation but give suggestions on testing requirement & frequency and assessment of risks associated with the system.

Validation Approach

Major part of the VMP is to determine the need of validation and how it is related to SDLC of the product development. The Validation Master Plan is a document that describes execution of validation program. It outlines system qualification principles, defines sub-systems to be validated and provides a written program for achieving and maintaining a qualified system with validated processes.

Validation of computer systems is not a once off event. But it is a part of the complete SDLC. This cycle includes planning, specification, programming, testing, commissioning, documentation, operation, monitoring and modifying.

New systems should be validated when it is going to use to solve an existing problem. While for an existing system it starts when the system owner brings the system into a validated state. System retirement with successful existing data migration is the end of validation. Validation planning, defining user requirements, functional specifications, design specifications, validation during development, vendor assessment for purchased systems, installation, initial and ongoing testing and change control are steps of validation beginning to system retirement.

Validation process is typically broken down into life cycle phases because of complex and time consuming process. One model that is frequently used is the V-model.

PQ

URS

OQ

FS

DS

IQ

SYSTEM BUILD 

V-Lifecycle Model

For true commercial off the shelf system with no code development for customization V-model is quite complex. 4Q model with just four phase best fits for COTS system.

  4Q Lifecycle Model

Both the 4Q and the V-model are lack of retirement phase. Hence it is not suitable when systems require to be configured for specific applications or when additional software developed by the user’s firm or by a 3rd party is required which is not included in the standard system. In this case following model is preferred.

User/System Requirements

INTEGRATION

DEVELOPMENT

IQ

OQ

PQ

Maintenance/Use Retirement

System Integration Combined with System Development

If there is no vendor, the software needs to be developed and validated by following the steps on the left side of the diagram. Programmers need to develop functional specifications, design specifications and the code and perform testing in all development phases under supervision of the quality assurance.

If users want to purchase system from vendor, they compare the vendor’s responses with their own requirements. If all vendors fail to meet user requirements, then requirements may be adjusted or additional software is written following the development cycle on the left side of the diagram. The vendor is selected based on the users’ technical and business requirements.

To decrease testing requirement more standard with less customization software should be used. GAMP has developed software categories based on the level of customization. Category one and two define operating systems and automated systems firmware are specified in category 1 and 2 respectively. Both of these have less important as compare to 3rd, 4th and 5th category. Each computer system is associated to third, fourth and fifth categories.

Category

Description

GAMP 3

Standard software package. No customization.

Examples: MS Word (without VBA scripts). Computer controlled spectrophotometers.

GAMP 4

Standard software package. Customization of configuration.

Examples:

LIMS, Excel spreadsheet application where formulae and/or input data are linked to specific cells.

Networked data systems.

GAMP 5

Custom software package. Either all software or a part or the complete package has been developed for a specific user and application.

Examples: Add-ons to GAMP Categories 3 and 4, Excel with VBA scripts.

[2]

Risk Based Approach

Risk based approach is widely used in the industries, not only the pharmaceutical industries but other industries also adopting this concept. Recent studies show that the pharmaceutical industries are widely using this concept for the development of new soft ware. In the pharmaceutical industries, particularly in the testing of computer system this is very useful. As we know the how important is the GXP approach in the pharmaceutical industries which is mainly based on the computer system for documentation and storage of data and also for operate other operations. So, the verification or the validation of computer system is very important. Proper functioning of the computer system is necessary for the pharmaceutical industries.

7.4.1 Define the System Inventory:

To determine the inventory of the computer systems and software it involves the following:

System Boundaries: First step is deciding the boundaries of the system.

Document process: Document all the processes of the organizations which used the application.

Define functions: the functions performed by that particular system is define properly and also the other which support the application.

Identify data: Data used in the process should be clearly defined and show that are compliance with the FDA.

Identify existing controls: This involves the identification of the existing process controls.

7.4.2 Risk Assessment:

Risk assessment should be performed to determine or identify the critical data.

The risk assessment process includes:

Risk Assessment

Functions Performed or Data used

Subsystem Affected by the Function

Reasons for Failure

Likelihood of Failure

Consequences of Failure

Detection of Failure

7.4.3 Gap Analysis:

The Gap analysis is performed mainly to identify the shortcomings of the existing design and other process controls. After the identification next step is the develop the plan and strategy to minimize the associated risk.

For example, the existing system has not certain specifications to perform adequate tests. This kind of risk would be minimized by adopting needed specifications. This may involve the addition of new software or upgrade the old version or hardware to the existing systems.

7.4.4 Prioritized Validation Plan:

All the activities in detailed should be included into the Validation Master Plan. The main focus should be on the compliance during the development of the plan to minimize any non-compliance and be in the regulations required by the agency. All the groups of the organization should be involved in the validation master plan of the complex computer system like stakeholders, including operations, engineering, IT, and also QA groups. So, all the process and procedures and also other related parameters performed by these groups should be considered.

7.4.5 Execute Plan:

After the approval of the validation plan, it should be implemented including all the controls as required and also the retrospective development if necessary. First validate the highly priority functions.

7.4.6 Training & Training Plan:

As the system is validated and implement the new technology the personnel should be trained as per the requirement.

All personnel related to development and use of GXP computer system must be properly trained to perform computer system validation in a very efficient way to achieve desire goal without any failure during validation process.

Requirements of Personnel:

Educational Qualification and Experience

Roles of personnel required to be performed

Training Plans and Records

Education Qualification and Experience:

System developer and system user should have qualification requirements stated in 21 CFR Part 11 Regulation for electronic records and electronic signatures. Each personnel engaged in computer system validation should have enough technical background of computer systems and some experience of GXP computer system handling.

Roles of personnel required to be performed:

Management should assign specific roles and responsibilities to each person. Individual role description should be prepared and kept up to date to show during inspection.

Training Plans and Records:

Organization should develop training plans at specific intervals to manage the staff development in order to aware all personnel regarding GXP principles of computer system. Training procedures and plans must be documented and maintained to comply with regulatory requirements. There should be audit and periodic review of personnel performance and/or training records. The personnel should be given supplementary training if necessary.

7.5 System Acceptance Criteria

1) The system is installed according with design specification based on manufacturer recommendations and cGMP guidelines

2) Instruments are calibrated, identified, and entered in to calibration program

3) Software and hardware systems are verify and confirmed as per specification

7.6 Vendor Selection & Assessment

Vendor selection and assessment play critical role to get computer system with high efficiency. To validate a computer system, not only vendor is responsible but user is also responsible for overall validation. System owner should assess the activities of commercial off-the-shelf system developers to determine necessary additional efforts to ensure that computer system is fully validated for its intended use.

Vendor selection and assessment is based on vendor qualification to assure that vendor has developed a system which meets all regulatory and user requirements specification for quality.

Answers of following questions are essential for vendor assessment.

“What type of assurance do you have that the software has been validated during development?”

“How can you be sure that the software vendor did follow a quality assurance program?”

Answer of above questions using risk based approach:

Documentation regarding the experience of working with the vendor.

Working experience of other end user with particular vendor to be useful when your company has no experience with that vendor

Assessment checklists to verify the identification and performance of validation activities

3rd party audits

Independent assessment of the software system and/or development process

Direct vendor audits

For actual assessment of the vendors’ quality system and software development and validation practices.

Final procedure should be based on justified and documented risk assessment.

Computer System Validation Steps

7.7.1 Design Qualification and Specifications:

Detailed specifications related to functioning and operating of the computer system is stated in Design Qualification. It also explains various important decisions regarding the selection of supplier.

All the required functional and performance criteria of computer system should be included in the DQ, for the successful implementation of the intended application and fulfill all business requirements. There can be huge business and technical impact if there are errors in DQ occurs. Hence it is wise decision to invest adequate time and resources in the DQ phase.

Design Specification generally includes the following steps:

Brief description of the task assigned to the computer system which it is expected to perform

Explanation related to the proposed use of the system

Explanation regarding the intended environment within the system (For example, the network environment)

Description regarding the selection of the functional specifications, system requirement specifications and vendor

Vendor assessment and selection process description

Description of the final selection of functional specification, the system requirement specifications and final supplier selection

Description related to the final system specifications’ development and documentation

A well documented procedure should be followed in the development of user requirement specifications. Involvement of representatives of all user departments in this process is the most important point to consider here.

Following key attributes should be included in the user requirements:

Necessary – There may be drastic increase in development, maintenance and support costs as well as validation cost due to unnecessary functions.

Complete – Add all functions initially with caution without missing them because at a later stage it will be much more expensive than including them initially. 

Feasible – There must be implementation of all specified functions on time because that will delay the project.

Accurate – All functions must be accurately specified to solve the applications problem.

 Unambiguous – Developer must avoid wrong interpretation and guessing.

Testable – Functions that are not able for test applications cannot be validated.

Uniquely identified – These sorts of specifications can be linked to the test cases.

7.7.2 Installation Qualification:

Verification regarding the computer system has been established as per design specifications, installed properly in the selected environment, and that environment is suitable for the normal operating condition and use of the instrument is the goal of Installation Qualification. Before and during installation the list of steps below should be recommended and followed.

Before Installation:

For installation site requirements owner should consider manufacturer’s recommendations

Test the site for the execution of the manufacturer recommendations

During installation:

Evaluate computer hardware and software received from vendor with purchase order ( which includes, software , spare parts and accessories)

Verify documentation for entirety and un-ambiguity (For example, operating manuals, standard operating procedures for testing , maintenance instructions, safety and validation certificates)

Test computer system hardware and peripherals for any type of damage

Install hardware (which includes, computer, peripherals, cables, network devices)

Follow the manufacturer’s recommendation to install software on computer

Check for the correct software installation, (For instance, whether all files accurately copies on the computer hard disk, utilities to do this task are proper for that software).

Ensure back-up copy of that particular software

Organize network devices and peripherals, (For example, printers and equipment modules)

Categorize and make a list of all hardware description (which includes drawings for networked data systems)

Prepare a list of description of all software installed on the computer

Store design and pattern settings either electronically or on paper

List SOPs and equipment manuals

Prepare and organize an installation report

7.7.3 Operational Qualification:

Demonstration of functions of a computer system according to its functional specifications in the selected environment is the target of Operational Qualification (OQ) process. Computer system functions and utilization of those functions for particular use is the major point to be considered before OQ testing is done.

Documented and justified risk assessment is the basis for determination of extent of testing. Basic Criteria to consider here are:

Impact on Business Continuity

Impact on Product Quality

Information taken from the Vendor on Type of Tests and Test Environment

Complexity of System

Level of Customization  

Whenever the system is developed for a specific user, most extensive tests are essential. All functions must be tested by the specific user in this case. Tests are performed for functions which are highly critical for the operation or for functions that can be influenced by the environment.

The GAMP Categories 3, 4, or 5 are well enough to justify the level of customization. Category three states the standard software without customization and configuration setting. Category 4 identifies a configurable system and Category 5 involves fully customized system. Extent of testing increases from the lower risk and standard system to the higher risk with full customization.  

7.7.4 Performance Qualification:

PQ is the process which demonstrates that a system consistently performs as per the specification suitable for its regular use. For regular preventive maintenance of computer system it must work in a manner that consistent performance is achieve throughout life cycle, For instance, introduce changes to a system in a controlled manner and regular testing to ensure consistency.

Checking and testing of the computer system with total applications is the practical definition of the PQ. For example, proper testing of running system in which important type of system performance characteristics are considered and compared with documented predetermined limits. 

Generally PQ testing activities includes,

To verify and prove that the entire applications work as intended, complete system testing is done. For instance, performance qualification for computerized analytical system is carried out by introducing and running a well distinguished sample through the system and compare the results with previously obtained results.

Regression testing:  Data files are reprocessed and compared the result with previous result

System is scanned for regular virus

Computer systems are audited at regular time intervals

7.8 Configuration Management and Change Control Procedures

User can make any change in computer system validation because there is a possibility of an error in the program set for the computer system or due to different function specifications of computer hardware or software. Initiation, authorization, implementing, testing of any changes to written specifications, programming codes or hardware system should be done as per written procedures. A specific form is required to initiate, authorize and document any change.

All tasks related to change control procedures should include in validation master plan and should be documented in validation report. User should test part of the program that has been changed. Moreover, User should do regression testing for entire program to ensure that program will run normally after any change made in it.

7.9 Back-up and Recovery

Back-up and recovery is required in case of system failure to store existing data to e available in future. There is a more than one strategies for back-up and recovery. Different approaches include policies and procedures which facilitate consistent approach for system back-up and recovery to various system infrastructures. This would be useful to simplify back-up & recovery management. To reduce the variability in management of recovery, standardization desktop configuration is the best approach. One can use thin client computing architect ring concentrates recovery process to decrease workload and personnel required in back-up and recovery process. New back-up system called Worm media that means write once, read many provides higher security with more integrity for backups.

Different Backup & Restoration Strategies

Strategy

Description

Cost

Traditional Back-up to Tape

Manual process of copying data from hard disk to tape and transporting to secure facility

Low

Back-up to Electronic Tape Vault

Copying data from disk to remote tape system via WAN link

Medium to High

Disk Monitoring

Copying data written to one disk or array of disks to second disk or array of disks via WAN link

High

7.10 Error Handling and Corrective Actions

System user should specify different error handling actions like Root Cause Analysis, CAPA, OOS and DMAIC etc in validation master plan.

Root Cause Analysis – What happened at when and why??

Structural investigation that aims to identify the true cause of problem, and action necessary to eliminate it.

CAPA – Non conformances are investigated to the root cause level & resolved

Periodic management reviews address preventive action

DMAIC – Define, Measure, Analyze, Improve & Control

OOS – What went wrong??

Out of all these Quality Management System, CAPA is the most widely used corrective action. It focuses on investigation into depth of the problem to prevent recurrence of the problem or to prevent from occurrence. After implementation of CAPA, it should be evaluated for its effectiveness. Moreover, combination of CAPA and Root Cause Analysis is the best way to correct any problem in a very effective way. Together use PDCA concepts as per Deming-Shewart cycle. This is nothing but Identification & Investigation of the problem, Root Cause Elimination, Review and evaluation for effectiveness of implemented actions.

7.11 Contingency Planning and Disaster Recovery

As computer system is a man made system, it can be failed to work. When system fails, there should be a contingency planning and recovery procedure to restore the data existed in failed system. Before system gets failed, data has been generated and stored on the computer system as per PIC/S guidelines for use of GxP computer systems. System user should develop SOPs for disaster recovery procedures to ensure that failure of the system is handled in a efficient & controlled way and all issues and risks will be corrected.

7.12 Maintenance and Support

Computer system needs maintenance for hardware as well as for software. Reasons of failure are different for both so there are a separate type of maintenance for hardware & software.

Types of Maintenance for Hardware:

Preventive hardware maintenance actions

Component replacement

Corrective changes

Types of Maintenance for Software:

Corrective Maintenance: Correction of errors

Perfective Maintenance: Improvement in software’s ability to work

Adaptive maintenance: Software changes to make usable in different environmental conditions

After making any changes, there is a requirement of regression testing to assure that parts of the software which is not changed was not impacted by parts that was changed.

After maintenance of the software, revised software should be validated and should document all problems identified during maintenance and all corrective and preventive actions taken to fix those problems. Modifications made into the system should be assessed to determine their impact on the system itself. Documents should be review and updated to determine whether they are affected by approved maintenance changes or not.

7.13 System Retirement

System retirement must be performed with proper planning and under strict control for data retention to be complying with regulatory requirements and policies and to store all existing data into newly replaced system. System retirement should be done as per written procedures and all procedures and results of action taken after failure of the system should be documented.

When computer system goes out of operation, it means the system is retired. Reasons for system retirement include old technology, redundant application, failure to comply with new regulatory requirements and replacement of the system due to lack of some advanced functions a new system has. If any GXP computer system is retired, system owner should make a formal request and implement a new system through change control procedure. Proper retirement plan should be developed and documented by system owner.

Retirement plan includes introduction and short description of a new system which is replaced the old system, all steps involved in system retirement procedure, personnel responsible for whole retirement process and timelines for implementation & completion of the procedure. In addition to this, rationale for the system retirement should be documented and maintained. Data migration from existing to new system is a critical part of the validation project and measures should be taken to ensure data migration & retrieval to new system is effective in terms of accessibility and readability of transferred data.

After completion of the retirement procedure, system owner should prepare a System Retirement Report and based on it, they can make a decision that old system should be switched off or fully decommissioned. Decommissioning plan development and documentation includes process of data removal from old to new system.

Other Project Related

Documentation 7.14 Validation Deliverables & Documentation

User Acceptance

Summary

Development

Documentation

Validation

Final

Report

User Acceptance

Protocol

Unit and Integration Testing Documentation

Qualification

Documentation

Supplier audit

Documentation

Training Records and SOPs

Documentation

Inclusion of all information from validation planning to validation completion is called validation documentation. Following figure represents all steps & information related to validation without bypassing existing system for procedures and documentation. It includes validation policies, guidelines, procedures, roles & responsibilities of validation team, validation deliverables, short description of the system going to be validated, computer system hardware & software specifications, test protocols, test results, risks associated with the project and corrective & preventive actions taken to correct some critical issues, final approval or rejection statement, etc.

System owner should make a validation report after completion of system validation. Validation report is nothing but a validation documentation which includes outcome of the validation project. In other words, it is a mirror image of the validation project plan. Final validation report is reviewed, approved and signed by system owner and QA people.

Standard Operation Procedures: SOPs to perform computer system validation is a major part of validation documentation as well as of validation master plan. Validation team should develop the specific procedures for the system which is going to be validated which includes following procedures.

Training for GxP, 21 CFR Part 11 and Computer Validation (S-125).

 Risk Assessment for Systems Used in GxP Environments (S-134).

 Validation of Commercial Off-the-Shelf (COTS) Computer Systems (S-271).

 Validation of Macro Programs and Other Application Software (S-263).

 Risk-Based Validation of Computer Systems (S-252).

 Development of User Requirement Specifications for Computers (S-253).

 Quality Assessment of Software and Computer System Suppliers (S-274).

Auditing Software Suppliers: Preparation, Conduct, Follow-up (S-273).

 Development and Maintenance of Test Scripts for Equipment Hardware, Software and Systems (S-237).

 Handling of Problems with Software and Computer Systems.

 Data Back-Up and Restore (S-317).

 Disaster Recovery of Computer Systems (S-319).

 Archiving and Retrieval of GMP Data and Other Documents (S-162).

Access Control to Computer Systems and Data (S-320).

Configuration Management and Version Control of Software (S-259).

Change Control of Software and Computer Systems (S-262).

Revalidation of Software and Computer Systems (S-260).

 Retention and Archiving of Electronic Records (S-315).

 Qualification of PC Clients (S-289).

 Retirement of Computer Systems (S-261). 21. Review of Computer Systems.

Auditing Computer Systems (S-272) [2]

7.15 Templates and Validation Examples

To document validation tasks, roles and responsibilities of each personnel and outcomes of validation, templates and validation examples would be very helpful to determine how much validation is needed and how to perform validation. Lab compliance has examples for this.

Requirement Specifications for Chromatographic Data Systems (E-255).

Requirement Specifications for Excel Applications (E-268).

 User Requirement Specifications – 20 Good/Bad Examples (E-308).

 Computer System and Network Identification (E-326).

Template/Examples: Test Protocol for Excel Spreadsheet Application (with traceability matrix): Includes 12 test scripts examples for functional testing, boundary testing, out of range testing and test traceability matrices: tests vs. specifications, specifications vs. test cases and test summary sheet (E-358).

Testing of Authorized System Access (E-362).

 MD5 Checksum File Integrity Check Software with Validation Documentation: DQ, IQ, OQ, PQ (E-306).   [2]

8.0 Conclusion

As each task needs planning to have better positive outcomes, validation of computer system also needs planning for successful completion. Whole validation process should be planned according to required regulations. Validation Master Plan is the document which is developed by organization management and other personnel associated with validation process. It is an important tool to understand all validation activities, roles & responsibilities of each personnel, how the computer system works, change control management, what type of maintenance it requires and system retierement plan when system gets failed.