General Principles of Software Validation. FDA guidance in the general principles of software validation emphasizes the need to assess the risks related to validating automated process equipment and quality system software. The level of effort for validation activities should be commensurate with risk. The guidance provides examples of levels of validation effort such as the following:
• Low level of validation effort for automated milling machines in which output is fully verified against specification prior to release.
• High level of validation effort for test equipment used for inspecting and accepting circuit boards in life-sustaining devices.
The guidance indicates that IVD manufacturers are required to validate only those software functions used in automated systems as related to the implementation of the quality system regulation. Manufacturers should also reconfirm validation of changes to those used functions.
In addition, the guidance states that defining usage requirements is the key to software validation and can include the following information:
• Intended use of software or automated equipment.
• Extent to which IVD manufacturers depend on software or equipment for production and quality.
• Expected operating environment for hardware and software.
• Performance (e.g., error handling, start-up, shutdown, security).
• Safety (e.g., sensors, alarms, interlocks, command sequences).
Other validation documentation that is traceable to the usage requirements should include:
• Predetermined expected results.
• Validation protocol.
• Acceptance criteria for critical parameters.
• Test cases and actual results.
• Validation summary report indicating that the software version is validated to its use.
For validating OTS software used in automated processes, the guidance recommends that a beginning point might be an assessment of the vendor’s development and validation information where available, and an audit of the vendor where appropriate, especially for high-risk software. For OTS tools (e.g., compilers, linkers, editors, operating systems, databases), the guidance states that exhaustive black-box testing may be impractical. Proper operation or validation of the tools may be inferred or covered through validating the overall application usage requirements that are traceable and indirectly implemented by the OTS tool functions. Guide to Inspections of Quality Systems (QSIT Guide). The QSIT guide is a training handbook for FDA investigators for conducting inspections of IVD manufacturers. Consistent with the requirements in the quality system regulation and the guidance in the general principles of software validation, the guide instructs FDA investigators to review the software validation documentation during a QSIT inspection.
21 CFR Part 11: Scope and Application Guidance. The Part 11 guidance (“Electronic Records; Electronic Signatures: Scope and Application”) indicates that FDA “intends to use enforcement discretion regarding specific Part 11 requirements for validation of computerized systems (section 11.10(a) and corresponding requirements in section 11.30). Although persons must still comply with all applicable predicate rule requirements for validation (e.g., 21 CFR 820.70(i)), this guidance should not be read to impose any additional requirements.”
Accordingly, IVD manufacturers should comply with the predicate rule requirements in section 820.70(i) for those systems containing electronic records and signatures since FDA does not intend to add additional validation requirements. The Part 11 scope and application guidance also provides specific advice for validating word processor software tools: “For instance, validation would not be important for a word processor used only to generate standard operating procedures.”
However, IVD manufacturers should be aware that the other remaining part 11 requirements could also be considered as part of the software usage requirements (e.g., security checks, operational system checks, device checks, password aging). In fact, validating these additional Part 11 software-related requirements may be mandatory.