SOP for Validation of Computer Systems

PURPOSE

The purpose of this SOP is to define the process for the validation of a Computerized System.

This policy document is not intended to provide comprehensive technical and regulatory guidance for all systems. To ensure a validation effort is performed in line with current best practices, additional guidance should be sought from the documents.

SCOPE

• This validation procedure applies to any computerized system that is deemed to have an impact on GxP activities within Pharmainfo Ltd. Examples of such systems include, but are not limited to, automated manufacturing or laboratory equipments.
• Computerized systems where the validation strategy has been approved before the approval of this directive are not within the scope. It is incumbent upon the local quality unit to ensure that local and regional requirements have been met.
• Specific integrated components of a larger system such as HVAC or packaging lines, that do not generate, store or process GMP-relevant data for the purpose of quality decisions may be excluded from this procedure and validated as part of the commissioning process.

RESPONSIBILITY

• It is the responsibility of All staff and contractors involved in the installation, implementation and validation of computerized systems to adhere to this procedure.
• It is the responsibility of the regional/local quality unit to ensure that their local computer system validation SOPs conform to the requirements of this document.
• It is the responsibility of the Process Owner and/or the System Owner to ensure the validation activities are performed in full and in compliance with regulatory requirements and global and local procedural requirements.
• It is the responsibility of the Process Owner to ensure that any staff involved in the validation or qualification of a computerized system will have received training in this procedure.
• It is the responsibility of the Head of Quality Assurance to ensure that a list of GxP computerized systems is maintained and that all such systems are controlled within the lifecycle described within this policy. This list may be implemented as a portion of the Computerised System Validation Master Plan.

REFERENCES

• SOP: Initial Risk Assessment Procedure for Gap Computerized System
• SOP: Computerised System Risk Assessment Procedure
• SOP: Preparation of The Validation Plan for Gxp Computerized Systems
• SOP: PREPARATION OF SPECIFICATIONS FOR Gxp Systems
• SOP: Supplier Assessment Procedure for Computerized Systems and Services
• SOP: Testing of Computerized Systems
• SOP: Procedure for Periodic review of GxP Computerized Systems.
• SOP: Glossary of Terms for Computerised System Validation within Pharmainfo.
• Eudralex, Volume 4, Annex 11: Computerised Systems-European Commission Health And Consumers Directorate-General
• CFR Part 11 Electronic Records; Electronic Signatures; - Department of Health and Human Services Food and Drug Administration
• 21 CFR Part 211.68 Current Good Manufacturing Practice for Finished Pharmaceuticals Automatic, mechanical, and electronic equipment-Food and Drug Administration
• Good Practice for Computerised Systems in Regulated “GxP” Environments- Pharmaceutical Inspection Convention Pharmaceutical Inspection Co-Operation Scheme
• A Risk Based Approach to Compliant GxP Computerized Systems (GAMP 5) - International Society for Pharmaceutical Engineering.
• Guideline on Management of Computerized Systems for Marketing Authorization Holders and Manufacturers of Drugs and Quasi-drugs-Director of Compliance and Narcotics Division, Pharmaceutical and Food Safety Bureau, Ministry of Health, Labor and Welfare.

DEFINITIONS

