Pharmas favour risk-based validation
18 April 2008
As a long-standing supplier of GLP system validation services, LabLogic Systems has observed a trend in recent years towards risk-based validation for commercial off-the-shelf (COTS) systems rather than the traditional IQ, OQ and PQ validation phases.
The company says that many pharmaceutical companies are using a risk assessment of the potential of their systems to affect product quality and safety and record integrity not just because it can help to reduce validation costs, but in response to FDA recommendations.
In particular, the FDA's Guide Principles for software validation(1) say that 'The selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use'.
Risk based validation requires two steps; defining the user requirements for the system and specifying the risk (e.g. high, medium, low) for each, and then specifying the validation tasks for each category.
The criteria to be applied in judging risk are not specified by the FDA, but the industry appears to have arrived by various routes at a consensus under which the severity, probability and detectability of a problem in a data record are recognised as fundamental.
An example of high risk is the computerized analytical systems used in quality control laboratories, whose malfunction could release into the market drugs with impurities exceeding specified limits, whereas a word processing program used to write a validation report is clearly low risk.
Companies must identify these categories of risk for all their systems and - equally importantly - be prepared to justify their decisions. Even in the case of a system judged to be low-risk, validation must be carried out at the appropriate level and fully documented.
Once the system risks have been defined, the validation tasks can be assigned for each step. "In our experience," says LabLogic's systems director Dr Huw Loaring, "that often means that customers ask for a PQ type test to be performed to cover medium/low risk functionality - for example, for all data from a study to be entered into Debra and the results compared."
"But for higher risk items, such as testing the editing of data or the security of the software, they want elements of our OQ Functional tests to be included."
(1) United States Food and Drug Administration (FDA), General Principal of Software Validation: Final Guidance for Industry and FDA Staff, 2002