A Complete Guide to Computer System Validation (CSV)

This guide aims to suggest the tools and strategies necessary and appropriate for use in the validation of computerized systems for (human and veterinary) Pharmaceutical Industries, Pharmaceutical Chemicals (APIs and excipients), Biologics, Biotechnology, Blood Products, Gas Medicinal Products, and Medical Devices, used in activities related to compliance with Good Practices (GxP), activities include:

• Manufacturing / Production (GMP)
• Clinics (GCP)
• Laboratory (GLP)
• Good Distribution Practices (GDP)
• Storage (GWP)
• Documentation (GDP)

It provides a suitable approach to compliance with all types of computer systems, according to national and international regulations; based on the guidelines established in the GAMP® 5 Guide ISPE, providing an understanding of the logics of work, definition of scope, and selection of the validation strategy that best suits the system to validate.

This Computer Systems Validation Guide is based on the following approaches:

• Risk-based approach
• Approach based on the life cycle of the system
• Approach on "V"-model for development and system test
• Approach based on the process which serves the system
• Approach on GAMP category system

This guide provides a general review of the guidelines required for qualification identifying regulatory infrastructure base (NOM / FDA / WHO), prior to the validation of computer system requirements is performed.

It also identifies the documentary base to support the validation of computerized systems, in accordance with the particular QMS of each organization.

This work is designed to be used regardless of their knowledge or experience related to validation or compliance with Good Practices, among others, the following areas or business functions:

• Administration
• Quality Unit
• Investigation
• Development
• Manufacturing
• Laboratory
• Engineering
• Maintenance
• Regulatory issues
• Human Resources
• IT
• Support staff
• Associated suppliers

Through the principles and methodologies suggested here, this guide will help the organization to ensure that computer systems prove their fitness for intended use, meet the good practices of the industry in an efficient manner, provide practical guidance to facilitate the interpretation of regulatory requirements, with a language and terminology easy to understand and interpret, clarify the roles and responsibilities of each of those involved in the validation of computerized systems.

Finally, this guide is designed for understanding the principles of validation of computerized systems by the most diverse personnel, both those who occupy this knowledge as part of their daily work and those who at some point will be involved in the effort to validate a system without any prior knowledge of Good Practices, validation or IT computer terminology, thus becomes a valuable tool for both and for anyone who wants to train others in basic and logical principles of work on Computer Systems Validation.

Currently, the Health Industries such as pharmaceuticals (human and veterinary), pharmochemical, (APIs and excipients), biologics, biotechnology, blood products, and medical devices, are required to establish a validation program to demonstrate that any procedure, process, equipment, material, activity or system actually leads to the expected results.

The computerized systems that have an impact on product quality, patient health, and good practices (GxP, as in the case of those who serve production processes, storage of inputs and finished products, insurance quality, documentation management, electronic records, etc.) must be validated, in order to meet normatively, ensure the integrity and traceability of information and product quality.

Computer systems with GxP impact are becoming of particular importance today due to technological advances in process automation and data management and information generated by applications, and the increasing acceptance and use of these technologies in both administrative industrial, and productive processes.

As computer systems are increasingly integrated into many of the most important business processes, they help to reduce or eliminate the risks inherent in manual processes traditionally performed by qualified personnel. Thus, the risks of "human error" are no longer constant, while increasing the productivity and efficiency of processes does not depend on people performing repetitive tasks or require a high level of effort, leaving human hands to control tasks and maintenance of these systems, which provides room for creativity and process improvement.

With the above, it should be emphasized that the use of computer systems does not completely replace the human factor, but rather enhances it, brings it to a higher level within the process, where human error still exists, but at another level. Equipment and systems still rely on humans to tell them "what to do" and "how to do it" and any human error in this part results in an error in the rest of the process. There is a phrase that says "The machines does not commit a mistake, but the humans do it". Wrong instructions will result in erroneous results. It is for this reason that the human factor is decisive in validating, from defining its responsibilities to the training and qualification of personnel.

Eventually, the growth of Artificial Intelligence (AI) integration into technology systems, mobile device interfaces, and the use of cloud-based systems presents new challenges for current validation schemes, which must demonstrate fitness for use and compliance with requirements at all times.

2.1. What is validation? What is a computerized system?

During the validation process of computerized systems, various stakeholders are belonging to parts of the company where the knowledge of issues related to validation, computer systems and information technology is usually not always the common factor. It is necessary to use common concepts to avoid subsequent misunderstandings or problems due to a lack of conceptual approval.

The following section lists some definitions of validation according to regulations and national and international guidelines:

Definition of Validation

NOM-059-SSA1-2015: "Documentary evidence generated through the collection and scientific evaluation of the data obtained in qualifying and specific tests throughout the entire life cycle of a product, which aims to demonstrate the functionality, consistency and robustness of a given process in their ability to deliver a quality product."

Food and Drug Administration (FDA): "Validation is the confirmation by objective evidence, that the previously established requirements for the use of a process or system are met."

WHO guidance on the requirements of good manufacturing practices (GMP): "Establishment of documentary evidence that provides a high degree of assurance that a planned process will be uniformly in accordance with the expected specified results."

The above definitions have the following elements in common:

• Generating evidence
• Compliance of requirements
• In accordance with expected results

The definitions that handle national and international standards and guidelines for computer systems must include:

Definitions: Computerized / Computer System

NOM-059-SSA1-2015: "Computer/computer system, any equipment, process or operation having one or more computers coupled and associated software or a group of hardware components designed and assembled to perform a specific functions group."

Food and Drug Administration (FDA): "Functional unit of one or more computers and input/output devices, peripherals and associated software, used in common for all or part of a program and storing all or part of the data necessary for program execution."

GAMP® 5 ISPE: "System containing one or more computers and associated software, network components, functions controlled by them and associated documentation."

Good Manufacturing Practice Guide for Active Pharmaceutical Ingredients (ICH7): "Computer system: hardware components and associated software, appointed and assembled to perform a specific function or group of functions."

"Computer system: process or operation integrated with a computer system."

ANSI: A functional unit, consisting of one or more computers and associated peripheral input/output devices, and associated software, that uses common storage for all or part of a program and also for all or part of the data necessary for the execution of the program; execute user-written or user-designated programs; performs user-designated data manipulation, including arithmetic operations and logic operations; and that can execute programs that modify themselves during their execution. A computer system may be a stand-alone unit or may consist of several interconnected units.