• URS – User Requirement Specification.
• Supplier – An organization or individual internal or external to the user associated with the supply and/or support of products or services at any phase throughout the system’s life cycle.
• Risk Mitigation – Activities, processes, design or redesign of a process or system, undertaken to reduce risk.
• Risk Identification – The systematic use of information to identify potential hazards.
• Risk Evaluation – The comparison of the estimated risk to given risk criteria using a quantitative or qualitative scale to determine the significance of the risk.
• Risk Control – Activities, processes, design or redesign of a process or system, undertaken to reduce risk
• Risk Analysis – The estimation of the risk associated with the identified hazards.
• Risk – The combination of the probability of occurrence of harm and the severity of that harm.
• MES – Manufacturing Executions System.
• LIMS – Laboratory Information Management System.
• ICH Q9 – A guidance document issued by the International Conference on Harmonisation describing an approach to quality risk management.
• HVAC – Heating, Ventilation, and Air Conditioning.
• Hazard – A situation, action, or item that poses a potential threat to product quality, patient safety, data integrity, or to business continuity.
• GxP – International pharmaceutical requirements and applicable national legislation and include GMP, GLP, GDP, good pharmacovigilance practice and medical device regulation.
• COTS – Commercial Off-the-shelf software.
• GAMP – Good Automated Manufacturing Practice.
• (Source) Code – 1. Computer instructions and data definitions are expressed in a form suitable for input into an assembler, computer, compiler or other translator. 2. The human-readable version of the list of instructions [program] that causes a computer to perform a task.
• Bug – An error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.
• BCP – Business Continuity Plan.
• Audit – A systematic and documented process for obtaining evidence and evaluating said evidence objectively to determine the extent to which criteria are fulfilled.
• Assessment – The process of evaluating a (potential) supplier.
• Process Owner - The person responsible for a business process, as well as ensuring associated computerized system validation activities and operational controls are performed in compliance with regulatory and quality requirements.
• System Owner - The person responsible for the availability and maintenance of a computerized system and the security of the data residing on that system.

ALSO READ: SOP for HPLC and GC Software Validation

PROCEDURE

1. Validation Overview

• The validation cycle should establish documented evidence, which provides a high degree of assurance that the system will continue to operate in a reliable and reproducible manner, according to the documented requirements and within a controlled environment.
• Figure 1 shows a general approach for achieving compliance and fitness for use. The application of this general approach will vary widely depending on the risk, complexity, and novelty of the system. Beginning in Section 2, each module is explained.

• Within the application of this approach, a number of key concepts shall be applied for the management of the validation of a computerized system. These are:

1. Use of a quality-managed Lifecycle from the concept of the system, through implementation and normal operation including the retirement of the computerized system. The compliant state of the system must be maintained until the system is decommissioned. Appropriate documented procedures must be developed and adhered to as required.
2. Scalable life cycle activities shall be performed based on the outcome of one or a number of risk assessments and supplier assessments. The validation effort should be practical and defensible to an auditor. Scientific risk assessments can significantly reduce the validation effort and provide a documented justification for the scale of the activities.
3. System complexity, maturity, and the underlying process shall be considered when evaluating risk. The functionality required to control the underlying process, along with the amount of data to be stored, recalled, processed,  and secured will have an impact on the system complexity and must be considered when developing the validation activities. Additionally, the architecture of the hardware and software that comprise the computerized system are factors which impact upon system complexity. The configuration of the software application(s) and software functionality must also be considered.
4. Validation efforts need to give due consideration to regulations for all jurisdictions into which Pharmainfo ships and sells materials.
5. Leveraging of supplier involvement throughout the system lifecycle activities. The supplier may be able to provide a considerable degree of expertise through the process that can provide justification for a reduction in the validation activities. Where documents are supplied, these shall be reviewed to ensure that they are acceptable prior to use.

2. Planning

• The purpose of the planning phase is to assess the risk and complexity of the system and to identify the key activities and resources required for the implementation of the computerized system as a whole.
• For larger, more complex systems the development of a project plan and cross-functional project team may be required.
• The user requirements shall be developed during the planning phase.
• The degree of validation required depends on system size, complexity, intended use, and the potential risk to data integrity, product quality and patient safety. The outcome of the supplier assessment shall be considered within the validation planning.

Validation Responsibilities:

• Depending on the scale and complexity of the system the project or validation plan or specific separate protocols shall define the roles and responsibilities of all relevant staff such as Process Owner, System Owner, Qualified Persons, and IT.
• When third parties (e.g. component suppliers, service providers) are used within the validation effort or for the ongoing maintenance and use of the system, it is the system owner’s responsibility that the responsibilities of the third party are clearly stated and documented.
• Depending on the size and complexity of the system, third party responsibilities may be defined in separate formal supply or service agreements, or they may be integrated into the project or validation plan, or defined within the protocol for which the services are being used, such as a hardware installation protocol.
• Internal ongoing responsibilities shall be described within the appropriate SOPs.

