Software, qualification assurance

Operations checks of the system have been designed in to assure appropriate functioning of hardware and software. The installation qualification (IQ), confirming proper setup of system hardware and software, and the operational qualification (OQ), confirming functionality, have long been included in system valida-... 

In this chapter we guide quality assurance (QA) managers, lab managers, IT personnel, and users of equipment hardware and software through the entire qualification and validation process, from writing specifications and vendor qualification to installation and initial and ongoing operation. The following points are covered ... 

The installation qualification performed on the applications and the system software provides documented evidence to show, with a high degree of assurance, that the software has been installed according to an appropriate and approved technical design specification, and to the supplier s installation manual(s). Appropriate personnel must conduct the installation qualification of the application and system software. 

The system operational qualification performed on the computing technology provides documented evidence of a high degree of assurance that the hardware and software components perform as required by the system specification. This includes the verification that each unit or subsystem of the system operates as intended throughout all anticipated operating ranges. Appropriate personnel must conduct the system operational qualification. 

Qualification protocols are written documents prepared before conducting the qualification, describing the features of a particular application or item and how it should be tested. Qualification protocols identify the objectives, methods, and acceptance criteria for each test function contained in the applicable specification deliverable and identifies who is responsible for conducting the tests. In addition, the protocols should also specify how the data is to be collected, reported, and analyzed to determine if the acceptance criteria were met. The protocol should be reviewed by personnel with an appropriate understanding of computer systems and the functionality of the indicated system. Following the review, qualified personnel must approve each protocol in accordance with the company quality assurance procedures. In the software engineering world, qualification protocols are equivalent to test procedures. Traditionally the scope of the qualification protocols encompasses the following ... 

Assurance that equipment (including computer systems and software), which has been qualified (installation, operational, and performance qualification), is maintained in a qualified state. 

The objective of vendor qualification is to get assurance that the vendor s products development and manufacturing practices meet the requirements of the user s firm. For software development this usually means that the software is developed and validated following documented procedures. The requirements usually vary between user firms and, within companies,... 

SAP founded a so-called "FDA work group" with interested customers and consultants to define a common idea about GMP compliance for a software supplier. This group met several times, and SAP learned a lot about validation and qualification and changed its quality management to fulfill these legal requirements. Comparing GMP with other industry-specific quality rules like AQAP (Association of Quality Assurance Professionals) or QS 9000, SAP learned to see "validation as common sense", as Pfizer s Ken Chapman once stated in an article. SAP now has quality systems and a qualification strategy that satisfies the expectations of different industries. 

Whereas pre-developed software will be exeeptional in eategory A, because of the stringent requirements on product, process and their documentation, this type of software will be found more fiequently in category B and C. The proposed relaxations of qualification criteria in category B against category A are mainly the reduced amount of documentation required and a weaker process of product assurance. Table 4 shows the first level qualification criteria for category B. 

An interesting and useful classification of steps used to assure quality of analytical data (Bansal 2004) has drawn a clear distinction between quahfication of apparatus used to obtain the data and validation of the methods developed to use the apparatus to obtain the data pertinent to a particular analytical problem. Overlaid on this distinction is another, that between tests that must be completed satisfactorily before acquisition of the desired analytical data can begin (instrument quahfication and method vah-dation) on the one hand, and those that are conducted immediately before or simultaneously with data acquisition (system suitability and quahty control checks) on the other. The original paper (Bansal 2004) represented the outcome of a workshop intended to fiU a need for a more detailed scientific approach to what was termed Analytical Instrument Quahfication (AIQ) , particularly in the context of applications in the pharmaceutical industry. Note in particular that qualification of both hardware and software plays an important role in method validation. 

An excellent overview of the problem, particularly as it affects bioanalytical data and information submitted to the US FDA, was published by the Society for Quality Assurance (SQA 2000). The relevant regulatory documents on electronic documents and signatures are found as Part 11 of the US Code of Federal Regulations (CFR21 2003) and an FDA Guidance document is available (FDA 2003a). (Note that the FDA interprets the word equipment to include hardware and software as well as instrumentation.) The review of qualification of anal54ical instrumentation (Bansal 2004) includes a section on software validation and the same phases (DQ, IQ, OQ and PQ, see Section 9.5.1a) apply. 

A quality assurance programme is required to be established and implemented to cover items, services and processes that affect safety and are within the scope of this Safety Guide (Ref. [1], paras 3.14-3.16). The quality assurance programme is required to be implemented to ensure that data collection, data processing, studies, analyses and qualification, code validation (software) and verification, and other activities necessary to meet the recommendations of this Safety Guide are performed correctly [11,12]. 

It is not the aim of the automobile industry to one day develop resistors according to ISO 26262. However, this is not the case for software elements in this case the norm suggests that this type of qualification should not be used for new developments. Doesn t the software often behave different in a different microcontroller Are core operations for the different code instructions so unique Could compiler settings from one controller to another controller lead to the same safe functioning Even Autosar could not assure a sufficient safe and consistent environment for a safety-related application software. 

---