According to the above, you can define computer systems as a combination of hardware and software that perform functions for the process they serve (where process means, all the constituent elements of it, such as personnel, equipment, activities, input and output elements, related documentation, among others).

In other words, the computerized system is the combination of hardware and software in conjunction with the process they serve and its operating environment.

2.2. How are computerized systems classified?

To identify what must be validated it is important to know that the classification of computerized systems can be performed as follows:

• For its functions and design: Refers to identify, according to the functions performed, what kind of system belongs.
• Process: That is, according to the mode in which the system is being used. According to the needs of users, you decide what features are required to set up or if a system tailored to that function must be designed (see topic: Characterization of the process).
• System impacts: Identify the risks of computerized patient's health, impact on product quality, data integrity, and business to determine whether or not the system requires validation and scope of validation (see topic: What is the scope / impact of GxP).
• Category GAMP: After identifying the type of system, as used according to the process it serves and the risks inherent system classification according to the category GAMP be performed, which identifies whether this corresponds to a Category 1 (infrastructure software), 3 not configurable, 4 or 5 configured (tailored) and from here is derived which is the methodology to be followed for validation.

2.3. What are the types of systems functionality and design?

Depending on its functions and design, computerized systems can be classified into the following types:

Table 1: Types of computerized systems for functionality and design

3.1. What are known categories of computer systems?

It helps to determine the strategy and scope of system validation depending on the complexity and risks inherent in each category, both hardware and software. However, it will depend on their respective risk analysis to establish the same appropriate strategy. The categories suggested by the GAMP® are a good reference for determining the complexity and therefore the risks inherent in systems.

For example, in the validation of an ERP (SAP) Category 4 GxP to determine their impact and corresponding risk analysis (for each of its modules), you can decide not to challenge some of the functionality modules that compose (e.g. Finance), making only one installation verification this module if necessary.

3.2. How many categories are there?

There are 2 categories for Hardware and 4 for Software, although one is considered out of use (Category 2) from version 5 of the GAMP® Guide. Two important aspects are taken into account when determining the categories: the complexity of the system and the risk inherent in depending on their degree of proof (quality control software) during development. Thus, the more standardized and tested, the lower its category and therefore lower the standard of proof required for validation. On the other hand, the more personalized, the more need for configuration, and the least test conducted during development, will require more and detail in the validation challenges:

3.3. Why is there no category 2?

Category 2 was deprecated because when version 4 of the GAMP® was created, the firmware differed from the rest of the categories own characteristics. Today, it has evolved so that most of the firmware can be classified under category 3, 4 or 5, so category 2 disappeared. That's why there are only categories 1, 3, 4 and 5.

For example, there are cases of firmware for laboratory equipment, such as the firmware of a TOC (Total Organic Carbon Analyzer), which is based on the GxP impact and the risk analysis can be considered as category 3, which only requires a requirements review, or as category 4, which requires a more complete V-model.

3.4. What are the categories?

Category 1

Infrastructure software: established or commercially available software layer, e.g.: operating systems, database engines, programming languages, firewall, and antivirus and office software. It is on this software that the operation of business software categories 3, 4 and 5 depends. Without denying the existence of the category 1 systems, they will not be independently tested, but, indirectly when testing systems category 3, 4 or 5. Their proper operation is shown in the process they serve. This software during design and creation is subjected to extensive quality testing software.

Category 3

Non-configured systems: no configurations are freely traded in stores or as part of teams. These are called COTS (Commercial Off The Shelf). Examples include tools for statistical computing, software for data acquisition without configurability, Scribble control panels, spreadsheets only used as databases or documents without any configuration level, etc.

In this type of software there are very low or zero level settings that the user can personalize. They are sold as "as is" solutions because they are acquired as they are used (except worksheets category 3, which are not considered software "as is"). They have the advantage that the operation can not be modified, which means that the risks arising from incorrect operation is reduced. This generates the same disadvantage of having to adapt the processes to system operation.

The V-model which is usually the simplest, involves verification against user requirements only.

Category 4

Configured systems or products: Partially configurable software packages that allow you to run a specific business process. These configurations include, but are not limited to, operating parameters, measurement, and control, and can use other external interfaces to complete the function.

Examples of these systems are ERP (Enterprise Resource Planning), LIMS, Applications spreadsheet in Microsoft Excel with formulas and/or input data linked to specific cells (this is considered configuration), control systems production equipment associated with the process (e.g. autoclaves PLC), process control system as SCADA (depending on the degree of customization can also be category 5), systems of equipment quality control (M3 electron microscope), control temperature processes, among others.

The V-model usually includes the traceability of user requirements, functional and design specifications and protocols, Design, Installation, Operation, and Performance Qualification.

Category 5

Custom systems are those systems that are custom developed to meet the specific needs of the organization to optimize processes.

Examples are add-ons software for categories 3 and 4, MS Excel with VBA scripts, unique and dedicated systems, ERP systems, or developments of these facts to the specific needs of an organization, among others.

In the validation strategy for this category of systems it is recommended to put more emphasis on:

• Specifications and testing modules
• Design documentation and system operation
• Service-level agreement
• Technical support
• Updates
• Troubleshooting, errors and failures
• Change control

It is important to note that worksheets, depending on your level of configuration or customization (use macros or Visual Basic programming) can be considered category 3, 4 or 5.

Remember that in the case of the Mexican Health Regulation the qualification design based on user requirements is very important. Related to this requirement, it can include revisions documentary aspects mentioned above.

3.5. How many hardware categories are considered GAMP®?

There are two hardware categories based on their level of customization:

• Category 1 line: Most companies have regulated this type of hardware. It is standard hardware. Only verified and documented characteristics, and must be consistent with the need for software.
• Category 2, user program: Include additional elements to standard hardware, considered design specifications, and must undergo acceptance testing, aimed at evaluating suppliers. Its requirements are more robust and require detailed design specifications and performance. Category 2 hardware implies a higher level of risk of being less standardized and, therefore, less subject to pre-release testing and implementation.

3.6. What did computerized legacy systems inherit?