ALSO READ: Why Three Batches are Taken for Validation?

Risk Management:

• Risk Management shall be applied throughout the lifecycle of the computerized system to determine the extent of the validation activities required at each phase.
• While each assessment may review different aspects of the system, e.g. software development process, computer hardware, or functionality and process control, the fundamental consideration shall be the potential impact on data integrity, product quality or patient safety.
• An initial risk assessment shall be performed to establish GxP criticality of the system, the level of lifecycle documentation deliverables and verification to be undertaken, and the extent of supplier assessment to be performed. This ensures the scale of the effort is appropriate to a specific system.

Supplier Assessment

• The technical knowledge, experience and reliability of a supplier are key factors when selecting a product or third-party service provider.
• Any assessment must review whether a formal planned approach has been used by the developer to assure quality. A quality system for quality assurance in design, development, production, installation and servicing should be demonstrated.
• A rigorous testing regime shall demonstrate the operational functions, and also the structural integrity of the software and identify any weaknesses.
• The need for an audit, shall be based on a risk assessment.
• The instructions for the performance of supplier assessments shall be found in the ‘Supplier Assessment procedure for Computerised Systems And Services’ SOP.

Validation Plan

• A Computer system validation plan shall be produced for each GxP system. The level of detail shall reflect the level of complexity, function or process to be controlled and the identified risk.
• The validation plan shall define the activities to be undertaken to demonstrate the system is compliant to regulatory requirements and is fit for purpose. It shall also describe how this is to be documented and reported.
• It is the Process Owner’s responsibility to ensure that the Validation plan is prepared. Preparation may be delegated to a project manager, validation lead, or system owner.
• Approval of the validation plan shall include the Process Owner (unless prepared by the same) and the local/regional quality unit.
• Further information and guidance are given in SOP ‘Preparation of validation plan for GxP Computerised systems’, SOP.

3. Specification

• Specifications are developed to provide distinct measures against which the system can be tested. The specifications define the user’s needs, how the system operates, the build, and the configuration.
• The number of specification documents and level of detail within shall be commensurate with the risk, complexity, novelty and purpose of the computerized system.
• User shall be responsible for the preparation, control, approval and maintenance of the specification documents.
• Depending on system complexity, subject matter experts, including suppliers and other third parties, may be required in development of the specification documents.
• Specification documents shall be self-contained, precise, and unambiguous.
• For standard and non-configurable systems, detailed design specifications are not usually required as a deliverable. However, availability of detailed design specifications may be verified as part of the Supplier Assessment process.
• For custom systems, where a level of custom coding is performed, detailed design specifications may be required. This will be defined as part of the Risk Assessment. These documents will typically be prepared by the supplier and will be available for review and approval by Pharmainfo staff.
• The risk assessment process shall be applied to the specifications to identify potential risks. Subsequent verification shall be appropriate to the level of risk identified.
• Further information and guidance are given in SOP ‘ Preparation Of Specifications For Gxp Computerized System’.

ALSO READ: SOP for Preparation of Validation Master Plan (VMP)

4. Configuration and Coding

• Configuration extends beyond the primary software application of the entire computerized system including the hardware, additional software, firmware, and network.
• The requirement and the level of configuration activities will be dependent on the type of software and hardware components of the computerised system.
• The documents developed to describe the necessary configuration activities shall be suitably detailed to allow persons of suitable expertise to perform the operation in a repeatable manner.
• Where appropriate, it shall be possible to link specifications to configuration and verification activities.

• For standard and non-configurable systems, detailed design specifications are not usually required as a deliverable. However, availability of detailed design specifications may be verified as part of the Supplier Assessment process.
• For configurable systems, a Configuration Specification shall be required.
• For systems of lesser complexity, the Configuration Specification and Functional Specification may be combined in a single document.
• Further information and guidance are given in SOP ‘ Preparation Of Specifications For Gxp Computerized System’

5. Verification

