For companies doing business in regulated environments, the benefits of implementing software systems are abundant. Improved product safety, higher quality, enhanced efficiency, and increased probability of maintaining regulatory compliance are just a sample of the numerous benefits computerized systems can provide. Why, then, do so many companies resist implementing software systems?

The primary culprit is usually cost. Most organizations understand that the cost of purchasing or creating a software system is only the beginning of the expenditure. What frightens off many companies is not necessarily the initial price tag but the additional, inevitable costs that are associated with validating the software system. If not carried out correctly, validation can sometimes cost as much or more than the price of the software itself.

The time required to validate software systems and validation’s potential drain on resources are also often viewed as disincentives. Not to mention that there isn’t a “one size fits all” method of validating the multitude of software systems used by companies whose products are subject to regulatory requirements. Nor are there predicate rule requirements that pertain specifically to 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.

FDA’s Expectations Regarding Risk-based Validation

In the Guideline on General Principles of Process Validation the FDA defines validation as “Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.” In short, companies themselves may evaluate their systems and make their own determinations about how much validation testing is necessary. Taking a risk-based approach to validation as an alternative to “traditional” validation processes is advocated by the FDA—as long as it is conducted thoroughly and is commensurate with the amount of risk inherent in a particular software system. The proportionate level of validation to be performed should be based on the amount of risk that can be attributed to the records generated by the system.

Justification

There are three practical motivations behind the drive toward a risk-based approach to validation:

• By taking a risk-based approach companies can more rigorously test the areas of the software system that pose the greatest risk to product quality and patient safety.
• Overall validation costs are reduced and efficiency is increased not just within the organization adopting a risk-based approach but throughout the entire industry.
• The outcome of an industry-wide shift toward risk-based validation, according to The Society for Life Science Professionals (ISPE), would be the propagation of innovation in manufacturing and new technological advances without having to sacrifice product quality or patient safety.

Validation and Risk Assessment

It is crucial to note that risk is not dependent in principle on the software system itself. Rather, risk is dependent on those processes the system facilitates with the records it is managing.
These specific processes that must be assessed include:

• Creating records
• Record assessment
• Record transmission
• Archiving of records

The FDA employs risk assessment practices itself and recommends that industry should follow suit. The FDA guidance for industry Part 11, Electronic Records; Electronic Signatures – Scope and Application recommends that software validation should 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.”

Logic dictates that such documentation should include a formal Risk Management Plan that details the risk assessment and risk mitigation activities during not only the implementation of the system but during Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) testing phases.

Risk assessment can be useful in determining system elements that are fundamental to meeting the terms outlined by the FDA in the guidelines previously discussed, such as:

• Critical risk factors
• The need for validation and the extent of testing that will be required
• The need to implement audit trails (or equivalent controls) in the system and structure the audit will ultimately take
• A strategy for maintaining records’ integrity and reliability throughout their retention period

The next step in the risk assessment process then becomes classifying and prioritizing the identified risks using any number of risk factors. Factors often used to assess risk include:

• Impact
• Probability/Likelihood
• Detection

These (and any other relevant) risk classifications and priorities can then be used to help determine the need for and/or extent of validation and audit trail implementation as well as for developing a strategy for record retention.

This entire risk assessment process can be simplified and streamlined by a best-of-breed, “validation ready” software system.

Realizing Savings Using Vendor Documentation

Implementing a proven and effective commercial off-the-shelf (COTS) system can save the total amount of time and money a company is required to invest in their validation efforts. The more reliant a company can be on a software vendor, the less company resources have to be devoted to validation work.

It is imperative to note, though, that companies intending to utilize vendor documentation for validation purposes must first audit the vendor’s test records prior to accepting any data. Without a thorough understanding of the vendor’s methodology and test records the company will not be able to defend the acceptance of the vendor’s validation data. If the vendor’s data is successfully audited and can justifiably be accepted, however, it can be of great benefit in reducing the cost and time required to validate the software system.

A common attribute of successful and rapid risk-based validation is that the organization is able to focus more energy on 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, of course—the end result should be less validation work, faster system deployment and a reduction in overall validation costs.