Risk-Based Validation: What is it, and why do we do it?
Recently, much has been made of the FDA’s recommendation that pharmaceutical companies move toward a risk-based validation strategy. It has been referenced in the guidance General Principles for Software Validation (January 2002) as well as the final guidance regarding 21 CFR Part 11 (Part 11, Electronic Records; Electronic Signatures – Scope and Application, August 2003) as an FDA recommendation for validation of computerized systems. “Risk-based validation” is now a commonly heard phrase in the pharmaceutical industry, but its precise definition is unclear. The common impression is that it is a method that will reduce the overall time and effort expended in validation, and therefore will positively impact productivity and profitability. Though this is certainly true of a well-planned and well-executed risk-based approach, if the knowledge of how to implement such an approach is lacking, chances are the real benefits will not be seen.
In an effort to understand the concept of risk-based validation, individuals must begin by learning how to assess risk and make decisions based on that assessment. Frequently, a common scale for measuring risk is sought, and in the case of some efforts such as the GAMP risk assessment methodology, the establishment of a common scale, or at least a standard way to evaluate risk, is attempted. The GAMP method advocates categorizing software and performing validation based on the extent of validation recommended for the category in which the software is placed. Another method for assessing the risks associated with a given software package would be to assess each requirement (functional, design, user, etc.) for its ultimate impact on patient health, and deciding to concentrate validation on those requirements for which risk is highest. This requires the ability to approach the requirements at a macro level, and may require the initial involvement of more individuals from different disciplines within an organization, but that may be an acceptable investment for a software package that will be installed, and therefore validated, once, and only maintained thereafter for several years.
Another thing to remember about risk-based validation is that, as always, “if it’s not documented, it didn’t happen.” It is not enough to simply assess the risk and make the decisions based on that risk; the process of risk assessment must be documented, as well. The approach taken, the findings uncovered, the decisions made, and the justification for those decisions must be documented and included with the validation documentation for the system.
If steps are taken to perform a risk assessment for a piece of software to be implemented, it is indeed possible in some cases to reduce the overall amount of time spent on validation: taking a tailored approach rather than a “one-size-fits-all” approach can only benefit schedules as well as patient health. However, the approach must be planned and documented thoroughly.
In an effort to understand the concept of risk-based validation, individuals must begin by learning how to assess risk and make decisions based on that assessment. Frequently, a common scale for measuring risk is sought, and in the case of some efforts such as the GAMP risk assessment methodology, the establishment of a common scale, or at least a standard way to evaluate risk, is attempted. The GAMP method advocates categorizing software and performing validation based on the extent of validation recommended for the category in which the software is placed. Another method for assessing the risks associated with a given software package would be to assess each requirement (functional, design, user, etc.) for its ultimate impact on patient health, and deciding to concentrate validation on those requirements for which risk is highest. This requires the ability to approach the requirements at a macro level, and may require the initial involvement of more individuals from different disciplines within an organization, but that may be an acceptable investment for a software package that will be installed, and therefore validated, once, and only maintained thereafter for several years.
Another thing to remember about risk-based validation is that, as always, “if it’s not documented, it didn’t happen.” It is not enough to simply assess the risk and make the decisions based on that risk; the process of risk assessment must be documented, as well. The approach taken, the findings uncovered, the decisions made, and the justification for those decisions must be documented and included with the validation documentation for the system.
If steps are taken to perform a risk assessment for a piece of software to be implemented, it is indeed possible in some cases to reduce the overall amount of time spent on validation: taking a tailored approach rather than a “one-size-fits-all” approach can only benefit schedules as well as patient health. However, the approach must be planned and documented thoroughly.
posted by m at 10:08 AM
<< Home