• All GxP computerised systems shall require verification testing.
• The nature and extent of the verification activities shall be scaled according to the system complexity, use, novelty and outcome of supplier audit. The approach must be justified as part of a documented risk assessment.
• Typical testing shall include structural testing, functional testing, and performance testing. Testing should be performed in both the positive (as per normal operations) and the negative (challenge testing).
• Suitable subject matter experts, including suppliers and other third parties should be involved in the development, review and execution of verification test scripts and protocols. It may be appropriate to document such involvement in the document signatories.
• The verification activities shall demonstrate that the system:

1. The system is installed, configured and operating in accordance with the specification documents.
2. The system is fit for its intended purpose and poses no risk to data integrity, product quality or patient safety
3. The system is robust with adequate back up and failure recovery systems.

• Further information and guidance are given in SOP ‘Testing Of Computerized Systems’.

6. Reporting

• The purpose of the report is to summarise the validation effort and to assess the associated activities in terms of data integrity, product quality and patient safety. The report should also summarise deviations from the validation plan and any outstanding corrective actions and a statement of fitness for intended use.
• In addition to reviewing the completed activities, the report should outline how the compliant status of the system shall be maintained. This may be through existing quality systems or through new supporting processes established specifically for the system undergoing validation.
• The level of detail in the report shall reflect the risk, complexity, and novelty of the system. For large or complex systems, several reports may be required throughout the validation activities.
• Interim reports may be prepared in order to allow the release of phases or sections of the validated system and shall be documented in the Validation plan.
• The validation report should be reviewed by SMEs where appropriate, but must always include the process owner and the local / regional Quality unit.
• Acceptance and release of computerised systems shall require the approval of the process owner, system owner and the Quality Unit.

7. Supporting Processes

Operational Change and Configuration Management

• Throughout the life of the system, changes may be required. A documented risk-based assessment is required to assess and manage these changes.
• The operational change and configuration management procedure is an integral part of life cycle management. The risk assessment must identify any further validation activities that are required.
• Depending on the size and complexity of the system, separate procedures may be used for configuration and change management. Each procedure must clearly define the scope.
• The procedure may be site-wide or system-specific.

Performance Monitoring

• Performance monitoring is part of preventative maintenance. The data obtained can prove useful in diagnosing system problems and can be used to assess the performance impact of changes made to the system.
• The data can be used to build a trend that may indicate a shift in performance which can be used to provide early intervention and prevent or reduce system downtime.
• The need for and extent of monitoring activities should be based upon complexity, novelty and use of the system, and the risk to data integrity, product quality and patient safety.
• It is the responsibility of the system owner to ensure that the Performance monitoring is performed. This may be delegated and such delegation should be documented.
• For globally deployed centrally managed systems, Global IT will have responsibility the monitoring of global components of the systems; local components may be monitored by either the local site or global IT. The responsibilities shall be documented.

ALSO READ: Cleaning Validation Protocol

Incident Management

• A documented strategy shall be followed in the event of an unexpected incident should be defined .it shall describe the system for managing incidents to ensure continuity of business and to minimize the risk to data integrity, product quality and patient safety.
• Each incident shall be formally documented in an incident report logbook or other controlled system.
• As appropriate, the system owner/system administrator, the system owner, IT department and QA should decide the most appropriate actions to rectify the incident. These actions shall be documented and justified as part of the risk assessment.

Continuity Management

• A business continuity procedure should document the process to be followed in the event of system failure including any infrastructure.
• The business continuity plan should not put adverse risks on data integrity, product quality, and patient safety. Appropriate documented procedures, quality management systems, and training must be in place to support any alternative process to that of the computerized system.
• Business continuity planning will be defined for individual systems depending on risk and complexity.
• Failure protection shall be considered as part of the design specification.
• A business continuity plan may not be required for the systems assessed as Risk category LOW.

Backup and Restore

• A documented and verified backup and restore process will be established for specific systems as part of system lifecycle activities where it is determined that such a process will be necessary.
• The frequency of the backup shall be determined by the risk of data lost.
• A log of back up performed shall be maintained. This shall include an assessment of any errors that occurred, and corrective actions.
• The retention duration of the backed-up data shall be consistent with the data retention policy.