For purposes of this guide, you can define the legacy computer systems in 3 ways:

1. Computer system that has become obsolete, but still used by the user and not easily willing or able to be replaced or upgraded, or is no longer supported by the supplier.
2. Those who do not comply with the 21 CFR part 11 and launched before August 20, 1997 on old computer hardware according to FDA Compliance Policy Guide 7153.17. This definition applies only if it is consistent with FDA regulations.
3. Systems in use before the start of automated systems validation activities (should be included in the validation master plan).

During the preparation of the Validation Master Plan, it is necessary to identify the legacy systems and define the criteria to be cataloged in this way, and whose characteristics have advantages and disadvantages, as well as very particular risks to be taken into account when defining the strategy validation.

Since in legacy systems there are often no documents and much fewer tests performed during the design stage, the validation strategy can have different shapes, in relation to the development of requirements and specifications, for example:

In the flow chart of the validation guide ISPE legacy systems, it is observed that for a legacy system depending on its characteristics, you can choose to develop only the requirements or both the Requirements Specification and specifications. Furthermore, existing procedures should be evaluated and updated according to their risk, taking into account changes that the process and the system may have undergone. The appropriateness of each of the routes to take risk depends on the system and the required level of proof and the availability of information.

4.1. What is the validation of computerized systems?

Validation of computerized systems is a documented process to ensure that a computerized system does exactly what it was designed to do in a consistent and reproducible way (suitability to use), ensuring the integrity and security of data processing, product quality, and complying with GxP applicable regulations. The robustly and documented evidence shows that the system is suitable for the contemplated purpose and it is doing what it is designed to do, with the certainty that the result or the final product will have the expected quality.

Suitability to use

4.2. What is the suitability to use?

The suitability of the system involves verifying that the system is functioning properly according to the needs of the process for which it was acquired. This will be demonstrated during validation and routinely checked during operation.

4.3. How is the suitability for use demonstrated?

The suitability for use is demonstrated by compliance with all established (mandatory) requirements. Since the requirements are directly traceable to the protocol Qualification Execution or Performance (PQ) and indirectly traceable to protocols Installation Qualification (IQ) and Operational Qualification (OQ) (through the functional and design respectively, serving them to meet the requirements), it is the satisfactory conclusion of the PQ that we can state that it meets the suitability for use.

For the qualifying infrastructure, legacy systems and Category 3 may only test IQ true and OQ traceable requirements, in this case, the suitability to use is also demonstrated by compliance with user requirements.

GxP

4.4. What is GxP?

It is an acronym for Best Practices (x), where "x" stands for some of the best practices related to regulations and national and international reference guides. The English acronym is GxP, where G refers to Good and P refers to Practices.

4.5. What good practices are applicable?

Among others, the main Good Practices that apply are the following:

• Good Manufacturing Practice (GMP) is associated with the manufacture of a product, which is produced and controlled to quality standards for use, according to regulations that help ensure reliability to the final consumer.
• Good Laboratory Practice (GLP)
• Good Distribution Practice (GDP)
• Good Clinical Practice (GCP)
• Good Documentation Practice (GDP)
• Good maintenance practices
• Good industrial safety
• Etc.

4.6. What is the scope / impact of GxP?

The term refers to any action or omission that adversely affects any Good Practices defined as part of regulatory compliance. In the case of systems, processes, activities, equipment, facilities and personnel, they can have an impact if GxP serve to support compliance with one of the defined Good Practices.

Since the Validation of Computerized Systems provides an approach to risk, its proper determination involves knowing the GxP impact of systems from which the scope of the validation study are established.

4.7. What do you gain from knowing about the impact of GxP?

Knowing the impact of GxP allows for a better validation strategy, with particular emphasis on those points where there is an increased risk of negatively impacting the performance of Good Practice also to determine during characterization of the system if it is impact GxP allows differentiate those requiring validation for regulatory compliance of those who do not. The role of process owners and/or Quality System is crucial in this determination to be guardians and empowered the elements of the system under its interference in relation to each regulatory requirement.

In the inventory of computerized systems, the definition of those that have a GxP impact is important. This definition can be provided by considering the following aspects:

Functionality of systems with a GxP impact:

1. The creation, maintenance or preservation of records or documentation required by the Good Practice regulations for evaluating product quality and making security decisions.

2. Automation of Best Practices, product quality or product safety decisions.

3. The data output to other system modules or external systems with the above features.

4. The input process data from other system modules or other systems with the above features.

It is also important to generate evidence of why some systems are not considered GxP compliant. This evidence can be provided during system characterization using a checklist.

4.8. What are the different types of impacts of computerized systems?

There are 6 major types of impacts to be considered for computerized systems. These should be evaluated both in the initial risk analysis system and subsequent risk analysis (to requirements and during maintenance of validated state):

Examples of GxP impacts:

• Patient safety: This type of impact involves systems that release products and manage information for patient use (batch, instructions, expiration date), e.g. HPLC, software coding, etc.
• Product quality: This impact is directly involved in making or evaluating critical parameters, e.g. IR spectrum, TOC, PLC an autoclave, etc.
• Data integrity: The ERP systems, inventory control, document management systems, etc.
• Regulatory compliance: QMS control systems, spreadsheets with training plans or maintenance control, electronic logbooks, etc.
• Internal policies: Systems that manage the qualification of personnel, security systems, etc.

Examples of non-GxP impacts:

• Business: This impact is determined by how the malfunction, damage or loss of the system and/or information can result in economic (business) losses to the company. All systems have this type of impact to a greater or lesser extent. The business impact cannot be neglected it enables continuity of the organization that owns the system (user, according GAMP®)

It is important to remember that the same system can have more than one type of these impacts. For example: An ERP system directly impacts the business to manage company resources, but also, if you have a quality module, can have an impact on product quality, patient safety, and data integrity. In the case of the control system of a tableting, this can have an impact on product quality, but also on the integrity of the data it manages. Depending on the type of impact(s), it increases the criticality of the system.

4.9. Is there an order of importance for each type of impact?

The impact on product quality and patient health are the most important GxP impacts. The impacts on product quality, patient safety, and data integrity are crucial to the decision whether or not to validate the computerized system. In this sense, experience and end-user knowledge are of great value for the correct weighting of the impacts.

