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: §820.100 Corrective and preventive action.
Requirement text
The manufacturer shall establish a documented problem resolution process for software. Each problem detected in the medical device software must have a problem report; the problem must be investigated and its relevance to safety evaluated using the software risk management process; relevant parties must be advised of the existence of the problem, as appropriate; a change request must be created for actions needed to correct the problem, or the rationale for taking no action documented; change requests must be approved and implemented observing the requirements of the change control process; and resolutions must be verified to determine whether the problem has been resolved and the problem report closed. 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) introduced a new compliance path for legacy software (Clause 4.4), allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
In Clause 4.3, Amendment 1 struck the 2006 sentence "The software safety classes shall initially be assigned based on severity as follows" and its three severity-based class definitions, and inserted class definitions that depend on whether the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, with the resulting possible harm being non-serious injury (Class B) or death or serious injury (Class C). Figure 3 states that the probability of a software failure shall be assumed to be 1 and that only risk control measures not implemented within (external to) the software system shall be considered. The 2006 text already allowed a hardware risk control measure to reduce the class (from C to B, and from B to A); Amendment 1 inserted a NOTE 1 stating that external risk control measures can be hardware, an independent software system, health care procedures, or other means. Amendment 1 also inserted a NOTE to clause 5.3.5 (Identify segregation necessary for risk control) that ends: "Other means of segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3)."
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 identification and avoidance of common software defects (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.