Problem tracking, investigation, corrective action, and record retention — standard CAPA and corrective action practice.
Safety triage of every problem before resolution; SOUP vendor fix tracking; formal integration with the CAPA system for systemic or safety-significant issues.
Safety impact assessment records — reviewers check that every problem report has a documented triage, and that safety-relevant problems trigger formal CAPA entries.
Maps to
IEC 62304: §9 Software problem resolution process
ISO 13485: §8.5.2 Corrective action
Pre-QMSR Part 820 (legacy QSR): §820.100 Corrective and preventive action.
Requirement text
The manufacturer shall establish a documented problem resolution process for software. Problems must be reported, investigated for safety impact, communicated to affected parties when appropriate, resolved using the change control process, and tracked to closure. Problem trends must be analyzed and records maintained.
Why this clause exists
The software problem resolution process serves a dual regulatory function: it is both the intake mechanism for post-market safety signals and the evidence record that demonstrates the organization is capable of detecting and responding to safety-relevant software defects before they cause widespread patient harm. Without a formal process, problem reports from clinicians, service technicians, and internal testing flow into informal channels where safety-relevance is assessed casually, fix urgency is driven by operational convenience rather than patient risk, and the aggregate signal that a class of defects is recurring in safety-relevant code areas is never assembled because no one is looking at the data across reports. IEC 62304:2006+A1:2015 clause 9 mandates the problem resolution process as a lifecycle-spanning discipline because software problems do not respect the production-to-market boundary: a defect in a device that has been deployed to patients and is no longer under active development still requires a formal process for evaluating whether it creates safety risk, whether currently distributed devices require field action, and whether it triggers CAPA obligations under ISO 13485. The trend analysis requirement is the clause's systemic view: individual problem records answer whether a specific defect was resolved; trend analysis answers whether the development process itself is producing defects at a rate or in a pattern that indicates a systemic root cause requiring corrective action independent of any individual problem's resolution.
What changed
Amendment 1 (2015) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for publishing known defects with risk assessments (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Problem resolution process not linked to CAPA system — Software problem reports are tracked in engineering tools (Jira, GitHub Issues) but not evaluated for whether they should trigger the quality management system's CAPA process. Software bugs that could affect safety are resolved as engineering tickets without root cause analysis or effectiveness verification.