GxP Lifeline Feature Article

Benefits of a Risk-Based Approach

By David Ade

Life science companies can avoid software validation difficulties by taking a risk-based approach to evaluate potential risks and developing a risk management plan to deal with potential problems after they have been identified.

Of the 242 medical devices recalled by the U.S. Food and Drug Administration (FDA) between 1992 and 1998 for reasons related to software failures, “192 (79 percent) were attributable to changes made to the software after its initial implementation” (http://www.fda.gov/cdrh/comp/guidance/938.html). If software solutions are not deployed and validated properly the results can be product recalls, production downtime, business closure, or—worst case scenario—risk to patients’ health. Using a risk-based approach to validate software allows life science companies to save effort, time, and money, without affecting the quality and safety of the software. Avoiding software validation pitfalls begins with evaluating potential risks and developing a plan to deal with hazards once they have been identified.

Life science industry analysts, validation experts, software solution vendors, and the FDA are all calling for the industry-wide adoption of a risk-based approach to validation. To understand why, one must first examine how the risk-based approach is defined. The “21 CFR Part 11 Electronic Records, Electronic Signatures, Scope and Applications” industry guidance recommends that software validation be focused on “a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety, and record integrity.” Based on this “justified and documented risk assessment” companies can evaluate the best approach to validating the system and determine how much testing is necessary. According to the FDA’s General Principles of Software Validation guidance, 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.” In a 2002 FDA Subcommittee meeting presentation, Leon Lachman, Ph.D., elaborated on the subject, indicating that the FDA’s determination of adequate risk-based validation requires documentation that can provide “assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.”

The reasons for the push toward a risk-based approach to validation are practical:

  • A risk-based approach allows testing on areas of the system that pose the greatest risk to product quality and patient safety.

  • Reduction of overall validation costs and increased efficiency throughout the industry.

  • The end result of an industry-wide shift to risk-based validation, according to The Society for Life Science Professionals (ISPE) white paper “Risk-Based Approach to 21 CFR Part 11” would be the proliferation of “manufacturing innovation and technological advances, while safeguarding the product and the patient.”

If all the players in the life sciences industry stand to benefit from basing validation on risk assessment, why are so many companies resisting the shift to a risk-based approach? Some of the general challenges that may be affecting their resistance include:

  • There is no FDA-sanctioned model to emulate. Constructing a methodology for prioritizing risks is an ambiguous undertaking that requires some degree of improvisation since broad FDA instructions (“impact on product quality and patient safety”) can seem vague and open to interpretation.

  • Some companies take the wrong route to assessing risk by placing unnecessarily high prioritization on systems that should be considered low risk, wasting time and resources.

In his Journal of Validation Technology article “Risk-Based Validation of Commercial Off-the-Shelf Computer Systems” (May 2005, Vol. 11, No. 3) validation expert Ludwig Huber, Ph.D., states that the ultimate purpose of a risk-based position is to “identify and control critical functions that affect product quality and data integrity.” Companies that would benefit from a risk-based approach are often wary of Commercial Off-the-Shelf (COTS) systems because, while such systems may have been tested and validated with hundreds of previous customers, the lack of personal experience with a software solution is too daunting and risky in a strict regulatory environment. Huber’s article clarifies this common misconception: “The risk is not dependent mainly on the system,” he says, “but more on the records created, evaluated, transmitted, or archived by the system.”

Therefore, potential buyers of software solutions that are ready “out-of-the-box” can learn from other life science firms who have had successful validation experiences with COTS systems. Huber recommends that companies not already utilizing a risk-based outlook to validation should take the following steps:

  • Develop a risk management plan.

  • Develop a risk management project plan for each computer system validation project.

  • Identify risks, possible hazards and harms and define the risk category (low, medium, high, or a similar, company-specific categorization).

  • Determine validation tasks for each lifecycle phase.

  • Develop a risk management plan with a sound justification and thorough, consistent documentation of results.

Without an official FDA model to follow, formulating and actualizing a risk management plan with this suggested degree of detail is an overwhelmingly difficult undertaking without implementing an off-the-shelf software solution to streamline the process. If you do implement a risk-based approach utilizing a COTS validation system, take care to avoid IQ/OQ/PQ validation entanglements that hinder many life science companies. Most companies allocate the bulk of their validation efforts to Operational Qualification (OQ) when their products—and subsequently, profits—would be better served if the majority of time was devoted to Performance Qualification (PQ). A proven and effective COTS software validation solution could reverse this OQ/PQ conundrum. A good out-of-the-box solution should also perform affordable validation quality testing in a “transfer” setting—within its own environment prior to deployment—to prove the system can live up to validation expectations.

In the end, companies should keep their efforts in line with FDA and industry guidances which suggest that the level of validation to be performed should be based on the risk of the records generated by the system.  And, if this method is followed accordingly, the cost of overall validation can sometimes be reduced, allowing companies to better take advantage of the benefits of an electronic system sooner due to less validation work and faster system implementation.

About the Author
David Ade, a product manager at MasterControl Inc., specializes in FDA computer validation and other software-related requirements.

Learn more about a risk-based approach to software validation and COTS systems:

White Paper:

21 CFR Part 11 System Validation - Risk Management Plan

White Paper:

21 CFR Part 11 Risk of Non-compliance

Click here to view all available resources.

If you are a current MasterControl customer click here to download documents directly through our Customer Center.


FDA Link

  • FDA Guidance: General Principles of Software Validation; Final Guidance for Industry and FDA Staff, issued January 11, 2002.
    Full Article

  • FDA Guidance: Electronic Records; Electronic Signatures ? Scope and Application, issued August 2003.
    Full Article

  • Validation presentation: ?Process and Method Validation,? Leon Lachman, Ph.D., Lachman Consultant Services, FDA Subcommittee Meeting, February 2002.
    Full Article

Additional Articles

  • Combination Products: Navigating Two FDA Quality Systems ISPE white paper, ?Risk-Based Approach to 21 CFR Part 11?
    Full Article

  • ?Risk Based Validation of Commercial Off-the-Shelf Computer Systems,? Dr. Ludwig Huber, Compliance and Validation Expert. Compliance News, July/August 2006.
    Full Article