David J. Bergeson is a senior compliance consultant at KMI, a division of Parexel International LLC.

David J. Bergeson

The objective of this article is to attempt to look at the future state of computer validation principles based on current events and trends in regulations, business practices and technology. This crystal ball approach will prepare the industry for the future by establishing a current-state best-practice foundation of computer validation principles as well as improving computer validation practices.

Part I of this article was published in the March 2003 issue of 21 CFR Part 11: Compliance and Beyond. In this issue, Part II discusses the potential advances and changes that must be made for computer validation to remain innovative and relevant to the industry.	

Improving the future of computer validation infrastructure

With the increased need to conduct computer validation, there comes a need to improve the efficiency of how computer validation is performed. To have better efficiency in computer validation practices, a better infrastructure for computer validation practices is required. In addition to an existing computer validation programme that may already have been established (for example, the availability of an inventory list of the systems, a master plan on the validation status of the systems or a prioritization of how the systems are going to be validated and procedures for conducting computer validation), the following are some conceptual approaches that can be considered for building the future infrastructure (please note that these concepts are simply food for thought).				

Use of a commercial off-the-shelf (COTS) screening requirements document

The current computer validation practices for preparing a full and thorough requirements document before system purchase may hamper the effort of purchasing a system in an expedient manner. In addition, the current operational lifestyle for new systems acquisition is mainly related to the purchase of COTS software, which typically means there is an existing client base and, perhaps, some familiarity with the product. The concept of screening requirements is the use of a high-level requirements document to select a vendor, which enables a purchase order to be issued and then allows the system acquisition process to begin. Once the vendor is selected, the strategy is to work with the vendor in acquiring or developing the specifications document. The potential for developing and using a screening requirements process can only be considered for purchasing a system that meets all of the following criteria:		

a COTS system (one that is not a customized, contracted or an in-house developed system)

not a new system (that is, it is not version 1.0; there is an established, regulated client base)

a system for which the principle of functionality and operation is already known (for example, a high performance liquid chromatography system)

a similar system is already available in-house

a system for which the requirement specifications can be furnished by or co-developed with the vendor.

As with other types of software systems, a risk factor is involved in the use of this screening requirements concept. Those risks may vary from system to system, from project to project and from company to company. From a computer validation perspective, the main risk factor to be considered when using this concept is the capability of it meeting the basic objective of computer validation: providing documented evidence that provides a high degree of assurance that the system reliably and consistently does what it is designed to do. When this concept is applied, and the above criteria are met, the basic objective of computer validation can still be met. Mitigating the risk arising from this approach can be done by ensuring that the system is qualified to meet business needs (for example, through testing). Hence, incorporating and meeting business needs should be included in validating the system.	

Process for evaluating the need to do a vendor audit

This section is not intended to introduce a concept regarding how a vendor audit should be conducted, but rather to introduce the concept of determining whether there is a need to conduct a vendor audit (or the type and level of the audit). Having such a process will define a consistent approach for evaluating vendors and expedite the decision making process.				

The following are some of the questions that can be considered for this process:	

is the system COTS or custom developed (contracted out or developed in-house)?

does the system's acquisition involve the purchase of one or more than one system?

will the system be implemented at one location or multiple locations?

will the system be deployed as a standalone system or interfaced to other systems?

is the system new and recently marketed or has it already been in the market for an extended period of time?

has the purchaser had experience with this system?

has the purchaser had experience with the vendor?

will the vendor be used just for this one particular project or for future projects?

has the vendor been previously audited by your company or does the vendor have an audit on file with the Audit Repository Center?

can the vendor make high quality development validation available?

does the vendor have an established market history (is it financially stable)?

does the vendor have quality certifications?

does the system perform complex GxP functions (for example, you may not want to do an audit of a vendor for simple electronic balances)?

Other factors can also be considered and a weighting factor can be applied to each of those factors. The totalled result can be used to determine whether a vendor audit should be conducted. Having this type of process in place will expedite the process of computer validation by providing guidance as to which vendors must be audited.	

Process for accepting third party certification

