Unresolved Anomalies: Best Practices, FAQs, and Examples

Introduction 🔗

The “Unresolved Software Anomalies” document is required for most FDA marketing submissions (e.g., 510ks, De Novos, and PMAs). This document lists any known anomalies within the software that haven’t been fixed.

It sounds simple enough, but I’m often asked many questions about how to complete this document. I’ve collected all of this information here into one place.

If your team is struggling to complete your regulatory submission in time, let’s talk! Our team of engineers and regulatory experts can help you meet your timeline goals.

About the Author 🔗

FAQs 🔗

What is an “unresolved anomaly”? 🔗

The FDA defines an anomaly to be “any condition that deviates from the expected behavior based on requirements specifications, design documents, standards, or from someone’s perceptions or experiences.”

An unresolved anomaly is an anomaly that hasn’t been fixed in the version of the software you’re submitting to FDA.

Is an anomaly the same as a software bug? 🔗

No. Most, but not all, unresolved anomalies are software bugs.

If users consistently report that a UI components doesn’t work like they’d expect, this is a “condition that deviates from the expected behavior”.

Software Bugs mean you didn’t “build it right”. These are often caught during Design Verification.

Other Anomalies mean you didn’t “build the right thing”. These are often caught during Design Validation.

What information do I need to document regarding each unresolved anomaly? 🔗

Each anomaly should list the following information for each anomaly:

Name	Description	Required?
Description	A short description of the anomaly	Yes
Source	How the anomaly was discovered	Yes
Safety Impact	The impact on device safety and/or effectiveness (including operator usage and human factors considerations)	Yes
Security Impact	The impact on the device’s cybersecurity	Yes
Correction plans	Safety- and security-risk based rationale for not correcting the issue.	Yes
Risk level	Rank by risk level	Suggested
Defect classification	Defect classification per ANSI/AAMI SW91'sClassification of defects in health software	Suggested

Do we need to report unresolved anomalies to the customers (users)? 🔗

Yes, if there are work arounds or mitigations that are possible, these should be listed in the IFU.

Can we group bug reports or feedback into a single “unresolved anomaly”? 🔗

Yes, although the FDA guidance says the unresolved anomaly list is typically “generated as an output of a change control board or similar mechanism,” there’s no reason you can’t lump related entries together. In fact, this is often a useful exercise. You will however, need to keep track of customer complaints associated with software anomalies. This is important in making sure that customers are made aware when an anomaly has been fixed.

If a user complains about an unexpected behavior, yet it’s behaving as intended, do we need to report this as an unresolved anomaly? 🔗

Yes, because an “anomaly is any condition that deviates from the expected behavior based on …, or from someone’s perceptions or experiences.”

If you feel that user’s expectations are misguided, you can document this in the entry in the unresolved anomalies document. These types of situations often indicate that training materials need to be updated.

If a user provides feedback that they would expect a particular feature to be implemented, is this an unresolved anomaly? 🔗

No. We typically don’t consider feature requests to be an anomaly.

In one sense, the lack of the feature is a condition that deviates from your user’s expectations, but on the other hand, users often want software to have more features than it does. If the missing feature is related to safety or is preventing the user from using the device effectively, you could consider including it, but if it is more of a “wish list” feature and the current features are behaving as expected, we wouldn’t typically include this.

Do we include unresolved anomalies for software risks? 🔗

Not typically. If you’ve mitigated the software risk to the extent that’s appropriate, and the mitigations are functioning as expected, then any remaining risk is not an anomaly. Rather, it is an expected limitation of the design. Keep in mind, it’s not possible to remove all risk.

Now, if it were possible to mitigate the risk further, only the team did not do so, but then users are reporting that they’d expect the risk to be mitigated further, then it does become an unresolved anomaly.

Do we include fixed anomalies? 🔗

If the anomaly has been addressed in the version of the software under review, then no, the anomaly should not be listed in the Unresolved Anomalies document. Issues that have been fixed are typically tracked in the “Revision Level History” document and/or the release notes.

If the issue has been fixed in an ancestor version of the software from the one being reviewed by the FDA, you should note this in the “plans or timeframes for correct the problem.”

Can we include detailed information about the anomalies and the investigation into them? 🔗

We suggest removing the detailed problem reports and analysis from the documentation provided to the FDA. Instead, we suggest summarizing the problem succinctly so the FDA can review your submission quickly and efficiently. Furthermore, providing unnecessary details can open you up to questions that will delay your review.

