How Much Value Is There in a Software Operational Qualification?

Feb 01, 2013

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.