Although business impacts are not important from a regulatory point of view, they should be seriously considered since the business must continue to exist in order to generate value through their processes. An incorrect strategy that considers a potential impact on the business due to a breach of good practice, or costs not covered by the maintenance of the system or required by the validation study can result in significant losses that jeopardize the operation of the business.

For example: A drug distributor does not manufacture and does not perform analysis to determine the purity and identity of the drug. They have a system that manages the inventory and distribution. This system does not directly affect the patient safety, however, it may affect product quality if the distribution is not performed according to the manufacturer's instructions. Because of the affected product quality, patient safety may also be compromised. These impacts would generate a loss for both monetary and business reputation.

As the illustration above shows, possibly any of the other impacts can lead to an impact on product quality and this, in turn, has an impact on patient health.

4.10. How can the system impact internal company policies?

The failure of the quality management system policies has the most significant effect. It is therefore important that every staff member part of the validation process, becomes aware of them. Any breach of Good Practice may eventually cause business impact through loss of credibility with customers, loss of demands, plant closure, fines or damages to patients.

4.11. How can the system impact regulatory compliance?

The main impact on internal company policies is the failure of the quality management system policies. Therefore, it is important that staff involved in the validation process (IT, Human Resources, Quality, Validation, Production, Maintenance, etc) are aware of them.

An example is when a company does not adequately control the training and qualification of its personnel, resulting in unqualified personnel operating the system which breaks the validated state, increasing the uncertainty of the system and taking, therefore, the inherent risks.

4.12. How can the system impact business?

The absence of a validated system, failure to comply with the good practice provisions or falsification of results or evidence that does not take into account hidden costs of maintaining or supporting the system, the purchase of a system that will soon be updated, loss of money due to the system not having the required functionalities that would require changing the process, etc.

4.13. How can the system impact data integrity?

When it lacks controls for use, archiving, backup, restore, transmission and modification of data and information that the system manages.

An example: an employee, using control software inventory in the warehouse, has an error in moving product "X" between stores. An IT colleague responsible for the management system, solves the error of the employee by modifying the data. In this case the system is vulnerable and its information can not be considered as integrated.

4.14. What is data integrity and why is it important?

The FDA states in its guide "Data Integrity and Compliance With cGMP" the following: data integrity means that the data must remain Attributable, Legible, Contemporaneously recorded; Original (or actual copies) and Accurate. The above attributes are mentioned by the FDA under the acronym ALCOA as well as complete, consistent, lasting and available. These concepts have been reproduced in other guidelines and regulations.

When it comes to data, it should not be forgotten that it is part of the records managed by the system.

When dealing with data, there is a life cycle that generally includes the following steps:

• Generation
• Process
• Report
• Check
• Use for decision making
• Storage
• Discarded at the end of the retention period

Transfers between manual and/or IT systems may occur within these phases.

Data integrity must be maintained when the data managed by the systems are relevant for compliance with good practices, when part of the evidence of regulatory compliance or when they are critical for compliance and the measurement of product quality attributes or patient safety.

When the system is not able to support and maintain the integrity of the data it manages, a major risk is generated as these critical data can be falsified, deleted, disclosed without authorization, modified or denied by issuers. Data governance can maintain data integrity.

4.15. What is data governance?

It is the sum of total arrangements that provide assurance of data integrity, regardless of the process, format, or technology by which they were generated, recorded, processed, stored, retrieved, and used.

There are two types of data governance controls for maintaining the integrity:

• Organizational
  • Procedures
  • Staff training
  • Governance system design
  • Routine data verification
  • Periodic surveillance audits
• Technical
  • Computerized control system
  • Automation

Data governance should also have a risk approach (see topic: Risk Analysis).

4.16. How is data integrity verified?

Verifying the integrity of the data in electronic records system is done in two ways:

1. By routine verification of data and system logs at fixed intervals (checks, audits) (see topic: Maintenance of Validated Status).
2. By studying validation through the installation of testing protocols, operation and system performance (see topic: How to validate computerized systems?).

In developing the left side of the applicable V-model, there must be defined requirements and identified risks related to the generation, processing, reporting, verification, use for decision-making, storage, and discarded end of the data as well as making sure its attributes remain complete, consistent and accurate, attributable, legible, contemporaneously recorded, original and veracity copy, accurate, durable and available. When applicable, develop specifications for these data in accordance with the above.

During validation testing, the challenges necessary to identify and define the location of data and electronic records (IQ), the verification of processes and procedures creation, file transfer, the backup and restoration of data as well as the evidence for the maintenance check of these attributes during the operational process (OQ) and as part of the results of the (PQ), should be established (risk-based).

One element that contributes to the control of the data and the traceability of its integrity elements is the data audit (see topic: Data Audit) as this keeps an unalterable record of the actions performed with the system information.

Electronic signatures (see topic: What are electronic signatures?) also contribute to data integrity by allowing them to be attributed and verified for use in decision-making.

4.17. What are electronic records?

Electronic records are data and information that are created, modified, archived, retrieved and distributed by a computer system. Electronic records are GxP relevant and those that are not, the difference is whether or not the performance impact of good practice in force.

Until a few years ago the management of information was made 100% on paper; from procedures, records, production orders, logbooks, maintenance programs, among others. However, with technological innovation, more and better information management tools are emerging every day. Such as systems that manage the quality management system, manage inventory systems, production control systems.

Derived from this, some companies decide to eliminate the use of paper, and manage all or some of the documents electronically; the use of these tools brings benefits such as reduced costs, availability of information, ease in finding information, environmental benefits by reducing paper consumption; but it requires security measures to ensure the data integrity is at all times established.

Technological tools are becoming more accessible and versatile, allowing in some cases to make designs tailored to the needs of each customer and company, increasing the electronic records that are generated; however, not all records are subject to validation. It is important to discern which of these have GxP impact and therefore will be subject to verification/validation.

Testing electronic records during system validation demonstrates the integrity of the data being processed by the computer system. The file is given a name and a format with which it can be reproduced. Records to be checked during validation are those with a GxP impact.

4.18. What are electronic signatures?

It is a set of encrypted electronic data accompanying or are associated with an electronic document, whose basic functions are: unequivocally identifying the signer and ensuring the integrity of the information and data contained in the signed document.

