IEC 62304 Clause 9: Software Problem Resolution

A bug gets reported. Someone reproduces it. Someone fixes it. Someone closes the ticket.

Somewhere in that sequence, four regulated decisions happened. Most teams can't tell you where.

Was this a defect or expected behaviour? Does it affect safety? Where does the fix re-enter the development process? Who outside engineering needed to know?

Clause 9 of IEC 62304 is the software problem resolution process. It's the last clause in the standard and the one teams treat as the most optional, because on the surface it describes something you already do. You already have a bug tracker. You already triage. It reads like the standard is asking you to keep doing that.

It isn't. Clause 9 is about what the record has to prove afterwards.

This is the last piece in our clause-by-clause series — we've covered Clause 5, Clause 6, Clause 7 and Clause 8 over the past several months. Here's the practitioner's read on Clause 9.

What Clause 9 actually requires

Eight sub-clauses. Most of them are short, and most of them are about the record rather than the fix.

9.1 — Prepare problem reports. Every problem gets a report that characterises it: type, scope, criticality. This applies to problems found in released software and to problems found in software still under development. Many teams run a regulated process post-release and an informal channel during development. The standard doesn't make that distinction.

9.2 — Investigate the problem. Investigate, and evaluate whether the problem has safety relevance. If it does, that's a documented evaluation, not a hallway conversation. The output is a problem statement, a cause where one is known, and a decision on whether a change is needed.

9.3 — Advise relevant parties. Problems with safety relevance get communicated outward — to users, to regulators, to whoever the problem touches. This is the sub-clause that connects your bug tracker to your complaint handling and reporting obligations. It's also the one engineering teams forget exists, because it's the only one that isn't an engineering activity.

9.4 — Use the change control process. Approved changes route into the maintenance process (Clause 6) or configuration change control (Clause 8). Clause 9 doesn't implement changes. It decides one is needed and hands it off.

9.5 — Maintain records. Problem reports and their resolutions are retained, with status tracked through to closure.

9.6 — Analyse problems for trends. This is the one nobody does. You are required to look across problem reports for patterns, not just close them individually. A cluster of unrelated-looking defects in the same component is a signal about your architecture or your verification coverage, and the standard expects you to be looking for it.

9.7 — Verify software problem resolution. Verify that the change resolved the problem, that no adverse effects were introduced, and that the process was followed. Regression evidence, not "works on my machine."

9.8 — Test documentation contents. Records of what was tested, the results, the versions, the hardware and software configuration used, the test tools and their configuration, and traceability back to the problem.

The three processes teams conflate

Here's the confusion that costs the most time in practice. Three processes have a claim on what happens after a problem is reported, and they are not the same thing.

Clause 9 — problem resolution. Triggered by any reported problem, released or in development. Its output is an analysis and a decision.

Clause 6 — maintenance. Triggered by a decision to modify released software. It governs how that modification gets planned, implemented and released. Clause 9 feeds it.

CAPA under QMSR. Triggered when a problem indicates a systemic quality issue requiring corrective or preventive action at the quality-system level. It's broader than software, and most individual software defects never escalate into it.

Teams collapse these, and it fails in one of two directions.

Either everything becomes a CAPA, the process grinds, the backlog grows, and engineers quietly learn that reporting problems creates work — which is the worst possible incentive to build into a safety process. Or nothing does, the trend signal never escalates, and an auditor eventually identifies a pattern from data the team had all along.

The connective tissue is 9.6. Trend analysis is the mechanism that promotes recurring problems out of Clause 9 and into CAPA. Skip it and you have no defensible basis for deciding when a software bug becomes a quality system problem — you're just making the call by feel, under pressure, after someone else noticed.

Where teams get stuck

1. The two-tier bug tracker. Development bugs live in one workflow, "official" problems in another. Then an auditor asks how you know a pre-release defect wasn't safety relevant, and the honest answer is a shrug. 9.1 applies to both tiers.

2. Criticality that was never defined. Severity fields inherited from a generic template — P1, P2, P3 — with no mapping to safety relevance. Severity describes how much the problem hurts the user experience. Safety relevance describes whether it can hurt the patient. Two different axes, and a team tracking only one can't reconstruct 9.2 later.

3. Resolution without verification records. The fix is merged, the ticket is closed, CI is green. But nothing ties this test run, at this version, on this configuration, back to this problem. 9.7 and 9.8 want that link explicitly, and CI logs that roll off after 90 days don't provide it.

4. No trend analysis at all. 9.6 is the most-skipped requirement in the clause, and it's the one that would have caught the problem early in almost every post-market surprise I've seen. The data is sitting in the tracker. Nobody has a standing reason to look at it sideways.

5. An orphaned 9.3. Nobody in engineering owns "advise relevant parties," and nobody in quality is watching the bug tracker. Safety-relevant problems sit in Jira marked resolved while notification obligations run on a completely different clock.

Five patterns that work

Two fields, not one. Severity and safety relevance, separate and both mandatory. Safety relevance is yes, no, or undetermined, with a required rationale. "Undetermined" is a legitimate answer as long as the workflow routes it to someone whose job is to resolve it.

One intake, branch afterwards. Every problem enters the same queue regardless of source — internal test, customer complaint, CVE in a dependency, field report. The branch happens after evaluation, not before. This is what keeps 9.1 honest without turning every UI typo into a regulatory event.

Make 9.3 a person, not a status. Name the role that gets notified the moment safety relevance is set to yes. A field that changes value doesn't advise anyone. A named owner with a defined response window does.

Close the loop inside the ticket. Problem report links to change request, change request links to commits, verification run links back to the problem with the version and configuration recorded against it. Done this way, 9.7 and 9.8 are satisfied as a by-product of a workflow the team already follows, rather than as a documentation exercise someone performs afterwards from memory.

Put trend analysis on the calendar. Quarterly, thirty minutes, problem reports grouped by component, by type, by root cause. Write down the conclusion — including "no trend identified," which is a perfectly good finding. That written conclusion is the artifact 9.6 wants, and it's what demonstrates you were looking before the pattern became obvious to everyone else.

What this looks like in production

The teams that get Clause 9 right are not running a heavier process than everyone else. They're running the same triage, with two extra fields, one named owner and a recurring calendar item.

The difference shows up eighteen months later, when someone finds a regression and the question becomes what changed, when, why, and whether anybody considered the safety implications at the time. On a team with a working Clause 9 process, that's a query. On a team without one, it's a week of archaeology through commit messages and Slack threads — and a week of archaeology is exactly what an audit finding looks like from the outside.

Clause 5 gets you cleared. Clause 6 keeps you cleared. Clause 9 is how you find out what actually happened.

That closes the series. Five clauses, five posts: development, maintenance, risk management, configuration management, problem resolution. Read together, they describe a single system rather than five compliance obligations — which is the point the standard is making, and the one that's easiest to miss when you're reading it a clause at a time.

Building or supporting a medical device software team? Get in touch at hello@hattrick-it.com.