VAL-110 Computer Validation Guideline

The scope of this document is limited to the validation of Computer Systems utilized in a GxP environment. A computer system is a computerized system plus it’s defined operating environment. Computer validation aspects which are inherent to discrete manufacturing and laboratory equipment are addressed in the mechanical equipment qualifications. Separate computer validation documentation is only raised for standalone systems and SCADA (Supervisory Control and Data Acquisition) systems, which interact with more than one item of equipment. Separate validation plans and guidelines may be written for large scale systems. Interfaces between computer systems are also covered by this guideline.

The implementation of computer and computerized system validation shall follow the Lifecycle model and the principles of validation discussed in this guideline as applicable. Qualification documentation shall be of a similar style and content to the documentation used for equipment validation and in the case of computerized systems, protocols may cover both the controlled equipment and the controlling system. Table 1 summarizes the validation lifecycle. All phases of the lifecycle detailed below are not applicable to all categories of computer systems.

The validation strategy will depend on the type of hardware and software and the development quality of the software. This flow chart should be used as a basis for determining the validation activities and the documentation required.

6.1 Computer System Validation Lifecycle

6.2 Definition Phase of Lifecycle

6.2.1 User Requirement Specification (URS)

The User Requirement Specification defines “what” the intended use of the system is. The URS should include all essential requirements (musts), and if possible a prioritized set of desirable requirements (wants). Requirements should be linked to Performance Qualification, which tests the system in its operating environment, including the associated procedures.

This document is required if new software system is being considered, either purchased or developed locally For legacy systems the URS may be replaced by a document that defines user requirements. The URS may evolve with the development of the computer system and therefore should be formally approved and maintained as a controlled document. The URS should be developed by the System Owner and approved by the Site Validation Committee (SVC).

6.3 Planning Phase of Lifecycle

6.3.1 Computer System Register

All computerized systems at a site that require validation, the validation approach to be taken, and the documentation required shall be defined in the Validation Master Plans (VMPs) and/or Validation Project Plans. An inventory is to be maintained of all existing computerized systems used in GxP related operations and should be updated to include new systems. The validation status should be documented.

6.3.2 Impact (Risk) Assessment

All new computer systems (software project requests, computer hardware requests), legacy computer system or any changes to GxP systems must be assessed for their effect on product quality prior to project/change implementation. The Impact Assessment must be performed during the planning phase and must include in its scope the URS and FS to determine if functions affect regulatory compliance. The Impact Assessment should include a list of all functions and processes assessed and results of the assessment. The Impact Assessment will be used as part of the change control system to determine validation requirements. If validation is required system components should be assessed and categorized to determine the validation approach required. The output from this assessment will be documented in the validation project plan or protocol as required. If the review determines that validation is not required then a justification must be documented.

6.3.3 Vendor Audit

Prior to purchase of bespoke or user configurable software a vendor audit should be performed to ensure that the software has been produced to appropriate quality standards. The audit should be performed by qualified quality auditors and if required a computer systems experts such as an IT representatives. The audit report must be completed prior to initiation of testing. The audit results shall be documented and used in the testing strategy. If the audit results in a status other than acceptable, purchase and implementation of new systems or components from the supplier shall be suspended until quality issues have been resolved.

Audits are only required for category 4 and 5 software. Where an audit is not required for category 4 or 5 software, justification must be documented. For standard software packages, firmware, and operating systems, documented assessment of successful market history or supplier evaluation in the form of a review and analysis of publicly available information such as bug reports or reviews shall be documented and approved by the Site Validation Committee.

An evaluation shall be performed and documented that addresses the support and recovery of each system to ensure business continuity in the event that the developer is no longer able to provide support services.

6.3.4 Validation Project Plan (VPP)

A Validation Project Plan (VPP) shall be prepared for computer validation projects. The VPP shall reference the design documents and shall define as a minimum the intended use, principle hardware and software components, validation scope and approach, system boundaries, responsibilities (including Vendor/Contractor/Consultants), the validation documentation to be prepared and the deliverables.

The validation approach will depend on the software/hardware category, complexity and GxP criticality of the computerized application, which is determined by the impact assessment. The result from the assessment will provide the basis for the validation work effort and can be documented in the VPP or for a small system, or minor change in the validation protocol.

6.4 Design Phase of Lifecycle

6.4.1 Functional Specification (FS)

The FS shall be prepared by the system developers and shall describe how the system will function. The FS shall identify the process and functions to be provided by the computerized system in order to meet the requirements defined in the URS. The FS must be maintained current and reflect the system as implemented. The FS for configurable software packages shall be derived from the FS obtained from the system supplier. Where the system developer FS is not available, the FS shall be derived from the vendor-supplied manuals. The FS links to Operational Qualification which tests all the functions specified. The FRS should be approved at minimum by the system owner and the Quality Authority and maintained as a controlled document.