Electronic signatures require the user to be able to identify themselves electronically in a manner equivalent to a handwritten signature. An electronic signature must have the same legal validity as a handwritten signature.

The standard also allows the use of biometrics and tokens.

Characteristics of an electronic signature and related best practices:

• All user actions can be configured to require signing or signing and authorization.
• Privileges on the use of electronic signatures should be set according to the authorization level of each user.
• Guarantee the identification of each user by removing accounts without deleting them.
• Usually, electronic records are linked to other documents, such as procedures, that are used for the same purpose and are used by the company to approve or reject the information contained in these documents.
• For purposes of FDA compliance, electronic signatures should also include the signature motif.
• As electronic signatures and their use may have a legal implication, it is necessary to document (via a policy in a procedure or a manual), the date from which they are implemented and its validity as equivalent to handwritten signatures and scope (on documents applicable).
• The organization will ensure that the electronic signatures remain unique and non-transferable to each user. This is achieved by verification of electronic signatures where at least one of the elements is only known to the user.

4.19. What does an electronic signature guarantee?

Authenticity: The document information and electronic signatures are undoubtedly from the person who signed it

Integrity: The information in the electronic text has not been modified after it was signed

Non-repudiation: The persons who signed electronically can not say it was not them

Notice: The information has been encrypted and the issuer will only allow that the receiver can decrypt

4.20. What are the risks associated with the use of electronic signatures?

Among the risks associated with the use of the electronic signature, it is known that it can be hacked. These risks, as always, are borne by the end user who uses it.

Digital signatures (other than digitized signatures), are a type of electronic signatures that have a higher level of security. To perform the digital signature, a username and two keys, public and private, must be used. The public key is what can be shown and accessed by a third party and the private key will be in no case known or accessed by someone else, because this key is integrated in our identity and our firm.

The exposure of the private key is a very high risk because its security is unique and ensures the security of electronic signatures. Anyone with the same key can create fraudulent signatures with the same legal value as a handwritten signature. Knowledge of the key by a third person can lead to phishing, can be passed around by the user and can be signed anywhere.

It is recommended to have a clear policy of control and password protection, and implement a secure system for managing them. The organization must ensure (and generate evidence of this) that the user is aware of the responsibilities associated with the use of electronic signatures.

The standard also allows the use of biometric identifiers and tokens to establish control measures that are not used by outsiders.

4.21. What does not require validation?

Throughout the chapter 'Why validate computerized systems' the reasons why computerized systems should be validated were described, however, it is important to identify which features or components of the computerized system do not require validation.

The clearest examples are the commercial operating systems, e.g. Windows, Unix, and Linux. They are infrastructure systems that are required for the application to work properly. However, these are indirectly verified during validation, because they are commercial systems. These are tested from a design by the companies that develop them.

Another example is antivirus and firewall, which as in the previous example, are extensively tested before the release and because they are constantly developing new infectious agents. They need to be constantly updated to protect companies from malicious agents.

Finally, office or complementary software such as Microsoft Office (Word, Excel, etc.), Adobe Reader, or Teamviewer are not subject to validation. They indirectly prove their operation during the validation of the software and document the business characteristics.

5.1. What are the main responsibilities?

Before the execution of validation, the people and areas that should be involved throughout the process must be identified. Each person must know and accept the responsibilities that apply.

There are 4 main responsibilities in the process of validation of computerized systems:

• Process owner
• System owner
• User
• Provider

5.2. Who owns the process and what is their responsibility?

The process owner, usually the boss or manager of the area that the process serves. There can be more than one process owner. He is the main actor of success, regulatory compliance, and economic benefits that the system can generate. He is called the process owner because he is empowered to make decisions about the process because of his hierarchical level, knowledge, and experience related to it, his interactions, and relationships.

The process owner may also be responsible for the system, however, this will depend on the type of system and the size of its operations. It is recommended that the process owner is a person who knows the company widely, not only process variables that serve the application but also the system.

Part of his responsibilities will include:

• Manage the development of user requirements
• Having a robust and comprehensive knowledge of the regulatory requirements related to the process
• Assemble the team that will participate in the operation, validation, and test execution system and provide the necessary resources
• Involvement in the risk assessment team
• Approve the documentation resulting from the validation
• Maintenance of the validated state
• Training management system users
• Elaboration of the required procedures for the process that serves the system
• Allocation of system operating personnel during validation
• Develop and report change controls
• Monitor the matrix training of the personnel involved
• Perform follow-up calibrations of equipment as required

Usually, he is responsible for the availability of information, configuration, maintenance, support, training of personnel, and the access control security system and takes measures to ensure compliance and GxP.

5.3. Who is a user and what are its responsibilities?

According to ISPE, the "user" refers to a pharmaceutical or consumer-oriented customer organization that engages a provider to provide a product. In this context, it does not only apply to individuals and is synonymous with customer. It is common to conceptualize the user as a personal direct contact with the routine operation of each of the activities within the process system, and defining the user causes problems when establishing user requirements because each conceptualizes their requirements from the limited perspective of their specific activities within the overall operation.

In these terms, we can have multiple levels of users. The most important is the one who has the overview of the process (managers, managers of the area or areas where the system serves, process, and system owners). Their level of responsibility is high for the results of the process and system. Second, we have the key users (can be any of the above), their characteristics are that they have broad skills and knowledge management system as well as a level of responsibility that allows them to supervise younger users or parts of the authorized process.

Finally, we have the younger users, who are those who are responsible for performing most system operations related to the entry and exit of information. They usually have very small and limited liability, the critical process steps run by the system often require additional monitoring and authorization.

As part of their responsibilities, are the following:

• Report errors in the system
• Communicate information about the requirements the system must meet to be suitable for the intended use
• Provide information about the process
• Data entry system
• Extract and use information system
• Support in the execution of validation tests

5.4. What is the responsibility of the (internal / external) provider?

Providers play an important role during the system life cycle and each of the selected stages of the V-model.

We can classify them as follows:

• Provider of computer system and consumables (implementation, support, maintenance)
• Provider of infrastructure (implementation, maintenance, support)
• Service provider qualification and validation

To reduce the possibility of any inconvenience with any provider, you must carry a rating and approval of this before purchasing supplies or services. Also, a way to eliminate risks associated with suppliers is to ensure that the UK, is established from the same purchase order.

