Maps to
QMSR / ISO 13485: §820.100
ISO 13485: §8.5.2
IEC 62304: §9
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.
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.
Atomic constraints
- •A documented software problem resolution process must exist.
- •All problems must be reported and recorded in a problem tracking system.
- •Problems must be investigated for safety impact before deciding on a response.
- •Relevant stakeholders (users, regulators) must be notified when required by the safety assessment.
- •Problems must be resolved using the change control process — no uncontrolled hotfixes.
- •Problem records must include the investigation, resolution, and verification of the fix.
- •Problem data must be analyzed for trends to identify systemic issues.
- •Problem reports must be evaluated to determine whether they affect all versions or software releases of the product, not only the version in which the problem was first observed.
- •When a problem is identified in third-party software (SOUP) used in the product, the process must include evaluation of the SOUP vendor's fix availability and a timeline for incorporating the fix.
- •The problem resolution process must cover the entire product lifecycle through retirement, including problems reported for products that are no longer being actively developed.
- •For problems affecting devices already distributed, the process must determine whether regulatory notification or a field safety corrective action is required and must document that determination.
- •The software problem resolution process must be integrated with the organization's CAPA system so that systemic or safety-significant problems result in formal corrective actions with root cause analysis.
Common gaps
Problem resolution process not linked to CAPA system
majorSoftware 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.
Evidence signals
- •
FILE_EXISTS
Problem.*Resolution|Software.*Problem|Bug.*Tracker|SOP.*Problem|Incident.*Report
- •
CONTENT_MATCH
Does this document define a process for recording software problems, evaluating their safety impact, communicating to stakeholders when required, resolving issues through change control, and analyzing trends in problem data?
Audit defense
Software problem resolution for [your product] follows our SOP Software Problem Resolution (Doc ID: [your document ID]). All problems are triaged for safety impact, with mandatory notification procedures for safety-relevant issues. Problem data is aggregated for trend analysis in each PMS review cycle.