VAL-210 Computer Validation Master Plan

1. Introduction

[Enter company name] manufactures and distributes a range of sterile and non-sterile, liquid, veterinary biological and pharmaceutical products from their sites [address].

The GMP facility has Code of Good Manufacturing Practice (cGMP) licenses with the [List all licenses]. 

The core business focus is manufacturing and packaging of human and veterinary medicines in various forms. These include sterile injectable vaccines, oral, powders, creams, ointments, lotions, pastes and tablets and pour –on drenches.

This document aims to summaries the overall intentions and approach to the validation of automated system or computer system (known hereafter as computerized systems).

It is intended to be a working document and will be periodically updated by site management responsible for the execution of validation.

Systems addressed by this document are contained in the following list.

[List of Computerized and Automated Systems] used in the facility.

This Computer Validation Master Plan (CVMP):

– Identifies which computerized systems are subject to validation or qualification

– Identifies appropriate standards and guidelines to be referenced.

– Describes functional requirements for testing.

2. Purpose and Scope

The purpose of the Validation Plan will be to outline the principles and objectives of the Computer Validation Program for the [site]. Validation activities will be determined to be the sum of all activities that are conducted to ensure that the systems of manufacture are sufficient to produce products of a high quality that are safe for the intended user of the product.

The control of computer systems which impact GMP activities is important to assure control of processes, assessment of data, accuracy of manufacturing and control records and compliance with industry regulations.

This guideline provides guidance on how to validate computer systems that relate to GMP. This document should be considered as a guide; it is not intended to establish any mandatory or implied standard. Alternative approaches may be applicable.

This document will define the validation of all GxP computerized systems used by [company] including, where appropriate systems used by administration and quality groups (QA, QC, Regulatory Affairs Validation). This document does not define the requirements for the validation of Excel spreadsheets.

3. Regulatory Standards

[company] agrees to comply with Good Validation Practices for computerized systems as defined in the code of GMP [reference].

4. Responsibility and Training

4.1 Validation Resources

[company] will provide an appropriate level of competent resources to ensure the achievement of the outlined Validation program, with consideration of the risk to quality associated with the manufacture of products at [company] manufacturing sites.

4.2 Authority and Responsibility

The general authority and responsibilities for undertaken Validation projects are defined in the Validation Master Plan (VAL-080).

[Company] acknowledges computerized systems require special expertise and the co-ordination of key personnel and those involved with operation and maintaining computer systems.

Persons with appropriate expertise should be responsible for the design, introduction and regular review of a GxP related computer system.

The responsibilities of the key persons in manufacturing and quality departments are not changed by the use of computers. Electronic signatures are the legally binding equivalent of any written signatures they may replace.

4.3 Training

Persons responsible for the operation and management of computerized system shall be appropriate trained. The requirement of training includes ensuring those responsible for aspects of design, validation and installation of computerized system.

5. Validation Approach

The control of computer systems which impact GMP activities are important to ensuring control of processes, assessment of data, accuracy of manufacturing and control records and compliance with industry regulations. The Validation program for computerised systems shall be carried out in compliance with [Company] Quality Management System (QMS) strategy and the company’s Validation Master Plan (VMP).

Computerised systems will be documented in an approved Master Computerised Systems Lists (MCSL) which will be reviewed and approved at least annually or as required. The validation of computerised system shall be under taken on a priorities plan.

When a computer system is in the process of replacing a manual operation the two systems should be operated in parallel until it has been shown that the computer system is operating correctly. Records of the parallel operation, deficiencies found and their resolutions should be recorded in the appropriate validation documentation.

Changes to an existing GXP computer system should be processed in accordance with a defined change control procedure which should document the details of each change made, its purpose and its date of effect and should provide for a check to confirm that the change has been applied correctly.

[Company] will define its approach to the validation of computerized system based on the assessment of risk (5.1), the stage of system within the system life cycle (5.2) and the classification of the software (5.3).

5.1 Risk Assessment

A risk based approach will be undertaken to determine the level and scope of the Validation Program for computerized systems.  General procedures for undertaking risk assessment are documented (VAL-135 Risk Assessment for Computer Validation Systems).

Results from the risk assessment of computerized systems can be used to support future implementations of similar systems; therefore, a separate risk assessment is not typically required for similar systems with the same intended use.     

5.2 System Life Cycle

The requirements and activities for the validation or verification of computerized system will be different based on the stage of the system within its life cycle. Therefore, it is important to ensure a systematic approach is undertaken from design to retirement. The lifecycle approach for validation activities is discussed in Validation Master Plan (VAL-080).