6.4.2 Design Specification (DS)

Design Specifications shall be prepared by the developers and IT/Engineering as required. Design Specifications shall specify minimum requirements for system hardware and system software, or ancillary software tools and the baseline configuration. This stage identifies how the System will meet the FS. The DS must be maintained current and reflect the system as implemented. The DS shall be approved at minimum by the system owner and the Quality Authority. Design specifications for operating systems, standard and configurable software packages shall consist of the documentation of the system configuration.

6.4.3 Design Qualification

Design Qualification shall be performed to ensure that all applicable regulatory compliance registration requirements have been defined in the URS and addressed in the FS and DS. Design Qualification can be documented as a Traceability report.

6.5 Construction Phase of Lifecycle

6.5.1 Coding

The construction phase of configurable and custom software packages includes programming, unit testing, integration testing, and code and/or configuration review(s). Documentation of the construction phase shall include, and is not limited to:

a.  Approved coding standards,

b.  Configuration documentation,

c.  Documented source code,

d.  Documentation of code review(s), and

e.  Unit and integration testing documents (e.g., protocols, test procedures, or test scripts) and results.

For such documents created and maintained by an external developer, the documentation shall be reviewed during the software developer audit. For internally developed software, the documents listed above shall be generated and maintained internally by IT and/or Engineering and shall be approved by the Quality.

Source Codes for all Custom Developed Software must be available, either in escrow or in site custody. All configuration parameters and settings must be managed the same way as source code is managed. In addition to the code itself, any options used to create the code (e.g., compiler options) must be documented. A Complete Source Code History, beginning with the initial implementation, must be in place for all versions of the source code that have been implemented and used to support regulatory compliance. Source Code shall be reviewed for, and not limited to the following:

a.  Elimination of dead-code,

b.  Structural modularity,

c.  Compliance with naming conventions, and

d.  Annotated code.

Limited access shall be provided to source code and it shall be maintained under site change control

6.5.2 Unit/Module Test

Unit tests may be carried out on custom software packages to ensure that the unit meets its pre-defined specifications prior to integration to the completed system. Unit testing should be approved by Engineering / IT. Tests shall include at minimum, functional, stress, boundary and error testing, and testing of alarms.

6.5.3 System Integration Test

A system integration test protocol for custom software packages should be produced where more than one software module has been produced. This test defines those tests that demonstrate that all software units communicate with each other correctly and the software system meets its pre determined acceptance criteria. If software is to be integrated to an existing system, the change request should define the procedure for integration and the units/code affected. The integration tests should be approved by Quality, Validation, Engineering and IT.

6.6 Installation and Configuration

User documentation (e.g., User Guides), technical documentation (e.g., installation guides, wiring diagrams), and baseline hardware and software configurations shall be available prior to the initiation of testing.

6.6.1 Factory Acceptance Test (FAT)

Prior to the installation of the system at the site, a Factory Acceptance Test may be carried out at the vendor’s premises in the presence of site personnel. This should be conducted following a FAT Plan/Protocol approved by the vendor and site. If the FAT is performed according to formal procedures and it can be demonstrated that the items tested will not change upon shipping and installation, it may not be necessary to repeat these tests at the installed site.

6.6.2 Site Acceptance Testing (SAT)

SAT may be performed prior to IQ/OQ/PQ and should ensure that the system operates as indicated in the Functional Specification and meets the user requirements as defined in the URS. The SAT should be approved by Quality, Validation, Engineering/IT and the User Group. The SAT may be combined with equipment and plant commissioning and this will provide a basis for IQ/OQ. Testing performed in the SAT, if documented according to site procedures may not need to be repeated in the OQ.

6.7 Testing Phase of Lifecycle

6.7.1 Validation Test Strategy

The test strategy shall be defined in the validation project plan. Protocols shall be approved prior to execution of the tests. Executed test protocols shall be reviewed by a person other than the tester after execution and must be approved by the Validation Steering Committee (VSC). Validation test scripts should not be written by the system developers.

The type of validation testing is determined by the risk assessment and is documented in the VPP. The level of validation testing required will depend on the impact assessment and the vendor audit results. Testing should be based on approved test specifications and formally reported, reviewed and approved. Test plans/scripts should detail the system being tested (including omissions), the scope of the tests and detail the procedure for each test as well as the acceptance for each test. Test scripts should test normal operations and challenge/stress conditions.

6.7.2 Installation Qualification (IQ)

