This article will give you a solid idea how computerized systems are validated using the GAMP 5 framework. This is about streamlining the scope of work to complete the project faster.

What is Computer System Validation – CSV?

The validation proves with documentation that computer systems used in industrial production adequately fulfill their automatic functions and contribute to ensure the traceability of produced batches and meets GMP regulations. Every computer system that has a direct or indirect relation to the production of the medicine, product for health or impact on traceability, must be validated, because it is a GxP system.

Regulatory requirements:

FDA 21 CFR Part 820

When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.

FDA 21 CFR Part 211

Appropriate controls shall be exercised over computer or related systems to ensure that changes in master production and control records or other records are instituted only by authorized personnel. A written record of the program shall be maintained along with appropriate validation data.

FDA 21 CFR Part 11

It is the FDA standard that establishes rules for use of electronic registration in the Life Sciences industries. In a very brief way, the system must broaden:

• Electronic tamper-proof files
• Audit Trail
• Access control
• Electronic signature = ID + password
• Retired user policies
• Accounts use guarantee by its genuine users
• Strict control of password recovery

The requirements of FDA 21 CFR Part11 are currently quite common in the market and if foreseen at the beginning of the project, it brings safety and necessary traceability for the good use of the system. For legacy systems that do not comply with the regulation, the best way is the Risk Analysis21 CFR Part 11 defines the requirements for electronic document , signature documents and signature submissions to the U.S. Food and Drug Administration (FDA). This law specifically details the FDA regulations for electronic records signatures and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper.

The 21 CFR 11 mandates that organizations using electronic signatures meet three distinct categories of compliance requirements:

1. Security for closed systems (subpart B, Sec 11.10)
2. Security for open systems (subpart C, Sec 11.30)
3. Requirements for executing an electronic signatures (subpart B, Sec 11.50 and Sec.11.70; Subpart C).

Under 21 CFR Part 11, a system is described as either closed or open.

• A closed system is an environment which system access is controlled by individuals who are responsible for the content of the electronic records that are in the system.
• An open system is an environment in which system access is not controlled by individuals who are responsible for the content of electronic records that are in the system.

