Highly regulated life science labs that operate under quality systems like Good Manufacturing Practice (GMP), Good Laboratory Practice (GLP), or Good Clinical Practice (GCP) must document that the lab instruments and software will meet the needs of the lab and deliver the expected outputs. These processes are known as instrument qualification and computer system validation (CSV). An easy way to remember the difference is supplied by Dan Zuccarello, founder of the RBF Consulting Group, LLC: “Instruments are qualified, software is validated.”
Instrument qualification
An effective approach to instrument qualification is provided in the US Pharmacopeia (USP) General Chapter <1058>, “Analytical Instrument Qualification.” Instrument qualification enables the lab to demonstrate that it acquired the right equipment to solve a problem and deliver on a need for a key stakeholder. The scope of the qualification is confined to a specific piece of lab equipment. Following the USP approach a lab will conduct four different stages of instrument qualification:
Design qualification (DQ)
The design qualification defines the need for the instrument by the lab. It will clearly describe the problem that needs to be solved for both technical and regulatory purposes. The lab will generate a set of user requirement specifications (URS) that clearly document how a potential solution will solve the problems. The DQ enables the lab to clearly define the problem, the need, and how a specific solution will solve the problem and meet the need.
Installation qualification (IQ)
Once an instrument is selected, the installation qualification verifies that it is properly installed and operating according to manufacturer specifications. The IQ also documents that the lab environment is appropriate for the instrument to operate properly and deliver the needed data.
Operational qualification (OQ)
The operational qualification confirms that the installed instrument operates as expected and intended under the existing operating conditions. From the URS, the lab can develop test scripts that will functionally test the new instrument against well-established standards. The outcomes of these tests will document that the instrument is delivering the expected data and outcomes.
Performance qualification (PQ)
The performance qualification demonstrates that the new instrument consistently performs this needed activity in the actual lab environment. Labs often document the PQ by running through a complete method, procedure, or protocol that is commonly performed in the lab. The PQ documents that the new equipment performs the needed tests as expected and is consistent with the needs documented in the DQ.
Software validation
The US Food and Drug Administration (FDA) provides an effective approach to software validation in its guidance document “General Principles of Software Validation” dated January 2002. This document provides guidance on how the lab can be compliant to FDA 21 CFR Part 11. The purpose of software validation is to confirm that the software consistently produces results meeting predetermined acceptance criteria. The key components of the validation ensure that the data are reliable, accurate, and secure. Important things for the lab to consider during the validation process are data integrity, effective audit trails, how they control user access, ensuring unique electronic signatures, and appropriate system maintenance.
The key driver of software validation is regulatory compliance. However, the lab also gains the benefits of ensuring data integrity, improving lab quality, and of mitigating risks associated with potential software failures
Since most modern lab instruments contain software, or are run by computers with specific software, the computer validation usually follows the instrument qualification. Once the qualification determines that the hardware is ready, then the software is examined. Some common steps for software validation are:
Scope and purpose
Documenting the specific functions that the software will bring to the lab is one of the first steps in validation. Link the scope of validation to the features that the lab will consistently need and use.
A best practice of software validation is using a risk-based approach. Focus on the critical parts of the programs and processes. The International Society of Pharmaceutical Engineering provides and effective approach to risk-based software validation in GAMP 5.
Regulatory compliance assurance
After establishing the purpose of the software, it is important to ensure compliance with the regulatory requirements under which your lab operates. This begins with a clear understanding of the regulations pertaining to your lab. If your lab is regulated by the FDA, ensure that electronic records, dynamic data, and electronic signatures are part of the validation project.
System development life cycle
The system development life cycle will establish the required specifications of the software to meet the lab’s needs and be compliant with the regulations. The lab can document that the new software is consistent with those requirements. It guides the lab through testing the software to ensure that it meets those requirements and functions properly during use.
Traceability matrix
The traceability matrix uses lab developed test scripts to document that the software complies through the actions required by the lab. Developing a complete set of test scripts can be a tedious and difficult task. It is important to remove any duplication between different test scripts to reduce the time required to validate the software.
Validation report
The validation report is the final documentation of all the effort invested by the lab in the software validation. It summarizes all the actions, findings, and outcomes of the project. This report will be the primary vehicle to demonstrate to regulatory auditors that specific software is compliant with their requirements.
Equipment qualification and software validation are big projects for labs. It can take longer to complete the qualification and validation steps than it does to identify the need, advocate for investment, win approval, and obtain the new equipment or software. Developing templates and building internal expertise can greatly improve the efficiency of these processes. It is also important to consider external partners who can do some or all these processes for the lab as contract partners.