Checklist for Computer Software Validation

Quality management of computer systems (hardware and software) is a central part of the overall quality management system in the pharmaceutical industry. In addition, quality management of electronic signatures and electronic records (1) (i.e., data generated by computer systems) is also part of the overall quality management system. Computer systems must comply with cGMP requirements, when used in these regulated environments. As continuous technology advancements, cloud computing, virtualized process control systems and manufacturing networks, including security, converge into a technology-driven, ever-adapting industry, so does the potential risk of non-compliance with both internal instructions as well as regulatory governance.

Users responsible for computer systems in pharmaceutical environments have raised legitimate questions con-cerning perspectives, validation strategy, scope, and methods when validating these systems. Validation of computer systems is a task often regarded as abstract and rather complex. Because of this attitude, users may rely too heavily upon vendor-supplied information and validation data to support their system validation. Relying on vendor-supplied data could compromise the intended use of the software, and therefore, compromise the validation. Guidelines, recommendations, hands-on frameworks and templates, including the extent of validation and the type of documentation required to support validation, are unclear (2-8). Furthermore, it is difficult to delineate vendor and user responsibilities, when validating vendor-supplied computer systems, even those systems regarded as mature and rather relatively simple systems (e.g., MS Excel, certain enterprise resource planning software). In contrast, several risk-averse pharmaceutical companies choose to validate, in-depth, vendor-supplied pre-validated “standard” software.

" target="_blank">
SPOTLIGHT EVENT

IVT’s 6th Annual Validation Week EU

RELATED ARTICLES

More in GMPs/Validation

Intended use
Intended use is defined as, “…facilitate operations for its intended use and for its cleaning and maintenance…” (1). This term has shown to be a good and pragmatic guideline. Users of computer systems can use the same term for computer systems. This rather simple notion proves useful as it simplifies an initial complex and, for some users, volatile concept.

From an internal-external perspective, verification practices (e.g., validation strategy, proper risk assessment, establishment of design, user requirements, and subsequent verification of requirements) must be processed and reported internally to verify the intended use of the software. The software’s intended use must be implemented, and personnel training in everyday operations must be conducted. The company must ensure that user requirements, specifications, and instructions match the intended use. From an external perspective respectively, the proper level of regulatory compliance of the intended use and the continuous quality control of the computer system has to be ensured and maintained. Figure 1 illustrates the typical lifecycle of computer systems, with intended use as a pivot point. This strict consensus is vital to avoid non-compliance with the intended use going from software requirement and designed functionality to operation.

Validation strategy
The validation strategy, and thus the extent of the validation activities, depends ultimately on the maturity and complexity of the computer software component(s) implied in ISPE GAMP5 and partly FDA 21 CFR 211.68(b) (6, 1). Computer software, as part of the computer system, dictates the hardware on which to be executed. The software categorization typology in GAMP5 ranges from infrastructure “used-by-millions” software  (category 1) such as antivirus software, operating systems (e.g., Windows, Linux, Unix, etc.), and databases (e.g., MS SQL, Oracle), to non-configured software with a large user base (category 3) such as firmware and MS Office applications, to customized software (category 5) (i.e., software characterized as being one of a kind such as most process controllers, scripts, macros, and data interfaces). Figure 2 illustrates software category and validation/verification activities depicted using the traditional validation-model.

Validation checklist
The following is a checklist of step-by-step recommendations for performing computer system validation:

Validation strategy and verification activities depend on the software category (maturity as implied in user base, and complexity). Use the typology and (almost industry standard) as outlined in ISPE GAMP5 (6).Recruit and involve users from identified functional areas (e.g., IT, quality assurance, vendor/supplier, and manufacturing) as early as possible. This early involvement makes specification and subsequent verification of ‘intended use’ easier. EU, Eudralex Volume 4. Annex 11 specifies the scope and extent of the functional-operational qualification to be done by the process owner, system owner, quality assurance (QA) and IT, respectively (2). From an operational perspective, it is recommended that the user group include system users. These users know how to establish test plans, test schemes, and test scenarios, not least in the subsequent performance qualification.Bridge project and operation by using an audit trail between the original requirement, its functional specification, the verification, and the standard operating procedure (SOP). A reverse audit trail, for example, could be used: Read the SOP, operate the designed computer system, and check the user requirements. Is the ‘intended use’ still valid?

Summary
From a strategic point of view, validating computer systems is an ever-increasing activity in the pharmaceutical industry as technology continuously automates former manual and paper-based processes. As technology increases, so does risk for non-intended use and ultimately non-compliance. Regulatory focus is primarily on raw data, data integrity, and SOPs (i.e., procedures not compromising the inteded use and, ultimately, the raw data). The pharmaceutical company is obliged to identify all raw data associated with GMP decisions (e.g., batch release) and determine which format (paper or electronic) to maintain data in. The integrity of the electronic record must be assured if raw data are to be maintained in electronic format. FDA issued warning letters in 2012 due to lack of documentation of intended use. Fortunately, top management, quality executives, and engineers are becoming more aware of potential regulatory pitfalls and breaches as the industry becomes familiar with computer systems and generated data.

References
1. FDA, 21 CFR 11, Electronic Records; Electronic Signatures
2. European Commission, EudraLex, Volume 4, Good Manufacturing Practices, Annex 11 Computerized Systems (January 2011).
3. European Commission, EudraLex, Volume 4, Good Manufacturing Practices, Part II--Basic Requirements for Active Substances used as Starting Materials (July 2010).
4. FDA, CFR 21 Part 210 Manufacturing, Processing, Packaging, or Holding of Drugs
5. FDA, CFR 21 Part 211, Finished Pharmaceuticals
6. ISPE, GAMP5 (Good Automated Manufacturing Practice, ISPE term)
7. ICH, Q7 Good Manufacturing Practice Guide For Active Pharmaceutical Ingredients (November 2000).
8. OECD.org.  

About the AuthorHenrik Johanning is CEO and senior partner, Genau & More; John Lee is executive director, PharmaNet Inc., former FDA Investigator; Christian Hemming is QA Manager, QAtor A/S; Lise Christensen is QA Director, CMC Biologics A/S.