1 Table of Contents
- Notice
- Last Update
- Introduction
- Definition of SW Validation
- Some Terminology
- Rationale
- Objective of SW Validation
- What to validate
- Main Institutions
- Quality System Regulation
- Verification
- Validation
- Benefits and Difficulty in SW V&V
- SW Development as Part of System Design
- Overview
- Design Reveiw
- Validation Pinciples
- Overview
- Conditions
- Planning
- After SW Change
- SW Lifecycle
- SW Lifecycle Tasks
- Overview
- Quality Planning
- Configuration Management
- Task Requirements
- Design Overview
- Design Consideration
- Design Specification
- Design Activity and Task
- Testing Tasks
- Overview
- Consideration Before Testing Tasks
- Code Based Testing
- Solution to White Box Testing
- Development Testing
- User Site Testing
- Overview
- Testing
- Maintenance and SW Changes
- Validation of Quality System SW
- Overview
- Factors in Validation
2 Notice
- I am so sorry not for providing a compfortab visualization. Although I have tried to use revealjs provided in the guide section in the Quarto website, I am still clumsy at handling it. I will update this article as I get proficient at revealjs using Quarto. (it seems that Quarto system has some issues on mermaid diagrams.)
- The FDA validation guidance document is a bit difficult to understand because its explanations provide abstract, general, and present broad cocepts. For this reason, I compiled and made a summary of the document with many diagrams. However, some diagrams are too small to see. Please, scroll up your mouse wheel with the ‘Ctrl’ key on your keyboard pressed to zoom in on the small text in the diagrams.
- (Writing in Progress) It is hard to say that this version of summary is suitable for representing and covering the original document. Some of the content of this document has been excluded for personal use (less than 10% of it have been excluded).
2.1 Last Update
- 2022-12-28, Summary of Document
3 Introduction
3.1 Definition of Software Validation
Software Validation is a requirement of the Quality System regulation, which was published in the Federal Register on October 7, 1996 and took effect on June 1, 1997.
(See Title 21 Code of Federal Regulations (CFR) Part 820, and 61 Federal Register (FR) 52602, respectively.)
3.2 Some Terminology
The medical device Quality System regulation (21 CFR 820.3(k)) defines
- “establish” = “define, document, and implement”
- “establish” = “established”
- Confusing terminology: requirements, specification, verification, and validation.
3.3 Rationale
FDA has reported the following analysis:
- 242 of 3140 (7.7%) medical device recalls between 1992 and 1998 are attributable to software failures.
- 192 of the 242 (79.3%) failures were caused by software defects that were introduced when changes were made to the software after its initial production and distribution.
- The software validation check is a principal means of avoiding such defects and resultant recalls.
3.4 Objective of SW validation is to ensure
- accuracy
- reliability
- consistent intended performance, and
- the ability to discern invalid or altered records.
3.5 What to validate
Any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system, including any off-the-shelf software.
3.6 Main Institutions
- Center for Devices and Radiological Health (CDRH)
- U.S. Department Of Health and Human Services
- Food and Drug Administration
- Center for Biologics Evaluation and Research
4 Quality System Regulation
The guidance reflects that the minimum list of the relavant scientific and legal requirements that you must comply with.
5 Verification
- Installation_Qualification (IQ): documentation of correct installations according to requirements, specifications, vendor’s recommendations, and the FDA’s guidance for all hardware, software, equipment and systems.
- Operational_Qualification (OQ): establishment of confidence that the software shows constant performances according to specified requirements.
- Performance_Qualification (PQ): confirmation of the performance in the intended use according to the specified requirements for functionality and safety throughout the SW life cycle.
6 Validation
- A conclusion that software is validated is highly dependent upon comprehensive software testing, inspections, analyses, and other verification tasks performed at each stage of the software development life cycle.
- Testing of device software functionality in a simulated* use environment, and user site testing are typically included as components of an overall design validation program for a software automated device.
7 Benefits and Difficulty of SW V&V
7.1 Benefits of SW V&V
- Increase the usability and reliability of the device,
- Resulting in decreased failure rates, fewer recalls and corrective actions, less risk to patients and users, and reduced liability to device manufacturers.
- Reduce long term costs by making V&V easier and less costly to reliably modify software and revalidate software changes.
7.2 Difficulty in SW V&V
- a developer cannot test forever, and
- it is difficult to know how much evidence is enough.
- a matter of developing a level of confidence that the device meets all requirements
- Considerations for an acceptable level of confidence
- measures and estimates such as defects found in specifications documents
- testing coverage, and other techniques are all used before shipping the product.
- a level of confidence varies depending upon the safety risk (hazard) of a SW or device
8 SW Development as Part of System Design
8.1 Overview
Software validation must be considered within the context of the overall design validation for the system. A documented requirements specification represents
- user’s needs
- intended uses from which the product is developed.
A primary goal of SW validation is to demonstrate that all completed SW products comply with all documented requirements.
8.2 Design Review
- Design review is a primary tool for managing and evaluating development projects.
- At least one formal design review must be conducted during the device design process.
- It is recommended that multiple design reviews be conducted.
- Problems found at this point can
- be resolved more easily,
- save time and money, and
- reduce the likelihood of missing a critical issue.
9 Validation Principles
9.1 Overview
- Preparation for software validation should begin as early as possible because the final conclusion that the software is validated should be based on evidence collected from planned efforts conducted throughout the software lifecycle.