In addition to considering the need for vendor audits to inspect the quality of the product, alternatives - such as third party certifications - may be evaluated. The introduction by the US Food and Drug Administration (FDA) of a systems approach to inspection may facilitate the use of third party certification to evaluate the quality of the software without performing a vendor audit. Accredited certification bodies certify the quality of a product by conducting audits performed by independent external quality assurance agencies known as third party certification bodies.39 The certification bodies use technically qualified auditors who have been specially trained and subjected to professional selection. Having this type of process in place would expedite computer validation by potentially avoiding long discussions regarding the quality of the product. Instead, the audit can concentrate on the capability of the product to meet user needs.				

It should be noted that FDA does not currently recognize any third party certifications, including ISO 9001 certification. The industry must work with FDA to provide it with a level of trust in such a scheme before it can be relied on to mitigate the validation workload. In the meantime, the PDA effort (Technical Report 32) of vendor audits and the establishment of a vendor audit package repository centre39 should be considered as a means of satisfying the supplier audit requirement.	

Availability of a corporate data dictionary

To increase the efficiency of the process for making a decision and for information availability, the need for systems integration (for example, between chromatographic systems and LIMS or between LIMS and MRP) will increase and become more prominent in the future.		

To anticipate this need, one has to consider the development of a corporate data dictionary standard (for example, establishing standard definitions for terms such as sample, item code and unit of measurement, and creating a naming convention for products or data elements that will be shared between the computer systems). Building the data dictionary can be started whenever a new system is deployed or from the existing systems through the collection of data dictionary items from those systems. The collected data dictionary items from the various systems can then be compiled and cleaned (that is, eliminating redundancies and selecting a primary data item preference) to provide a controlled version of the data dictionary. When another system is being considered for deployment or acquisition, the data dictionary can be used to assess whether the data elements already exist in the dictionary or a new element must be introduced to the library. This data dictionary can also be used to support requirements development and will be an aid to system or vendor selection. For example, the data dictionary can help determine the complexity of integrating or interfacing new and existing systems.	

Simplifying the computer validation approach

Currently, almost all instruments or equipment being purchased contain a microprocessor, even those as simple as a pH meter. The level of validation (or qualification) of a simple microprocessor-based system does not always require the same level of validation effort that a more complex system requires. Hence, a simple conceptual process for determining the level of validation (or qualification) effort is needed. This concept is based on the premise that the level of validation (or qualification) can be categorized as needing either calibration, qualification or validation. For example, laboratory instruments or equipment that meet all of the following criteria can be categorized as needing calibration only:				

equipment or instruments in a COTS system

instruments or equipment not attached to an external computer or PC

if software is embedded in the equipment or instrument and only the vendor can load or change the software

no data are retained or stored by the equipment or instrument other than the current data analysis measurement

no data can be stored and retrieved, changed and stored again

the equipment or instrument is of the standalone type and not interfaced or integrated to other systems (if it is interfaced or integrated to other systems, then the total integrated or interfaced system must be considered when determining the level of validation or qualification).

After calibration, qualification must also be performed if the following factors are required to operate or use the equipment or instrument:	

calibration must be run whenever a sample analysis is performed (calibration is not the periodic type of calibration or performed on a preventive maintenance schedule)

final output (or result) of the equipment or instrument requires data processing or calculation based on the input of another sample or other data parameters obtained during the analysis of that additional sample

the equipment, instrument controls, monitors switches or other functions that are needed for that equipment to operate.

For an instrument or equipment that does not fall into these categories (that is, calibration or calibration 1 qualification), then validation is required. The level of validation can then be divided, based on whether the system is a custom-developed or a COTS system. For the custom system, a vendor audit, design specifications, programming standards and a source code walk-through and review may have to be considered and included as part of the validation activities. For COTS packages, much of this work will have already been done by the vendor (and verified through an audit). The criteria described above offer a conceptual depiction of the types of issues that must be considered when attempting to determine an appropriate level for validation activities.	

Validation data and test sets retention for regression data analysis

Articles

Part I of this article was published in the March 2003 issue of 21 CFR Part 11: Compliance and Beyond. In this issue, Part II discusses the potential advances and changes that must be made for computer validation to remain innovative and relevant to the industry.