Verification and Validation Stage Checklists
List Of Known Anomalies
Document residual software bugs ensuring transparent risk assessment and informed release decisions.
Summary
The List of Known Anomalies documents all residual software bugs or anomalies that exist in your medical device software but will not be corrected prior to the current software release, including their risk impact and planned correction timeline.Why is a List of Known Anomalies important?
The List of Known Anomalies is essential for demonstrating transparency and risk management in software medical devices. It shows regulatory authorities that you have thoroughly tested your software, identified all known issues, and made informed decisions about which anomalies are acceptable for release based on risk assessment. This document protects both patients and your organization by ensuring that all stakeholders understand the limitations of the current software version and that appropriate risk controls are in place. Without this documentation, you cannot demonstrate that you have adequately assessed the safety implications of releasing software with known issues.Regulatory Context
Under 21 CFR Part 820 (Quality System Regulation) and FDA Software Guidance:
- All known software anomalies must be documented and risk-assessed
- Risk-based approach required for determining which anomalies are acceptable for release
- Software validation must include anomaly assessment (21 CFR 820.70(i))
- Change control procedures must address anomaly corrections in future releases
Special attention required for:
- Class III software devices requiring more stringent anomaly documentation
- Software as Medical Device (SaMD) requiring comprehensive anomaly risk assessment
- Cybersecurity-related anomalies requiring immediate attention regardless of risk level
- AI/ML devices where anomalies may indicate training data or algorithm issues
Guide
Your List of Known Anomalies must provide complete transparency about software issues that remain in your device at the time of release. This document demonstrates your commitment to patient safety through honest disclosure and risk-based decision making.Software Version Documentation
Clearly specify the software-version for which this anomaly list applies. Each software release should have its own anomaly list, allowing for proper version control and traceability. This ensures that stakeholders understand exactly which version of your software contains the documented anomalies.Comprehensive Anomaly Documentation
Your known-anomalies table must include detailed information for each anomaly. Document the Name of Anomaly using clear, descriptive terminology that allows easy identification. Provide a comprehensive Description that explains what the anomaly is, when it occurs, and under what conditions it manifests.Risk Impact Assessment
For each anomaly, assess its Impact on Risk using the three-tier system: “No impact on risk” for issues that cannot lead to patient harm, “Low impact on risk” for issues that could cause minor patient harm, and “Significant impact on risk” for issues that could cause serious patient harm. This assessment must align with your overall risk management approach and risk acceptability criteria.Risk Acceptability Determination
Determine whether each anomaly’s risk is Risk Acceptable based on your established risk matrix. Anomalies with “No impact on risk” or “Low impact on risk” can typically be marked as “Acceptable,” while those with “Significant impact on risk” should be “Unacceptable” and require immediate correction before release.Correction Planning
Document your Correction Action(s) for each anomaly, describing specific steps you will take to address the issue in future releases. Provide realistic Correction Timeline estimates such as “Next major software release,” “Next minor software release,” or “Next bug fix,” allowing stakeholders to understand when improvements will be available.Quality Assurance Integration
Ensure your anomaly list integrates with your overall quality management system. Anomalies should be tracked through your software problem resolution process and may trigger change management or CAPA procedures depending on their severity and impact.Example
Scenario: You develop a telemedicine platform for remote patient monitoring. During final testing, you identify three software anomalies: a minor UI display issue, a data synchronization delay, and an occasional login timeout. You assess their risk impact and determine correction priorities for the next software releases.List of Known Anomalies
ID: LKA-001 1. Scope The list within this document identifies the residual anomalies or “bugs” that exist in the software that will not be corrected prior to the software release in this version. Software Version: v2.1.0 2. Known Residual Anomalies| Name of Anomaly | Description | Impact on Risk | Risk Acceptable | Correction Action(s) | Correction Timeline |
|---|---|---|---|---|---|
| Patient List Display Truncation | Patient names longer than 25 characters are truncated in the main patient list view, showing only the first 25 characters followed by ”…” | No impact on risk | Acceptable | Implement dynamic text sizing and tooltip display for full names | Next minor software release |
| Data Sync Delay | Patient vital signs data synchronization between mobile app and web portal experiences delays of 30-60 seconds under high network load conditions | Low impact on risk | Acceptable | Optimize data synchronization algorithm and implement progressive sync for large datasets | Next major software release |
| Session Timeout Warning | Users occasionally do not receive the 5-minute session timeout warning dialog, resulting in unexpected session termination during data entry | Low impact on risk | Acceptable | Refactor session management system and implement redundant timeout warning mechanisms | Next bug fix |
Q&A
What should I do if I have no known anomalies to document?
What should I do if I have no known anomalies to document?
If you have no known anomalies remaining after testing, you can leave the anomalies table blank. This demonstrates excellent software quality and thorough testing. However, ensure your testing was comprehensive enough to identify potential issues.
How should I handle anomalies that have significant impact on risk?
How should I handle anomalies that have significant impact on risk?
Anomalies with significant impact on risk should typically be marked as “Unacceptable” and corrected before release. If you must release with such anomalies, you need strong justification through benefit-risk analysis and additional risk controls.
What's the difference between a bug and an anomaly in this context?
What's the difference between a bug and an anomaly in this context?
In medical device software, “anomaly” is the preferred term as it encompasses any deviation from expected behavior, including bugs, unexpected behaviors, and performance issues. All software anomalies should be documented regardless of their technical classification.
How often should I update the List of Known Anomalies?
How often should I update the List of Known Anomalies?
Update the list for each software release. Each version should have its own anomaly list, and you should track how anomalies are resolved or new ones discovered between releases. This provides clear version-to-version traceability.
Should I include user experience issues in the anomaly list?
Should I include user experience issues in the anomaly list?
Yes, include usability issues that could impact patient safety or device effectiveness. However, minor user preference issues that don’t affect safety or performance may not need to be documented as anomalies.
How do I determine the correction timeline for anomalies?
How do I determine the correction timeline for anomalies?
Base correction timelines on the anomaly’s risk impact, technical complexity, and your development schedule. High-risk anomalies should be corrected in the next bug fix, while low-risk issues can wait for minor or major releases.