Suppliers' responsibilities are defined in terms of the activities for which they are hired and the criticality of their participation in the process.

5.5. Supplier qualification

Given the criticality of its activities to the system and its results, it is important to define which suppliers should be qualified and which not. The criteria for this should be defined in each organization's internal policies.

The decision to perform a supplier qualification should be documented, based on a risk assessment and categorization system.

Supplier evaluations may include the following:

• Completion of a checklist audit by the supplier
• Gathering documentation from the supplier related to the development, testing, and system maintenance, including supplier procedures
• Site audit of the supplier's facilities
• Supplier's reputation
• Supplier's quality systems
• Collection of the documentation from the supplier on the system development
• Supplier questionnaire
• Staff competencies provider
• Historic quality (for already approved suppliers)
• Service-level agreement (SLA) if it meets the client's requirements for optimal performance and system maintenance
• Response times
• Contracts

Usually, for systems from suppliers with a lower category and therefore lower risk, a lower level of verification is required. For example, COTS providers, require a lower level of verification compared to the tailored systems.

It is important to always conduct a proper cost-benefit analysis of the appropriateness of an audit of a site provider versus a remote audit or merely documentary. In these cases, it is also important to mediate a risk analysis.

Each of the evaluated criteria should be given a grade that should be analyzed and documented in a report card of the provider, to indicate whether the supplier is approved or rejected, and what results are out of specification and what preventive and corrective actions should be taken by the supplier.

If the supplier is not approved or provides an unsatisfactory service, you should proceed with a check of the quality management system of the company that hired the supplier or a risk analysis to determine the frequency and scope.

5.6. What subject matter experts can be useful?

Having experts in the validation, implementation, updating, and removal of a computerized system is helpful because expert judgment is useful in increasing the reliability of decisions about the undertaken activities.

The informed opinion of people with experience in the subject, who are recognized by others as qualified experts, and can provide information, evidence, judgments, and assessments, is what gives value to the inclusion of experts in the field during the system lifecycle.

Experts in the field can be:

• People who develop software
• People who were responsible for the implementation of infrastructure
• People who implemented the software
• People who give support to infrastructure, servers, and PCs
• Users who operate the system daily

5.7. What is the responsibility of the area validation?

This area is responsible for creating the necessary documentation to validate the system and demonstrate what it says and does, and how it works, such as:

• Meetings with the process owners for the characterization of the process and system processing requirements, risk analysis, and specifications, as well as reviewing evidence and reports
• Meetings with the system owners for the characterization of the process and system processing requirements, risk analysis, and specifications, as well as reviewing evidence and reports
• Meetings with users who use the software every day
• Meetings with stakeholders to monitor the progress of validation
• Perform the necessary documentation for validation
• Run the protocols and document the evidence
• Develop validation reports
• Report if there is a deviation in the process

5.8. How are responsibilities assigned to the system and validation?

The responsibilities of those involved in the different areas involved in software validation, as outlined in the Validation Master Plan of Computerized Systems.

A validation committee (or equivalent) is formed with specific responsibilities that delimit the VMPCS. (See: Validation Master Plan).

5.9. What are the main problems that arise in the allocation of responsibilities?

The most common problems are:

• The lack of communication between the participating areas
• The lack of information on why you should validate software
• Not accepting the responsibility assigned to it and distancing themselves from it, arguing that the activities are up to other areas (Validation, IT, production, or quality)
• Areas arguing that they have the time to dedicate to software validation
• Assigning all validation activities to one area or person to be disregarded responsibilities from other areas, owners and users. The validation of computerized systems requires close collaboration with various roles and responsibilities where staff is responsible for integrating the information generated by other areas and functions involved
• Not knowing the process or setting it up incorrectly

Looking for expert CSV support? Our Software Validation team can help coordinate your validation project end-to-end.

For the implementation of the validation process of computer systems, it is extremely useful to view it as a project, depending on the criticality, impact, complexity, and risks of the system. Many variables are involved to control them in a timely manner.

It is common for validation activities to be subject to urgency and stress which in the case of systems with greater complexity (such as categories 4 and 5), increases the probability of errors if you do not have adequate management scheme activities and timing. For this purpose, it is important to start understanding both the process- or system-related activities as well as those related to the validation itself.

6.1. Who should coordinate the validation project?

The project coordination of the validation of any system is recommended to be carried out by a person who has the most control and knowledge of the system and the process, for example:

• In the case of ERP systems, it is recommended that the IT area coordinates the validation effort because, it is a system that serves several processes. That would not be practical for process owners to coordinate.
• In the case of LIMS systems for document management, it is recommended that the owner is the person who coordinates the process as they have better control over the process and system requirements.
• For spreadsheets, the same user would be responsible for coordinating and implementing the validation of the leaves.
• If your organization has a PMI or a project office, that would be the responsible entity.

Notwithstanding the above, it should not be forgotten that the validation of computer systems is a joint effort where various stakeholders provide information for the preparation of the elements of the chosen V-model.

It is important that all areas involved support and test the system.

Life cycle

6.2. What is the life cycle of a computerized system?

The life cycle is a period of time during which a computerized system 'lives' from conception to retirement. For companies, the concept of life cycle begins with the need or opportunity to automate one or more processes and ends with the retirement or replacement of the system that served for the automation.

A common mistake is to confuse the life cycle of a system with the "V"-model for the development and testing of the system, calling it a "V-model life cycle". These are two different things. The V-model will be discussed later as it relates to the stages of the life cycle of systems.

6.3. What is the life cycle approach?

The life cycle approach allows us to consider the characteristics of each stage for planning activities and scopes of validation, the risks and benefits for each stage and implementing the necessary controls.

6.4. What are the phases of the life cycle of a computer system?

At each stage you can perform various activities that typically accompany it. These steps become cyclical with each change, improvement or implementation of a new system.

6.5. Life cycle approach

The GAMP® Guide 5 establishes a life cycle approach as good practice for a better understanding of the system and its implications. This approach involves systematically defining and implementing activities from the four main phases:

1. System design
2. Draft
3. Operation (It is usually the longest phase)
4. Retirement System

