Decrease Computer System Validation Time and Costs by Implementing a Risk-based Approach
For companies doing business in regulated environments, thebenefits of implementing software systems are abundant. Improved productsafety, higher quality, enhanced efficiency, and increased probability ofmaintaining regulatory compliance are just a sample of the numerous benefits computerizedsystems can provide. Why, then, do so many companies resist implementingsoftware systems?
The primary culprit is usually cost. Most organizationsunderstand that the cost of purchasing or creating a software system is onlythe beginning of the expenditure. What frightens off many companies is notnecessarily the initial price tag but the additional, inevitable costs that areassociated with validating the software system. If not carried out correctly,validation can sometimes cost as much or more than the price of the softwareitself. The time required to validate software systems and validation’s potentialdrain on resources are also often viewed as disincentives. Not to mention thatthere isn’t a “one size fits all” method of validating the multitude ofsoftware systems used by companies whose products are subject to regulatoryrequirements. Nor are there predicate rule requirements that pertain specificallyto the interpretation of 21 CFR Part 11.
Despite these frequently perceived deterrents there is an increasing shift toward the use of software systems in regulatory environments,primarily for reasons of practicality and increased efficiency. The FDA has facilitated this shift by promoting a risk-based approach to validation.
This article is related to the Product Data Sheet:
MasterControl Validation Services.
To get the full details, please download your free Product Data Sheet.
FDA’s ExpectationsRegarding Risk-based Validation
In the Guideline on General Principlesof Process Validation the FDA defines validation as “Establishingdocumented evidence which provides a high degree of assurance that a specificprocess will consistently produce a product meeting its pre-determinedspecifications and quality attributes.” In short, companies themselves mayevaluate their systems and make their own determinations about how muchvalidation testing is necessary. Taking a risk-based approach to validation asan alternative to “traditional” validation processes is advocated by the FDA—aslong as it is conducted thoroughly and is commensurate with the amount of riskinherent in a particular software system. The proportionate level of validationto be performed should be based on the amount of risk that can be attributed tothe records generated by the system.
There are three practical motivations behind the drivetoward a risk-based approach to validation:
Validation and RiskAssessment
It is crucial to note that risk is not dependent inprinciple on the software system itself. Rather, risk is dependent on thoseprocesses the system facilitates with the records it is managing. These specificprocesses that must be assessed include:
The FDA employs risk assessment practices itself andrecommends that industry should follow suit. The FDA guidance for industry Part 11, ElectronicRecords; Electronic Signatures – Scope and Application recommends thatsoftware validation should be focused on “a justified and documented riskassessment and a determination of the potential of the system to affect productquality and safety, and record integrity.” Logic dictates that suchdocumentation should include a formal Risk Management Plan that details therisk assessment and risk mitigation activities during not only the implementationof the system but during Installation Qualification (IQ), OperationalQualification (OQ), and Performance Qualification (PQ) testing phases.
Risk assessment can be useful in determining system elementsthat are fundamental to meeting the terms outlined by the FDA in the guidelinespreviously discussed, such as:
The next step in the risk assessment process then becomesclassifying and prioritizing the identified risks using any number of riskfactors. Factors often used to assess risk include:
These (and any other relevant) risk classifications andpriorities can then be used to help determine the need for and/or extent ofvalidation and audit trail implementation as well as for developing a strategyfor record retention.
This entire risk assessment process can be simplified andstreamlined by a best-of-breed, “validation ready” software system.
Realizing SavingsUsing Vendor Documentation
Implementing a proven andeffective commercial off-the-shelf (COTS) system can save the total amount oftime and money a company is required to invest in their validation efforts. Themore reliant a company can be on a software vendor, the less company resourceshave to be devoted to validation work. It is imperative to note, though, that companiesintending to utilize vendor documentation for validation purposes must first auditthe vendor’s test records prior to accepting any data. Without a thorough understandingof the vendor’s methodology and test records the company will not be able todefend the acceptance of the vendor’s validation data. If the vendor’s data issuccessfully audited and can justifiably be accepted, however, it can be ofgreat benefit in reducing the cost and time required to validate the softwaresystem.
A common attribute of successfuland rapid risk-based validation is that the organization is able to focus more energyon PQ testing and less on IQ and OQ testing. By doing so—using only accurate,audited documentation from a vendor that has previous validation success, ofcourse—the end result should be less validation work, faster system deploymentand a reduction in overall validation costs.
 TheSociety for Life Science Professionals (ISPE) white paper “Risk-BasedApproach to 21 CFR Part 11”
About the Author
David Ade, a product manager at MasterControl Inc., specializes in information systems and computer validation in the pharmaceutical and software industries..
Read more about a risk-based approach to software validation:
General Principles of Software Validation; Final Guidance for Industry and FDA Staff
Guidelines on General Principles of Process Validation
Part 11, Electronic Records; Electronic Signatures - Scope and Application