Security

• The extent of security controls depends on the criticality of the computerised system and the potential risk to product quality and patient safety.
• Access to the computerised system shall be restricted to authorised persons. This may be achieved physical and/or logical controls.
• Users shall have only the minimum functionally and access to complete their assigned role. Each role and associated functionality shall be clearly defined.
• A documented procedure shall be in place to control how access is granted to new users and remove users who left the organization. The procedure should also control how users may change role.

7. Periodic Review

• Periodic reviews shall be performed throughout the operational life of validated computerised systems in order to verify that they remain in a compliant state.
• The review frequency shall be commensurate with risk and complexity of the underlying process and the potential impact of the controlling system. The suggested review periods are as follows

Patient Safety Impact	Review Frequency
Low	Not less than 48 months
Medium	Not less than 36 months
High	Not less than 24 months

• A clear process for the timing and scheduling of the reviews should be documented. This may be incorporated into the existing site procedure on internal audits.
• It is the responsibility of the system owner to ensure that the system review is performed. This may be delegated and such delegation should be documented.
• For globally deployed centrally managed systems, Global IT will have responsibility for the periodic review of global components of the systems; the local site will have responsibility for local components of the systems including local processes and procedures.
• Integrity and accuracy of backup data and archived data, and the ability to restore the data shall be checked and monitored periodically.
• Issues found shall be documented and assessed accordingly to established risk and corrective actions.
• Every system must undergo periodic review as per the schedule irrespective of reinstallation/upgradation and retirement.

Data Archival

• Records and data that are stored on the validated computerised system and that are considered to be part of required regulatory records shall be retained for the same period as paper based batch documentation in accordance with regulatory guidance.
• A documented and verified archive and retrieval process shall be established for specific systems as part of system lifecycle activities where it is determined that such a process is necessary.
• The Data archive shall include all GxP data including audit trails.
• Archived data shall be readily available for business and regulatory purposes.
• The retention duration of the archived data shall be consistent with the data retention policy.

Decomissioning

• The GxP Computerized System decomissioning process must be planned, controlled, and reported. This involves decisions about data retention, migration, or destruction.
• The extent and rigor of planned activities should be based on periodic review results, system criticality and risks associated with loss of data. The process of decomissioning a GxP Computerized System will be governed as per SOP “Change Management Process”

Training

• It is the responsibility of the Process Owner to ensure that Staff involved in the development, maintenance and use of computerised system shall have the appropriate education, training and experience to perform their assigned tasks.
• It is the responsibility of the System Owner to verify that appropriate training has been undertaken during the validation process for both internal and external personnel.

8. One Document Concept

• Scalable life cycle activities shall be performed based on the outcome of one or a number of risk assessments.
• One Document Concept can be used, only for those systems where the Initial Risk Assessment (IRA) has been prepared and the system is determined as COTS and falling under GAMP Category -3 and risk category has been determined as “LOW”.
• The decision to use One Document Concept for validation of the system must be documented as part of the IRA.
• One Document Concept will also act as validation plan for the system and no separate document will be required for validation plan.
• The One Document approach integrates the following system life cycle documentation items but not limited to

1. Training
2. URS
3. Risk Assessment
4. IT Operations
5. Acceptance Criteria
6. Testing
7. List Of Discrepancies
8. Change Control
9. Assessment /Justification

• The One Document Concept template is designed such that the tests can be documented directly and the completed and finally signed document can be used as a Validation Report. 

ATTACHMENTS

1. Attachment 01: Template of user requirement specifications
2. Attachment 02: Template of installation qualification protocol
3. Attachment 03: Template of operational qualification protocol
4. Attachment 04: Template of performance qualification protocol
5. Attachment 05: Validation process flow
6. Attachment 06: Document hierarchy
7. Attachment 07: Questionnaire
8. Attachment 08: Validation Report
9. Attachment 09: One Document Concept Plan & Report

REVISION HISTORY

Nil

ALSO READ: SOP for Transport Validation