Depending on the stage of the life cycle in which the system is in, the activities and V-model will apply.

Recommendations:

• Suppliers of products and services, as appropriate, can participate in improvement activities, maintenance, validation, auditing, etc., throughout the life cycle. It is subject to satisfactory evaluation measures and approval of the supplier (Supplier Rating).
• It is important to maintain an inventory of existing computer systems in the Validation Master Plan of Computerized Systems (VMPCS) or the General Validation Master Plan (VMP). This inventory is recommended to include data such as the date the system was implemented and the date the last validation was completed, so that the validation management can track what stage of the life cycle stage the system is in.
• As part of the initial system characterization stage of the life cycle it is in, prior to the validation study.

Table 2: Example inventory of computerized system

6.6. What are the characteristics of each of these phases?

Concept phase

The main activity of this phase is to establish the focus of the organization to justify the start of the proposed system implementation, defining the scope needed for enterprise resource optimization.

Initial requirements for determining the use of the system based on operational needs and the process in the same way may be the overall specifications for the system need their construction and use.

Project implementation phase

Phases of project implementation are:

• Planning
• Specification, configuration and coding
• Verification
• Reporting and release

Key supporting processes for project implementation compliance are:

• Risk management
• Change and configuration management
• Design review
• Traceability and document management

The results obtained during the execution of these phases provide documentary support for justifying the system as suitable for its intended use. This generated documentation can be used by the company as proof of compliance during inspections by the corresponding regulatory body.

Planning

Project planning includes the following activities to be carried out:

These activities are generally sequential, but may run in parallel or overlap.

In this phase, the requirements and specifications should be clear enough for a risk assessment and ultimately for a correct definition of verification tests (protocols).

In this phase, activities should be carried out taking into account the following:

• Impact of the system on patient safety, product quality, data integrity, business operations, internal policies and regulatory requirements
• Complexity of the system
• Capacity provider (vendor classification)
• System seniority
• Category System
• Existing GAPs

Specification, configuration and coding

During this phase, the following activities are performed:

• Specification: specifications are made with the level of detail required by the type of system and its use.
• Coding and configuration: Providers must choose and use the development methods and models most appropriate to the coding and configuration requirements and based on the approved specifications.

They should also ensure that their requirements and specifications take into account those coding needs and system configuration for the intended use and how these developments and configurations should be documented.

Verification

This phase confirms that the specifications have been met, through inspections and testing of the system (depending on the type of system). This phase is present throughout the project.

Qualification tests and validation infrastructure for new systems run during this phase.

Reporting and release

In this phase, the system must be acceptable for use in the operating environment, according to a documented and controlled process.

Release and acceptance for use in activities GxP should be done by the process owner and system owner.

A computerized system validation must be prepared at project closure, summarizing the activities undertaken, any deviations from the plan, and the results of the study.

In order to effectively maintain the system during operation, a handover (or release system) by the process owner, owner and operating system users is required as a prerequisite.

Operation phase

This phase is the longer phase, at this point you can still make changes to the software, hardware and process for which it has been released and authorized by the organization. These changes must be monitored and managed as part of continuous improvement and maintenance of the validated state.

System and infrastructure procedures must be continuously updated in accordance with the organization's quality management policy.

Retirement phase

This phase involves the removal, decommissioning and migration of data needed for decommissioning.

It reaches this stage when it is determined that the computer system is obsolete for the process for which it was designed, among other reasons because:

• The software is obsolete or has lost supplier support
• The hardware is not compatible with software updates
• The process for which it was designed has undergone significant changes that originally affected its suitability and use
• There are new and better options to replace (retooling)

6.7. What is the V-model?

The V-model is a graphical representation of software development and testing activities, including its verification and validation process.

The V-model can be viewed not only as the development activities and testing of the system, but also their sequence, their interrelationships and the validation process of the deliverables applicable to the V-model selected for each system.

It helps determine the best validation strategy according to the computerized system categorization, specifying the documentation to be generated and the type of tests to be performed at each stage of the validation process. Shows the logic of work in the process of system development and verification.

Determine in advance the V-model to be used so that those involved become familiar with the validation strategy to be followed.

6.8. How many V-models are normally handled?

Although several V-models and even combinations of them exist, 3 main models for the validation of computerized systems have been proposed in the GAMP® 5 Guide. Their selection and application depend first on the category into which it classified the computerized system and then on the evaluation of other factors discussed below.

6.9. What determines the application of each model?

It depends on the complexity, category, impact and risks, the degree of outsourcing of system components, the life cycle stage you are in, its age and maturity.

Each V-model test includes a degree system, this degree should be defined according to the criticality of the system or its components.

The definition of the applicable model should also be from a practical point of view that proves only what needs to be verified, without ultimately verifying less than necessary. In this regard, the experience of the validator and an appropriate risk analysis and characterization of the system are crucial for the correct choice of the V-model. In any case, when in doubt, it is preferable to increase the level test than to decrease it.

The models are not restrictive, so that if, for reasons specific to each system, more tests than mentioned in the model are performed for all or part of the system, it is possible to include them in the validation strategy.

6.10. How does the life cycle approach relate to the V-model?

Depending on the stage of the life cycle that the system is in, the chosen V-model and its activities can be placed so that they are more compatible with development activities and system testing.

The 3 V-models overlap indicating the increasing complexity of validation research based on the GAMP category.

Also, depending on the time set for project implementation and system validation, the V-model can be shortened or extended within the cycle of the system.

In any case, it is important to consider the following premises:

• The validation of the system should be completed before the release of the preferred system.
• The assessment infrastructure should be completed before the start of the validation preferred system. It can be performed in parallel, assuming the risk that in case of failure to pass the qualification infrastructure, the rest of the validation cannot be approved and tests must be repeated until the assessment infrastructure has been satisfactory.
• Extended runtime of the selected V-model may lead to loss of control over the validation process, unnecessary costs, changes that require reconsideration of the left side of the model, or obsolescence of the system.
• For new systems, the best time to begin the left side of the V-model (processing user requirements, functional and design specifications, as applicable) is during the system design phase and the best time to complete the right side of the V-model (developing protocol design, installation, operation and performance, as applicable) is before the system operation phase.
• For legacy systems, the beginning of the left side of the V-model (processing user requirements, functional and design specifications, as applicable) is usually during operation, as in the term on the right side of the model.
• Systems that have not completed their validation study in the operation phase pose a risk and therefore it is not recommended that the system be released through validation testing. An exception may be legacy systems, in which case they should establish controls to mitigate the release risk.

