A: The distinction between verification and validation as provided in the definition section of the FDA Quality System Regulation is somewhat general, both refer to satisfaction of requirements. Verification and validation are meant to represent different levels of test activities as explained below:

• Validation addresses the final test activities that occur prior to final acceptance of a product for release. These tests must include testing of intended use as defined by formal requirements and testing under actual or simulated use conditions. Validation tests are normally conducted by a party that is independent of the developer (Quality Assurance or the test group)
• Verification encompasses the lower levels of test activities that precede the final (validation) testing. These tests include unit test, module test, integration test, interface test, etc. Verification tests are normally conducted by the developer.

A: According to the FDA Quality System Regulation, all required records "shall be retained for a period of time equivalent to the design and expected life of the device, but in no case less than two years from the date of release for commercial distribution by the manufacturer." This suggests that it is important for the manufacturer to have a defined product life to at least establish the retention period for documents. This requirement is directed at documents associated with a device, for quality system software the applicable documents must be retained for the life of the software and as per internal procedures.

 

A: Tools used in support of the design and development process are considered to be part of the quality system as they support implementation of design controls and/or validation. As such these tools must be validated if an error in these tools could result in a device quality problem. Tools frequently used in the design and development process that should be validated include automated test tools (if used for formal testing), configuration management systems, and bug tracking systems.

 

A: Design controls applies to system validation and not just software. Corresponding documents or hardware components must be provided just as for software including schematics, drawings and applicable test procedures.

 

A: According to the Guidance for the Content of Premarket Submissions for Software contained in Medical Devices section 2 (2.2.1), the level of concern is the highest risk associated with our system as determined by the Risk Analysis. The recognized levels are Major, Moderate, and Minor.

 

A: Not according to the General Principles of Software Validation sections D5/Personnel and section I., as long as the company uses techniques such as “detailed written procedures and checklist” to “facilitate consistent application of intended testing activities”. Also, a company can show independence by using a tester that is not directly related to the development of the program.

 

A: Testing should “demonstrate that portions of the software not involved in the change were not adversely impacted” as well as testing to evaluate “the correctness of the implemented change.” This comes from General Principles of Software Validation sections G and Appendix VII.

 

A: The General Principles of Software Validation sections D5/Methods (Module paragraph) states that a trace table should be used to identify the safety critical code and look at this functionality for potential unit tests.

 

A: The FDA suggests that traces include the System Requirements, Software Requirements, Design Description, Source Code, Test Procedures, and Risk Analysis. However, this is often seen as cumbersome and unmaintainable. The concept of the trace matrix is to ensure that the documents are complete and that there is full coverage of the requirements. This can be accomplished by tracing the SRS, STP, and Risk Analysis.