Software operational qualification (OQ) is considered a mandatory item in a computerized system validation project for a regulated
laboratory. But we should ask two questions: Is OQ really essential to a validation project for this type of software such
as a chromatography data system (CDS)? How much value does a software OQ for commercially available software actually provide
to a validation project?
Validation of computerized systems requires that a regulated organization working under good laboratory practice (GLP) or
good manufacturing practice (GMP) requirements implement or develop a system that follows a predefined life cycle and generates
documented evidence of the work performed. The extent of work undertaken on each system depends on the nature of the software
used to automate the process and the impact that the records generated by it have (1–3). In essence, application software
can be classified into one of three software categories using the approach described in the ISPE's Good Automated Manufacturing Practice (GAMP) Guidelines, version 5 ("GAMP 5") (4):
- commercially available nonconfigured product (category 3)
- commercially available configured product (category 4)
- custom software and modules (category 5).
A justified and documented risk assessment is the key to ensuring that the validation work can be defended in an inspection
or audit. Therefore, the work that a laboratory needs to perform will increase with the increasing complexity of the software
(5). This discussion focuses on commercially available software, or GAMP software categories 3 and 4 (5,6). The arguments
presented here are not intended to be applied for custom software applications or modules (such as macros or custom code addons
to commercial software), which require a different approach. Nor will I consider the role of a supplier audit in leveraging
the testing carried out during product development and release into a laboratory's validation efforts.
Verification Stages of a Life Cycle
Terminology is all important to avoid misunderstandings. We are looking at the verification stage of a life cycle in which
the purchased system and its components are installed and checked out by the supplier (installation qualification [IQ] and
operational qualification [OQ]) and then user acceptance testing is carried out against the requirements in the user requirement
specification (URS) to demonstrate that the system is fit for intended use (performance qualification [PQ]).
Figure 1: Verification phases of a system life cycle with an indication of the responsibility for each phase.
|
In Figure 1, we see three phases of verification, together with the allocation of responsibility for each phase. Each phase
is described as follows:
-
Installation and integration (IQ)
— In essence, this asks the following questions: Do you have all of the items that you ordered? Have they been installed correctly?
Have the components been connected together correctly?
-
Supplier commissioning (OQ) — Does the system work as the supplier expects? Typically, this is performed on a clean installation of the software, rather
than configuring specifically for the OQ.
Not covered in Figure 1 is the user task of configuring the application software. For a category 3 application this may be
limited to the setup of the user roles, the associated access privileges and allocation of these to individual users. Additional
steps for configurable applications include turning functions on or off, setting calculations to be used for specific methods
and selecting report templates to be generated. This turns the installed software into the as-configured application for your
laboratory, which the users are responsible for.
• User acceptance testing (PQ) — Does the system work as the user expects against the requirements in the URS? This will be performed on the configured application
if you are using a category 4 application.
Following the successful completion of the user acceptance tests and writing of the validation summary report, the system
is released for operational use. Please note that the above descriptions of IQ, OQ and PQ apply only to software and are not
the same as outlined in the United States Pharmacopeia (USP) Chapter <1058> on analytical instrument qualification (AIQ) (7).
In this column, I want to focus on the supplier commissioning or OQ and ask the first of the two questions I raised at the
start.
RSS
Bookstore
