Best Practices 🔗
The “Unresolved Anomalies” document is required for most FDA premarket submissions (e.g., 510ks). 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.”
The “Unresolved Anomalies” document should list the following information for each anomaly:
- A short summary of the problem
- The impact on device safety and/or effectiveness,
- Any related usage (human factors) issues,
- Any plans or timeframes for correcting the problem (where appropriate)
- Mitigations or workarounds (where appropriate)
- Rank by risk level (suggested)
- Defect classification per ANSI/AAMI SW91’s Classification of defects in health software (suggested).
FAQs 🔗
Do we need to report unresolved anomalies to the customers (users)? 🔗
Yes. Known anomalies should be
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? 🔗
This is a gray area. We typically wouldn’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 fixed issues? 🔗
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.
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 2022 Draft Guidance titled “Content of Premarket Submissions for Device Software Functions” contains a short section on this.