The regulation requires manufacturers to validate software that is used as part of the production or the quality system for its intended use (21.CRF.820.70 (i). In general, software used as part of the production or the quality system falls into one or two categories:

• Software that is used directly as part of the production or the quality system.
• Software that supports production o the quality system.

Both kinds of software are used as “part of the production or the quality system and must be validated under 21 CFR 820. However, supporting software often carries lower risk, such that under a risk-based approach, the effort of validation may be reduced accordingly without compressing safety.

On the other hand, software with the following intended uses generally are not considered to be used as part of the production of the quality system, such that the requirement for validation would not apply:

• Software intended for management of general business processed and operations, such as email or accounting applications; and
• Software intended for establishing or supporting infrastructure not specific to production or the quality system, such as a networking or continuity of operations.

Data Integrity

One of the key requirements for the computer system is to ensure that the generated data in production is complete from the beginning to the end of the process.
It means that the system must be able to keep records of who entered the system, when, what was the action, why it was done and where it was done.
Normally, the impact on data integrity is primarily related to this production batch data traceability (depending on the validation focus system).

Why do I need to validate?

In addition to contributing for data quality and data integrity, the GMP validation lifecycle is valuable because it allows:

• Extracting all the needed available resources in the system to cover the specific process safely;
• Make the technical knowledge team more in-depth about the system, avoiding that the knowledge stays entirely on the hands of the supplier (opening the “black box”);
• Document technical discoveries, avoiding the loss of knowledge in an eventual exit of professionals of the company (risk to the business!);
• Explore all possible automatic features in order to avoid manual steps, leading to repeatability and reproducibility for the process (target of validation!);
• Direct the team to analyze necessary actions and documented procedures for contingency planning, data backup and application, and disaster recovery, reducing production downtime (risk to the business!);
• Reliability of process information avoiding operational errors.

Validation based on risk approach.

The study of the existing documentation to survey the risk scenarios is extremely important to know the particularities of the system to be validated and to meet cGMP guidelines. However, after some systems have been validated by the professional, some risk scenarios are invariably presented, such as the system behavior facing power outage, study of access profiles, access security, quality of electronic record produced by the system including audit trail, application of electronic signatures, etc.

It is important to emphasize that Functional Risk Assessment must be done by a multidisciplinary team due to the need of adopting mitigation measures for the risks which result in “medium” and “high” levels. The acceptance of these mitigation measures must be agreed among the team aiming to really be functional, whether they are adopting new work procedures or improvements in the system. The measures to be adopted become the validation strategy and they are the main points where GxP validation should focus.
* For the Functional Risk Assessment, the participation of the system supplier or developer is recommended. When this is not available, a professional can be hired with knowledge in this type of system that is being assessed.

GAMP5® Validation Guide

GAMP5® is a Good Automated Manufacturing Practice guide that is currently in its version 5 and was released in 2008. Since then, it has revolutionized the Validating Computer Systems method.

The guide is the main source of “inspiration” for Computer Validation professionals and has as its central axis the risk-based validation strategy (“A Risk-Based Approach to Compliant GxP Computerized Systems”).

Note.: although each company has its specificity, there are several standard processes within a type of system, for example purchasing processes within an ERP, which are common to different companies. Taking this opportunity, FIVE has developed a paperless e-validation software named GO!FIVE®, where users can select multiple libraries, according to the process or system they want to validate, and these libraries contain good market practices, regulatory requirements and much more. Click here and know our Paperless Validation Software.

GxP is a general term for the application of good practices. The ‘x’ indicates the area in which good practices are related (manufacturing, distribution, clinical research, laboratory, etc.). The relevant GxP system is any and all system that has impact on:

• Patient health;
• Product quality;
• Data integrity.

The best way to validate is undoubtedly, risk-based, whether it is a new system (prospective validation) or a legacy system (concurrent validation). If the risk results in ‘medium’ and ‘high’ levels, a mitigation measure should be envisaged. If mitigation or upgrade isn’t possible, system exchange should be considered.

URS – User Requirement Specification

Normally, these “medium” and “high” risk mitigation measures are detailed in the User Requirement Specification (URS), which becomes the reference document for system validation. If it is a non-configurable system, tests should basically be drawn up to prove that URS requirements have been met and some other typical system tests covered in the following GMP testing phases:

• Installation Qualification;
• Operational Qualification;
• Performance Qualification.

If the system is configured or customized to meet the needs of the user company, specification documents must be produced. Some examples:

• Functional Specification;
• Hardware Design;
• Software Design.

GAMP5® guide detail the exact life cycle required for each type of system and separate them as follows:

Classification / Categorization of Computerized Systems

GAMP®	Comments
Category 1	Infrastructure Software
Category 3	Non configurable product
Category 4	Configured product
Category 5	Custom application

• It is important to note that acquiring the vendor’s document package doesn’t reflect the completion of the validation work. It is necessary to “open” the document life cycle, with the issuance of the Validation Plan, Functional Risk Assessment and URS and “close” the lifecycle with the issuance of the performance test protocol, Traceability Matrix and Validation Report, documents that are not normally part of the solution provider’s scope.

Example of flow categorization to determine the validation scope and key deliverables.

Validation deliverables	Category 1	Category 3	Category 4	Category 5
Vendor Audit		X*	X	X
Validation Plan		X*	X	X
User Requirement Specification	X	X	X	X
System/ software Risk Assessment		X	X	X
Part 11 Checklist		X	X	X
Functional Specification	X*	X	X	X
Design Spec			X	X
Test Procedures	X	X	X	X
Validation Summary		X	X	X

*optional.

Need help with your validation activities? please book your free conference call at www.Q6consulting.com

Authors:

Alzira Martins, PhD, Executive Advisor @ Q6consulting LLC

Lilian Ribeiro, Coordenadora de Vendas na FIVE Validation;

Silvia Martins, CEO e Co-Founder na FIVE Validation

References:

GAMP5® is a guide that has its intellectual rights reserved by ISPE™. ( ispe.org.)

FDA 21 CFR Part 820, Quality System Regulation/ Medical Device Good Manufacturing Practices

FDA 21 CFR Part 211, Current Good Manufacturing Practices for Finished Pharmaceuticals

FDA 21 CFR Part 11, Electronic Records; Electronic Signatures

 

Do you need any help? Contact us! www.q6consulting.com.  Let’s do better together!

👉 Know someone who might be interested in this article? Share it with them.