The purpose of the Installation Qualification is to verify and document that all the key aspects of the hardware and software installation, including operating system details adhere to approved Design Specifications (including Hardware and Software Design Specifications if applicable), manufacturer’s recommendations and environmental conditions. An IQ protocol shall be prepared and will define the level of validation required. The IQ protocol may be separate for hardware and software. IQ must be performed in the production environment. If a validation environment is used for OQ, then IQ must also be performed in the validation environment, to demonstrate the equivalence of the validation environment with the production environment.

6.7.3 Operational Qualification (OQ)

The purpose of the OQ is to verify and document that the individual and integrated components of the System performs reliably and consistently within specified operating ranges as stated in the Functional Specification. OQ testing will be based on the Impact Assessment. OQ testing shall be conducted in a production environment or a validation environment that has been demonstrated to be equivalent to the production environment. An OQ protocol shall be prepared for each of the Systems and will define the level of verification required.

Operating software will be indirectly tested during OQ. Therefore OQ should include at minimum, security, time, date and network conductivity to qualify the Operating Software. Changes to Operating Software shall be assessed for qualification requirements.

There may be overlap between the testing performed at the System Integration Testing or Site Acceptance Testing stages. At the OQ stage it is not necessary to repeat tests that were performed as part of the Integration or Site Acceptance Tests. These documents may be referenced and reviewed as part of the Operational Qualification provided that the vendor audit demonstrates that the software is produced to a quality system and that the level and quality of testing and documentation of testing is acceptable to the Validation and Quality group.

6.7.4 Performance Qualification (PQ)

The purpose of the PQ is to challenge the fully configured release of the System in its normal integrated environment. A protocol shall be prepared which will verify the performance of the System in accordance with the approved URS, Standard Operating Procedures and related documentation. Testing will be developed to challenge the System as it is used and operated under routine conditions and environmental parameters. This includes the review of each procedure that interfaces with the System and provides evidence that the procedures are in existence, current, applicable and being followed. Sections of the PQ can be incorporated into the OQ for some Systems. PQ testing shall be performed in the production environment.

6.7.5 Retesting

Retesting shall be performed according to an approved protocol, if the testing does not meet the acceptance criteria. Retesting shall be documented, reviewed and approved. Any retesting as a result of a deviation shall be approved and documented as part of the deviation.

6.8 Reporting Phase of Lifecycle

6.8.1 Qualification Report

A Qualification Report is to be prepared summarizing the results and execution of the IQ, OQ and PQ. A final report summarizing the completed validation study shall be approved prior to use of the system and prior to release of any product produced using the system.

6.8.2 Traceability Report

A Traceability Report will be generated for each project. This report will detail traceability between the User, Functional and Design Specifications and the qualification testing, and list all relevant qualification documentation. Any acceptance criteria specified in the IQ, OQ or PQ protocols should be traceable back to earlier phases of the lifecycle.

6.9 Additional Validation Requirements

6.9.1 Core Computer Systems

For systems developed and installed at the site centre location Quality Assurance and  validation / Technical Services team shall review and approve core validation related documents. The Site Validation Committee shall approve the validation documents and is responsible for ensuring that the system implementation and configuration are covered by the core validation activities. A copy of the core validation activities will be maintained on site. validation activities shall include as required:

a.  Validation Project Plan

b.  Site specific specifications

c.  Training

d.  SOP preparation

e.  IQ

f.  Site-specific OQ

g.  PQ

h.  Final report

6.9.2 Electronic Data, Electronic Records and Signature

Computerized systems using electronic signatures or systems used to create, modify, maintain, or transmit electronic records for regulatory compliance shall be validated. In the event where Site uses electronic records or signatures the following policy shall apply:

a.  Electronic signatures are accepted as the equivalent of any written legal signatures they may replace.

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

c.  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, the original entry, the new entry and if applicable the reason for any amendment.

d.  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.

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

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

6.9.3 Network Qualification

Network qualification will be performed on all networks used for GxP systems. Network Qualification details those tests to be carried out to ensure that the network to be supplied meets the Network Design Specification. These qualifications also verify:

a.  Identification and description of the physical components;

b.  Critical information on configuration of routers and bridges;

c.  Transport protocols;

d.  Network operating system; and

e.  A diagram of the network topology including any links to the hardware and other networks.

Corporate IT Compliance and Standards shall serve as the Quality authority for IT managed information technology infrastructure.

Network Qualification shall be performed upon installation of the network and after any major change to the network (e.g., addition or deletion of switches or routers) and shall include, and is not limited to:

a.  IQ based on the Design Specifications,

b.  OQ of the network infrastructure (i.e., backbone) to verify connectivity between all connections to the network, and

c.  OQ of clients connected to the backbone to ensure proper operation of the client.

The network should remain in a validated state during the operational phase.