Software quality assurance audits documentation

In many instances operating system software has already been developed and is offered as a fundamental part of the computer system ready for application software to be developed or configured. In such cases it is prudent to establish the existence of the respective software quality assurance plans and procedures and the design, development, and testing records. Identification and examination of this documentation can be conducted and recorded as part of the supplier audit. (See Sec. VI.)... 

The definition of supplier validation activities and documentation should be embedded in contractual agreements. In addition, suppfiers should agree to potential inspection by GxP regulatory agencies and Supplier Audit by pharmaceutical and healthcare companies. Supplier Audits can be conducted by the pharmaceutical or healthcare company s own personnel or, if this would compromise the supplier s commercial interests, by an independent software quality assurance auditor, consultant, or validation expert employed by the pharmaceutical or healthcare company. Auditors must be suitably qualified, for example by independent certification by examination to the quafity system standards such as ISO 9001 2000. Suppfier Audits are discussed in detail in Chapter 7. 

Howard Garston-Smith, formerly of Pfizer, has published a book on software quality assurance. It provides a postal audit checklist reproduced in Appendix 7C. If the supplier has already prepared an internal ISO 9000 mapping or an internal audit report on how it aligns to industry standards such as the GAMP Guide, this can be offered as an alternative to the auditor s postal checklist. A reduced postal checklist may be agreed upon, at the very least. Wherever possible, photocopies of actual example documents and test records should be inspected for documentary evidence of validation. Remember that the pharmaceutical and healthcare companies are themselves being inspected for documentary evidence of validation. 

The International Standards Organization (ISO) definition of audit is Systematic, independent, and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which agreed criteria are fulfilled. The bottom-line goal of the software developer audit process is to allow you to assess the developer s quality assurance (QA) system. 

A Source Code Review must be performed on application software unless there is evidence from the Supplier Audit that the source code has been, or will be, developed in a quality assured manner and subjected to review as part of its development life cycle. The decision and justification not to perform a review must be documented within the Validation Plan. 

As stated above, the validation plan is a crucial document. From experience, the best method to create the plan is to set up a small team, consisting of the user, system expert, and quality assurance representative. The plan will include the results of the risk and software category assessments as well as any additional requirements determined by the supplier audit. The plan will state what documents are required, when they will be produced (i.e., in what order), and by whom. The validation plan will state what must be done in order to confirm that a system will be validated. 

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. 

---