6.11. What activities constitute the validation process of computer systems?

The activities in the validation process of computerized systems are described through the deliverables of the V-model.

6.12. How is each phase related to the V-model and what are the deliverables in this process?

Mandatory deliverables for process validation of computerized systems are divided into prerequisites, protocols, reports and traceability matrix:

• Characterization system (highly recommended)
• User requirements
• Risk analysis
• Functional specifications
• Design specifications
• Design qualification protocol
• Design qualification report
• Installation qualification protocol
• Installation qualification report
• Operation qualification protocol
• Operation qualification report
• Performance qualification protocol
• Performance qualification report
• Traceability matrix

Not all deliverables are mandatory for all systems, this depends on the V-model chosen for each validation and its scope.

The GAMP® Guide suggests that functional and design specifications should be established as a prerequisite for categories 4 and 5 because they provide more specificity and robustness testing.

6.13. What is the relationship between the quality management system and the validation of computerized systems?

The quality management system is an umbrella term covering all business processes. In this context, the validation activities and processes that serve the systems are no exception. There are three direct links of the validation study to the quality management system that must be taken into account to obtain the expected results:

• Compliance with established quality policies and processes
• Documentation of inclusion in the BPD system and documentation of its operation, maintenance, design, control, system definition and validation and the electronic records it manages
• Risk Management
• Maintenance of the validated state through the use of Change Control tools, handling of deviations or non-conformities, internal audits, CAPAs management, staff training, supplier evaluation, maintenance and calibration programs

Records are documents to be considered within the Quality Management System (QMS). Procedures related to the use of systems and their management (IT procedures) must comply with the GDP and be within the QMS. Validation protocols, reports and evidence must comply with the provisions of the QMS.

At all times, the quality policies established by the company must be adhered to and they must be consistent with expectations and conformity validation.

Validation studies and the management of their results must be based on the following quality processes:

• Non-conformities
• Corrective and preventive actions
• Customer complaints
• Risk management
• Internal audits
• Change control
• Qualification of suppliers
• Training and qualification of personnel

The minimum procedures for specific preparation of computerized system validation are divided as follows:

Procedures for IT system management

• Management of systems and new developments
• Management of physical and logical security
• Supplier management for computer systems
• Management of electronic signatures (if applicable)
• Maintenance of computer systems
• Backup, archiving and recovery of information
• Verification of electronic records
• Contingency plan in case of emergencies
• User management
• Virus management
• Configuration management
• Patch management and updates
• On and off infrastructure (if applicable)
• Help desk
• Spreadsheets for version control

Procedures for use and IT system management

• Installation of network equipment
• Escalation management and demand
• Change control (HW & SW)
• Security Management
• Preventive Maintenance
• Research problems
• Training
• On/off servers
• Performance measurement
• Capacity management
• Help desk
• User management
• Virus management
• Backup, archiving and recovery
• Configuration management
• Disaster recovery
• Commissioning and decommissioning

Procedures for use system

• Operational procedures that include not only the operation of the process, but also the system as part of the process

In addition, the procedures of the quality management system to maintain the validated status are mentioned above.

It is not necessarily important that these documents have these names, even several of them can be included in other procedures or unified into a single one or even those that do not apply to certain systems. In this regard, the decision to create or not create procedures should be based on the following assumptions:

• They will add value to the process
• They must be appropriate to the context and system control needs and processes
• They must be appropriate for the users who will use them

They should contribute to better control and reduction of risks.

One factor underscoring the importance of the relationship between quality management system and process validation of computerized systems is that there are validatable systems with high impact on the quality management system, some of which manage the QMS. Examples include:

• Document Management Systems (DMS)
• Quality control systems and Laboratory Information Management Systems (LIMS)
• Quality modules in the ERP
• Spreadsheets for process control and quality management

As for document management systems, these are some of the points to consider during validation.

International guidelines recommend:

• Keep documented information to support the operation of our activities
• Maintain documented information to ensure that the activities are carried out

Therefore, it is vital to implement a document management system to demonstrate that activities meet the previously established requirements.

DMS systems reflect the processes and associated documents that are part of the documentation system activities. The management of the organization's work methods computerized systems are critical because they manage the most important in the implementation of good practices element documentation. In them, documentation is integrated in an orderly manner to ensure proper understanding. Implementation of a documented system helps ensure consistent processes and helps make effective, well-informed decisions.

During the operation phase, changes to software, hardware, and processes must be monitored and managed as part of continuous improvement and maintenance of the validated state.

Key procedures for maintaining validated status include:

• Change control (hardware & software)
• Configuration management
• Backup, archiving and recovery of information
• User management
• Security management (physical & logical)
• Preventive maintenance
• Performance measurement
• Disaster recovery
• Help desk

7.1. Maintaining the validated status in outsourced activities

When activities related to the system are outsourced, it is important to ensure that the validated state is maintained through proper supplier management, service-level agreements, and regular audits. Outsourced providers must adhere to the same quality and compliance standards as internal teams.

The retirement phase involves removal, decommissioning, and data migration when a system becomes obsolete, loses supplier support, or is replaced by better alternatives.

Computer System Validation is a critical discipline for ensuring that GxP-regulated computerized systems are fit for intended use. By applying a risk-based, lifecycle approach guided by GAMP® 5 principles, organizations can ensure compliance, maintain data integrity, and protect patient safety.

Key takeaways from this guide:

• CSV ensures systems do what they're designed to do — consistently and reproducibly
• GAMP® 5 categories (1, 3, 4, 5) determine validation scope and strategy
• The V-model provides a structured framework for development and testing
• Data integrity (ALCOA principles) is fundamental to regulatory compliance
• Validation is a collaborative effort requiring clear roles and responsibilities
• Maintaining validated status is an ongoing process throughout the system lifecycle

For the full 100+ page guide with detailed illustrations and additional examples, download the free whitepaper.

Need expert support for your CSV project? Explore QbD Group's Software Validation services — from strategy to execution, GAMP® 5 compliant.