The Workbench · Craft
A software problem report doesn't close on a fix
This blog has already covered what IEC 62304's safety classification decides before a manufacturer writes code, how the standard's SOUP duty runs independent of that classification, and how a changed requirement reopens the risk analysis it came from. Clause 9, the problem resolution process, is where all three of those threads meet after a device ships: a defect found in the field doesn't just need a patch. It needs the same kind of re-evaluation the standard already demands earlier in the lifecycle, run again on a schedule the standard sets rather than one a bug tracker's own workflow happens to follow.
A problem report is broader than a bug
Clause 9 doesn't limit what counts as a software problem to a defect a user finds after release. It requires a manufacturer to log any instance where a software item fails to satisfy its own specified requirements, its documentation, or a user's reasonable expectation of it — a description broad enough to catch a mismatch a tester finds during verification, an anomaly a support call surfaces months into the field, and a defect an engineer notices by accident while working on something unrelated. A defect log that only opens a record once a customer complains has already missed the reports the clause expects to catch earlier, inside the manufacturer's own testing and maintenance activity.
Fixed and verified are two different findings
Clause 9 doesn't let a report close the moment a code change addresses the reported symptom. It requires the manufacturer to verify the problem resolution itself — confirming the original defect is actually gone, and separately checking that the fix hasn't introduced a new one through regression. Those are two different tests run against two different questions, and a change that passes the first without ever running the second has confirmed the symptom is gone without confirming the fix didn't break something else the original report never mentioned. A tracker field marked “resolved” the day the code merges, with no distinct field for the regression check that clause 9 requires afterward, has recorded a fix, not a verified resolution.
A low-severity report can still be a hazard question
This blog has already covered how Clause 5.2.7 forces a requirements change to reopen the device's risk analysis. Clause 9 asks a version of the same question from the opposite direction: whenever a reported problem could indicate or contribute to a hazardous situation, the manufacturer has to evaluate it against the existing risk analysis, regardless of how minor the symptom looked to the person who first reported it. A rendering glitch that looks cosmetic can still touch a value a risk control measure depends on, and the severity a support ticket gets assigned on intake isn't a substitute for that evaluation — it's a triage label, not the hazard question clause 9 actually requires answered.
A pattern is a different finding than any one report
Clause 9 also asks a question no single problem report can answer on its own: whether a group of otherwise unremarkable reports, read together, point to a trend a case-by-case review would miss entirely. Three unrelated-looking crash reports from the same subsystem, spaced months apart and each individually closed as a one-off, can describe a single underlying defect nobody has connected because no report was ever compared against the others. A problem log that tracks each entry in isolation, with no periodic pass that groups reports by subsystem or symptom, has satisfied the letter of logging every problem while skipping the trend analysis clause 9 asks for separately.
The fix still has to travel through Clause 8
Clause 9's own resolution step doesn't stand apart from the standard's configuration management duty: any change made to resolve a logged problem has to go through the change control process Clause 8 already governs, not around it as a same-day hotfix pushed outside the normal build. A patch applied directly to a shipped build, without the version identification and change record Clause 8 requires, can close the symptom a user reported while leaving no traceable link between the fix and the problem report that prompted it — which is the same traceability gap a change made through the proper process was built to prevent.
Where this meets the file
A software problem log built around this structure needs a field for the regression check, distinct from the fix itself; a hazard-evaluation outcome tied to the device's risk file, run even on reports that arrive labeled minor; and a periodic trend pass across the whole log, not just a per-report review. A worksheet built around that structure, alongside the classification, SOUP, and requirements logic this blog has already covered, is previewed in the launch catalog. If your team's problem resolution process runs differently, the shelf takes that correction directly.
The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.