GAMP 5 – Software Classifications

The extent of validation or qualification of a computerised system will be based on the assessed level of risk and category of the software. Software will be classified as either GAMP Category 1, 3, 4 or 5 defined below:

Category 1 – Infrastructure Software

Includes operating systems and layered software components such as database managers, middleware, and ladder logic interpreters. Also included are tools used to manage infrastructure, such as network performance monitors, batch scheduling tools, etc. This class is considered to be low risk due to two primary factors.

First, infrastructure software is so ubiquitous that it is extremely unlikely that any unknown faults will exist. Second, this software is challenged indirectly in all other testing activities.

While proper function of IT infrastructure may well be critical to satisfying a Critical Quality Attribute (CQA), infrastructure will almost always have an extremely low probability of failure. Applications built on top of this software may fail, but it will seldom be attributable to failure of infrastructure software.

Validation of infrastructure software is not required however records of the systems and their versions may be maintained in the MCSL. If a new version of the system software is required, a review should be conducted to determine the possible impact of the changes on the existing software application(s), and system configuration files.

Category 2 – (Firmware) is no longer a separate category since modern firmware can be so sophisticated that there is no longer any justification for differentiation. Firmware can fit into any of the categories depending on the nature of the embedded software.

Category 3 – Non-Configured Software (NCS) or Standard Software

This category has been expanded to include many examples of firmware. Non-Configured in this sense refers to configuration to meet the needs of a business process; run-time parameters can still be configured. Off-the-shelf software has grown in sophistication to the point where some examples are configurable to meet the business process, and hence could be considered Category 4.

Equipment qualification or verification documentation will require a reference to firmware versions and configuration settings. A validation assessment is required for all firmware upgrades. The qualification of operation and control functions of firmware should be considered as part of new equipment qualification.

User-derived functionality developed using non-configured software (e.g. a report, macro or a program) require validation if it involves GMP aspects. Implementing new versions of a NCS package require assessment of the user-derived functionality with respect to impact on data integrity, security, algorithms, high-level language code and macros. Additionally, due to the ease by which changes can be made by the user, formal change control is imperative.

Categories 4 – Configured Software

These software packages are called configured software and include Distributed Control Systems (DCS), Supervisory Control and Data Acquisition packages (SCADA), manufacturing execution systems and some LIMS and MRP packages. In these examples the system and platform should be well known and mature before being considered in category 4, otherwise category 5 should apply.

A typical feature of these systems is that they permit users to develop their own applications by configuring/amending predefined software modules and also developing new application software modules. Each application (of the standard product) is therefore specific to the user process and maintenance becomes a key issue, particularly when new versions of the standard product are produced.

Category 4 packages may require a vendor audit (i.e. discretionary) to be performed depending on the overall criticality of the system. The audit if required should be emphasised on the unit and system testing of the package along with documented evidence of a quality approach to system development. The outcome of the audit will dictate the testing approach required at the user site, and this should form the basis of a validation plan and test plan.

Categories 5 – Custom or Bespoke Software

These are custom-built applications and include also the custom-build interfaces implemented when installing a configured package. For these systems the full Life Cycle should be followed for all parts of the system. It should be noted that complex systems often have layers of software, and one system could exhibit several or even all of the above categories.

Third party supplier audit are generally required (depending on the overall criticality of the system) to examine their software development quality systems. The amount of subsequent validation activity is dictated by the information obtained from the software supplier.

Excel Spreadsheets

Excel spreadsheets (Spreadsheets) can be used to record and manipulate (change, delete, add) GxP data and as such need to be managed to ensure the continued integrity and security of that data.  While some are no more than simple calculation tables others are embedded with special features and use intricate logic in the form of Macros that are in effect computer programs.

Spreadsheets fall into a special category of software classification due to their widespread use in many critical GxP areas and their wide level of complexity. The validation and management of spreadsheets is documented in VAL-170 Guideline for the Validation of Excel Spreadsheets

5.3 New or Legacy Systems

Computerized systems can be divided into two classifications: New or Legacy.  Determining the appropriate classification for each system is dependent upon the date the system was released for use. 

The following definitions dictate the classification of systems:

– A Legacy System is defined as a system that is in operation for its business purpose on or before the approval of the first version of this document.

– Computerized systems that were purchased, under development or implemented into production on or after the approval of the first version of this document are classified as new systems.

New systems will be prospectively validated / qualified to ensure compliance with the system development life cycle model. It is expected that the extent of those activities within be defined based on the classification of the software and the systems perceived risk.

