Development Assurance process software validation

The FDA will consider the lack of computer validation as a significant inspection finding and log it as a 483 noncompliance citation. The MHRA may take a more lenient view depending on the criticality of the system on GxP operations. The lack of a detailed written description of an individual computer system (kept up to date with controls over changes), its functions, security and interactions (EU GMP Annex 11.4) a lack of evidence for the quality assurance of the software-developed process (EU GMP Annex 11.5), coupled with a lack of adequate validation evidence to support the use of GxP-related computer systems may very well be either a critical or major deficiency. Ranking will depend on the inspector s risk assessment. 

Alternatively, if the decision is made to buy only commercially available software, or only commercially developed add-ons or automation scripts, then the pharmacometrician needs to participate in the key processes used to evaluate the vendor. The occurrence of key quality failures in widely used software has been previously documented (14). Therefore, the pharmacometrician should be intimately involved in the vendor audit process. If the vendor is not performing the quality assurance procedures just outlined for internal development, the cost (both in quality and accuracy of future work) will be in jeopardy. As discussed later in the section on validation documentation, the ability to state what the vendor s quality processes are will mitigate the need to perform functional software testing at the same level that has already been executed by the vendor s quality assurance group. 

Furthermore, it is also plain from the definition of validation above that documentary evidence is the lodestar of validation and the tool by which the assurance is derived. In respect of software, the assurance needed will be in the form of documentary evidence, not of the product directly (though this may be included) but, as we have shown, from an examination of the development process that produced it. This strongly implies that the product is inseparable from the process, and the fitness for use of the product can only be secured through the rigorous control of the process that produced it. This ought to come as no surprise, since it is precisely this principle, the essence of the science of statistical process control, that determines the quality of any manufactured or fabricated product. In other words, the quality (of fitness for use) of an item is entirely determined by the process that produced it, where quality is defined according to the ISO 8402 [3] ... 

Software reliability assessment is different from traditional reliability techniques and requires a different process. The use of development standards is common in current good practice. Software safety standards recommend processes to design and assure the integrity of safety-related software. However the reasoning on the validity of these processes is complex and opaque. 

The user should get assurance from the vendor that software has been validated during its development process and that documented quality principles have been applied during manufacturing and testing of the equipment. 

Computer systems and software products should be supplied with declarations documenting the evidence of software development validation. The user should also get assurance that development validation procedures and documents can be made available to the user. Critical formulae used in the analytical process should be documented in the user s operating manual. 

---