Is it okay if we don’t have any unresolved anomalies? 🔗

Yes, although the FDA may be suspicious if you don’t have any, especially if its a more complex device. They may question whether your process is sufficiently robust and if you’re following it.

Consider listing the number of anomalies that have been resolved to date.

How do unresolved anomalies related to customer feedback? 🔗

Except at very small startups, customer feedback is triaged before being passed along to the software engineering team and only if the reviewer feels there’s an issue will it is passed along to engineering for a “problem report” investigation (IEC 62304). The problem report attempts to see if the issue has been solved already and/or what the root cause is. There are a few possible outcomes for a problem report investigation. Perhaps the issue is already fixed, or maybe the problem actually originates in hardware. Thus, not all feedback and/or problem reports will result in unresolved anomalies.

Do we need to include unresolved anomalies with root causes in the hardware? 🔗

No, the Unresolved Anomalies document only pertains to unresolved anomalies originating in the software.

Do you need to include unresolved anomalies with root causes in the hardware that could be mitigated by software (but haven’t yet)? 🔗

Again no, however, once you do implement the software-based risk control measures, you’ll need to add requirements for them. And you’ll need to verify these requirements.

How do unresolved anomalies relate to CAPAs? 🔗

The identification of a new unresolved anomaly in a released device may result in a CAPA, however, there are also CAPAs that are unrelated to unresolved anomalies in the software and typically, a CAPA is only raised when there is a trend. For example, if after investigation, it is determined that several software anomalies relate to a particular software module or software item, a CAPA may be raised.

Where can we read more about this document? 🔗

The 2023 Guidance titled “Content of Premarket Submissions for Device Software Functions” contains a short section on this.

The 2025 Cybersecurity Guidance adds the requirement to evaluate unresolved anomalies for security implications.

Examples 🔗

DICOM Viewer 🔗

Description	Source	Safety Impact	Security Impact	Correction Plans
DICOM images occasionally display inverted grayscale values when loaded from remote PACS	Discovered during design verification	Moderate. Users can identify the issue visually as it's immediately apparent, but it could lead to misinterpretation if not noticed. Workaround: reload the image or adjust window/level settings to verify correct display.	None. This is a display issue with no security implications.	Will be corrected in v2.3 (Q4 2025). Not corrected in current version due to low occurrence rate (0.1% of images) and available workarounds.
Measurement tool occasionally fails to save annotations when multiple users access the same study simultaneously	Discovered during design verification	Moderate. Measurements may need to be redrawn, potentially delaying diagnosis. Workaround: users should confirm annotations are saved before closing the study.	Low. Could potentially result in loss of annotation data, but no patient data exposure.	Will be addressed in v2.2 (Q1 2026). Current risk is acceptable with documented workaround in IFU.
Users expect thumbnail view to automatically update when new images are added to a study	Reported by multiple customers through support tickets	Low. Users must manually refresh to see new images, causing minor workflow inefficiency but no direct patient safety impact.	None. This is a user experience issue with no security implications.	Will be addressed in v2.2 (Q1 2026). IFU updated to clarify that manual refresh is required when new images are added to an open study.

ECG Arrhythmia Detection Library 🔗

Description	Source	Safety Impact	Security Impact	Correction Plans
Noise detector fails to identify high-frequency artifacts in ECG data collected on 50Hz line	Discovered during design verification with test database	Moderate. May lead to incorrect arrhythmia detection in noisy ECG signals. Workaround: Users should verify signal quality visually before relying on algorithm output.	None. This is a signal processing issue with no security implications.	Will be addressed in next release (Q4 2025). Current risk is acceptable with documented workaround in IFU.
Algorithm occasionally misclassifies S-type beats as normal beats	Discovered during EC57 performance testing	Low. Potential minor impact on rhythm classification but diagnostic significance is limited. All critical arrhythmias are still detected correctly.	None. This is a classification accuracy issue with no security implications.	Will be corrected in v2.2 (Q1 2026). Current classification performance still exceeds minimum EC57 requirements.
API memory allocation fails when processing extremely long ECG recordings (>24 hours)	Reported during fuzz testing	Low. System designed for shorter recording periods. Workaround: Process recordings in segments.	Moderate. Could potentially create a denial of service condition but no data exposure risk.	Fix implemented in development branch and will be included in next release (Q4 2025). IFU updated to specify maximum recording length limitations.

Revision History 🔗

Date	Summary of Change
18 July 2023	Initial Version
25 September 2025	Added examples and a few additional questions. Added security risk assessment details.