Legacy systems will be assessed firstly to determine their potential risk and then documented with the MCSL. Legacy systems will be validated retrospectively based on a priorities plan.

5.4 Regulatory Guidelines

Dependent on the risk level or complexity of the system, computerized systems are also required to be assessed against appropriate regulatory standards for system function (for example, an applicable Australian Standard).

6. Software Development and Validation – Category 4 and 5 Software

A User Requirements Specification (URS) shall be prepared specifying the objectives of any proposed GxP related computer system, the data to be entered and stored, the flow of data, the information to be produced, the limits of any variables and the operating program(s) and test programs, together with examples of each document produced by the program, instructions for testing, operating and maintaining the system and the names of the person or persons responsible for its development and operation.

The development, implementation and operation of a category 4 or 5 GxP related computer system shall be carefully documented at all stages and each step proven to achieve its written objective under challenging test conditions.

Software developers of Category 4 and 5 systems should follow a Software Quality Assurance Plan (SQAP) and should be audited if possible for adherence to the plan. Vendors should be asked to provide written assurance that software development or modification has followed the SQAP or an equivalent system.

A logic flow diagram or schematic for software should be prepared for critical evaluation against system design / requirements / criteria.

Records should be available for the following aspects of a computer system validation:

– Protocol for validation

– General description of the system, the components and the operating characteristics

– Diagrams of hardware layout/interaction

– List of programs with brief description of each

– System logic diagrams or other schematic form for software packages

– Current configuration for hardware and software

– Review of historical logs of hardware and software for development, start-up and normal run periods

– Records of evaluation data to demonstrate system performs as intended (verification stage and ongoing monitoring)

– Backup and recovery procedures

– Range of limits for operating variables

– Details of formal change control procedure

– Records of operator training

– Details of access security levels/controls

– Procedure for ongoing evaluation

Individual validation protocols for all qualifications and validations will define the actual validation testing which will be required.

7. System Documentation

A written detailed description of the system should be produced (including diagrams as appropriate) and kept up to date. It should describe the principles, objectives, security measures and scope of the system and the main features of the way in which the computer is used and how it interacts with other systems and procedures.

8. Security of Computer Systems

A hierarchy of permitted access to enter, amend, read, or print out data shall be established and documented according to user need.

Suitable methods of preventing unauthorised entry shall be available, such as pass cards or personal user-identity codes.

The recovery procedure to be followed in the event of a system breakdown shall be defined in writing. This procedure should be designed to return the system to a previous state.

Methods of recovery shall be validated based on the criticality of the system.

9. Batch Release

Where the computerized system controls the final release of product special consideration and or more rigorous testing should be considered to ensure only a deliberate release by an authorized person is capable.

10. Electronic Data, Electronic Records and Signature

[company] may use electronic records and electronic signatures during the manufacture or quality control of products. In the event where [company] uses electronic records or signatures the following guideline shall apply:

– The entry of critical data into a computer by an authorised person (e.g. entering a master processing formula) should require independent verification and release for use by a second authorised person or the computer system.

– The computer system should create a complete record (“audit trail”) of all entries and amendments to the database. The audit trail shall include, the identity of the person, date, time and if applicable the reason for any amendment.

– Data collected directly from manufacturing or monitoring equipment shall be checked by verifying circuits or validated software to confirm that it has been accurately and reliably transferred.

– Similarly, data or control signals transmitted from a computer to equipment involved in the manufacturing process should be checked to ensure accuracy and reliability.

– The computer system should be able to provide printed copies of relevant data and information stored within it.

11. Computerized Systems

A list and brief description of GMP computerized systems covered under the scope of this master plan is contained at the first section of the document.  A brief discussion of the wide area network and other systems are included below.

11.1 Wide Area Network (WAN)

The system owner of the Wide Area Network (WAN) is the IT Manager. The following mechanisms are used to protect the integrity and security of the WAN;

– Corporate policy on Internet Code of Compliance

– Protection by local and network firewalls

– Documented procedures for automated nightly backup of data

– User Account Access Restriction

11.2 Other Computing Systems

Software or firmware can be embedded into many automated devices from inkjet printers to temperature controlled units (TCU) and production Programmable Logic Controllers.

As it would be impractical to identify and assess each piece of software individually it is considered to be an accepted practice that these systems will be validated or verified as determined via risk assessment as an item of equipment or an instrument or system.

In such case where this practice is implemented consideration shall be given within the relevant protocol to the functionality of the software. Example of these items include

– Basic filling machines

– Air-conditioning system where the room or installation is qualified.

– Temperature Controller units such as fridges and contained incubators

– Simple lab instruments and equipment.