EN 62304:2006+A1:2015 clause 9 defines the software problem resolution process as eight linked activities: prepare problem reports, investigate each one, advise the parties who need to know, use the change control process from clause 8 to implement any fix, maintain the records, analyse problems for trends, verify each resolution, and test the fix in the context of the software system. The point is not to produce paperwork. The point is that every bug discovered during development, testing, or field use runs through the same controlled pipeline, so the manufacturer can prove to a Notified Body — and to the user who reported the problem — that the bug was understood, evaluated against the risk file, fixed if needed, verified, and closed. MDR Annex I Section 17.2 is the legal hook. EN 62304:2006+A1:2015 clause 9 is the harmonised tool that operationalises it.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN 62304:2006+A1:2015 clause 9 specifies the software problem resolution process and lists eight sub-activities that cover a problem from intake to verified closure.
  • Every problem report — whether it originates from internal testing, from a user, from a Notified Body finding, or from post-market surveillance — enters the same pipeline and carries the same minimum data set.
  • The investigation step links each problem to the risk management file under EN ISO 14971:2019+A11:2021 so the safety relevance is evaluated before a fix path is chosen.
  • Fixes are not implemented ad-hoc. Clause 9.4 requires the change control process from clause 8 to be used for any change that resolves a problem, which keeps the lifecycle discipline intact.
  • Trend analysis under clause 9.6 is the activity that turns individual bug reports into signals about the health of the software and the development process, and it is the single most-overlooked sub-activity at audit.
  • Verification and regression testing under clauses 9.7 and 9.8 close the loop — a fix is not closed until it has been verified and the relevant tests have been re-run to show nothing else broke.
  • MDR Annex I Section 17.2 requires software to be developed and maintained under the state of the art, and clause 9 is the harmonised definition of what that means for problem handling.
  • A startup with a modern issue tracker, a disciplined pull-request workflow, and a light-weight problem report template already runs 80 percent of clause 9. The remaining 20 percent is documentation and trend review.

Why this matters for your startup

The problem resolution question at an audit is concrete and brutal. The auditor opens the issue tracker, picks a closed bug at random, and asks for the full history. Who reported it. When. What was the investigation. What was the risk evaluation. What was the fix. Who authorised it. How was it verified. Which tests were re-run. Who was notified. A team that has run clause 9 discipline from the start opens the ticket and the linked pull request and walks through the history in four minutes. A team that has not has a hard afternoon.

The clause matters for a second reason that shows up later. When a problem report comes in from the field under post-market surveillance, the question "has this happened before" has to be answerable. If the problem history is scattered across chat, email, and developer memory, the manufacturer cannot see patterns and cannot tell whether a new report is an isolated incident or the third instance of the same underlying issue. Trend analysis under clause 9.6 is the activity that prevents this, and it only works if the intake and investigation steps were run consistently in the first place.

The cost of not running clause 9 is paid in three places. At the audit, in findings on an area where the standard text is unambiguous. In the field, where issues that should have been caught by trend analysis escalate into vigilance cases. And in engineering time, where the team re-investigates the same bug three times because there is no record of the first two investigations. The subtraction move is to run clause 9 as part of the normal engineering workflow from the first line of code, not to bolt it on later.

What EN 62304:2006+A1:2015 clause 9 actually says

Clause 9 of EN 62304:2006+A1:2015 is titled "Software problem resolution process" and it sits alongside clause 5 (development), clause 6 (maintenance), clause 7 (risk management), and clause 8 (configuration management). The clauses interlock: problem resolution uses change control from clause 8, draws on risk management from clause 7, and feeds into maintenance under clause 6. The standard is explicit that problem resolution is a lifecycle process, not a one-time activity, and that it applies during development and throughout the life of the released product.

The clause lists eight sub-activities. Each one is a required step in the process, though the depth scales with the software safety class (A, B, or C) assigned under clause 4 of the standard. Clause 9 applies to every safety class — there is no class for which a manufacturer is exempt from running a problem resolution process.

MDR Annex I Section 17.2 is the regulatory anchor. Section 17.2 requires software to be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management including information security, verification, and validation. (Regulation (EU) 2017/745, Annex I, Section 17.2.) Controlled problem resolution is one of the lifecycle principles. EN 62304:2006+A1:2015 clause 9 is the harmonised interpretation that provides presumption of conformity with the problem-handling aspects of Annex I Section 17.

9.1 Prepare problem reports

Every problem — from internal testing, code review, CI failures, user feedback, complaints, post-market surveillance, Notified Body findings, or cybersecurity vulnerability disclosures — enters the process as a problem report. The report carries a minimum data set: a unique identifier, the date, the reporter, a description of the problem, the conditions under which it was observed, the software version affected, the severity and safety relevance at first read, and the initial classification. The data set is the same whether the issue tracker calls the record a ticket, an issue, or a bug.

9.2 Investigate the problem

Each problem report is investigated. The investigation confirms the reported behaviour, identifies the root cause where possible, determines which software items are involved, and — this is the step startups most often skip — evaluates the problem against the risk management file under EN ISO 14971:2019+A11:2021. The risk evaluation asks whether the problem introduces a new hazard, changes the probability or severity of an existing hazard, or invalidates an existing risk control. The output is recorded on the problem report.

9.3 Advise relevant parties

The investigation's conclusions are communicated to the parties that need to know. Internally this is the engineering team, the risk management owner, the regulatory lead, and — for safety-relevant issues — management. Externally, depending on the severity, the conclusion may need to reach users through release notes or known-issues communication, the Notified Body in the context of surveillance, or the competent authority under vigilance obligations. Clause 9.3 does not define the external communication thresholds — those come from MDR Articles 87 to 92 and from MDCG 2023-3 Rev.2 on vigilance — but it does require the internal and relevant external advising to happen and to be recorded.

9.4 Use the change control process

Any change made to resolve the problem — to source code, to a configuration item, to a document, to a risk control — runs through the change control process defined under clause 8. There is no separate fast path for bug fixes. The same pull-request workflow, the same review, the same verification, the same traceability. Clause 9.4 exists to prevent the common failure of "emergency fix" commits that bypass the normal control process and land in a release with no record of authorisation or review.

9.5 Maintain records

The problem report, the investigation, the risk evaluation, the advising, the change history, and the verification are all captured in the problem record. The record lives in the issue tracker when the tracker supports the required fields, and is referenced from the configuration management system and the risk management file. Clause 9.5 does not require a paper form — it requires the record to be complete, retrievable, and durable.

Individual problem reports are analysed as a set to identify trends. The analysis asks whether multiple reports point to the same underlying cause, whether a particular software item or subsystem is generating a disproportionate number of reports, whether severity is drifting up over time, and whether process defects in development or verification are producing recurring problem classes. The trend analysis runs at a defined cadence — typically quarterly — and the output is recorded and reviewed. Clause 9.6 is the sub-activity most often missing at audit because it produces no natural artefact from day-to-day engineering work; it has to be scheduled explicitly.

9.7 Verify resolutions

Each problem closure is verified. Verification answers two questions: did the change actually resolve the problem, and did the change introduce any new problem. The verification is recorded on the problem report, linked to the test results, and reviewed before the problem is marked closed.

9.8 Test software

Clause 9.8 closes the loop on the system level. When a fix is implemented, the relevant software tests — unit, integration, system, and regression — are re-run to demonstrate that the fix works in the context of the whole software system and that nothing else was broken by the change. For a mature CI pipeline this is largely automatic; the regulatory work is to record which test run corresponds to the fix and to include the evidence in the problem record.

A worked bug-to-resolution flow

Take a concrete example. A user of a Class B diagnostic support application reports that, in a specific edge case involving measurements below a certain threshold, the displayed result is rounded incorrectly. The report comes in through the support channel.

Intake under clause 9.1. The support lead opens a ticket in the issue tracker, captures the reporter, the date, the software version, the reproduction steps, and a first-read severity, and sets the classification to "investigation pending." The ticket is the problem report.

Investigation under clause 9.2. An engineer reproduces the issue, identifies the root cause as an integer conversion that truncates instead of rounding in a specific code path, and lists the affected software items. The regulatory lead evaluates the problem against the risk file. The evaluation concludes that the affected code path participates in a risk control for measurement accuracy and that the incorrect rounding could, in a worst-case combination with other factors, contribute to a misinterpretation of a borderline result. The risk evaluation raises the severity of the problem and flags it as safety-relevant. The evaluation is recorded on the ticket.

Advising under clause 9.3. Because the problem is safety-relevant, the internal advising includes the engineering lead, the risk management owner, regulatory, and the quality lead. A decision is made that the problem warrants user communication and that a field safety notice threshold check is run against MDCG 2023-3 Rev.2. The vigilance evaluation concludes that a field safety notice is not required at this stage but that the fix will be shipped in the next scheduled release and documented in the release notes and the known-issues page.

Change control under clause 9.4. The engineer opens a pull request with the fix. The pull request is reviewed by a second engineer and by the regulatory lead because the risk file was touched. The CI pipeline runs the full test suite. The review is approved. The pull request is merged.

Records under clause 9.5. The ticket now links to the pull request, the CI run, the updated risk file entry, and the regulatory review. All the records live in systems that already exist. The regulatory file references the ticket as the authoritative problem record.

Verification under clause 9.7. A targeted verification script is run against the fix to confirm that the specific edge case now produces the expected rounded value and that the boundary cases around the threshold are correct.

System testing under clause 9.8. The regression suite is re-run against the fixed build and shows no new failures. The run is linked to the problem record.

The fix ships in the next release under the normal release process, with the configuration management release record referencing the problem ticket as one of the changes. The problem is closed.

Trend analysis under clause 9.6 runs at the next quarterly review. The rounding problem is one of three rounding-related issues found in the quarter. The trend analysis flags rounding and numeric edge cases as a cluster and triggers an action to extend the test suite with boundary-value coverage for all measurement display paths. That action becomes its own ticket and is tracked to closure. This is clause 9.6 actually doing the work it exists to do.

The Subtract to Ship issue tracker playbook

Configure the issue tracker once, then let the workflow do the clause for you. The playbook is short and can be set up in a day.

Use the existing tracker — GitHub Issues, GitLab, Jira, Linear, whichever the engineering team already runs. Do not buy a second system.

Add a single "Problem Report" issue type or template with the required fields: problem description, reproduction steps, software version affected, reporter, reporter type (internal, user, PMS, NB, vulnerability), safety relevance (pending, evaluated), risk file reference, classification, resolution type, and verification evidence link. Every field maps to a clause 9 requirement.

Require the risk evaluation field to be completed before a ticket can move from "investigation" to "in progress." This is a workflow rule, not a manual discipline. If the tracker cannot enforce the rule, the investigation lead owns it.

Link every fix pull request to its ticket, and configure the merge workflow to require the link. The pull request review satisfies clause 9.4. The CI run attached to the pull request satisfies clause 9.7 and 9.8 for the automated portion.

Schedule a quarterly trend review as a recurring calendar item with a fixed agenda: top clusters, top offenders by subsystem, severity drift, process findings, actions. The output of the review is a short memo stored with the regulatory file. This is clause 9.6 running on a schedule.

Map the release process — which already uses the change control process from clause 8 — to produce a release record that lists the tickets closed in the release. The release record becomes the evidence that the problem resolution process fed into the configuration management process and into the release decision. See the configuration management post for the release record structure.

That is the entire playbook. No separate tool, no parallel process, no second set of records. The regulatory file references what the engineering team already produces.

Common mistakes startups make

  • Running bug triage in chat. Problems discussed and resolved in a team chat channel without a ticket leave no record. When the audit asks for the history, there is nothing to show. Every problem starts with a ticket, even if the fix is trivial.

  • Skipping the risk evaluation step. Engineers fix the bug and close the ticket without evaluating the problem against the risk file. Clause 9.2 requires the evaluation, and the evaluation is also what catches the safety-relevant issues that need user communication or vigilance checks.

  • Emergency fixes that bypass change control. A critical bug is patched directly on the release branch by one engineer without review. Clause 9.4 does not allow a fast path. The discipline has to hold even under time pressure, because the time pressure is exactly when shortcuts cause secondary failures.

  • No trend analysis. The team handles individual problems competently but never aggregates them. Clause 9.6 is the single most common audit finding on this clause. Schedule the review or it will not happen.

  • Closing tickets without verification evidence. A fix is merged and the ticket is closed, but the test evidence is not linked. Clause 9.7 and 9.8 require the verification to be part of the record.

Reality Check — Is your problem resolution process ready for an audit?

  1. Does every bug — internal, user-reported, PMS, vulnerability disclosure — start as a ticket in your issue tracker with the required fields populated?
  2. Is every problem evaluated against the risk management file before a fix path is chosen, and is the evaluation recorded on the ticket?
  3. Does every fix run through the same change control process as every other change, with no "emergency" bypass path?
  4. Can you pick a closed ticket at random and walk through the full history — reporter, investigation, risk evaluation, change, verification, test evidence, closure — in under five minutes?
  5. Do you run a scheduled trend analysis on your problem reports at least quarterly, with a written output?
  6. When a new problem comes in, can you query prior reports to check whether the issue has occurred before and whether there is an unresolved cluster?
  7. Are your safety-relevant problems routed through a defined vigilance-threshold check before they are closed?
  8. Is your release record linked to the tickets closed in the release, so the configuration management system and the problem resolution system share a single line of evidence?

Any question you cannot answer with a clear yes is where the clause 9 audit finding will come from.

Frequently Asked Questions

What is the software problem resolution process under EN 62304:2006+A1:2015? Clause 9 of EN 62304:2006+A1:2015 defines a process with eight sub-activities: prepare problem reports, investigate, advise relevant parties, use change control for any fix, maintain records, analyse problems for trends, verify resolutions, and test the software system. The process applies to all software safety classes and runs throughout the lifecycle — during development and across the life of the released product.

Do bug fixes need to go through the full change control process? Yes. Clause 9.4 requires any change made to resolve a problem to run through the change control process defined in clause 8. There is no separate fast path for bug fixes. The normal review, verification, and traceability requirements apply, which in a modern engineering workflow means a reviewed pull request with CI evidence and a link to the originating ticket.

How does problem resolution connect to the risk management file? Clause 9.2 requires each problem to be evaluated against the risk management file under EN ISO 14971:2019+A11:2021. The evaluation asks whether the problem introduces a new hazard, changes an existing one, or invalidates a risk control. Safety-relevant problems may also trigger vigilance-threshold checks under MDR Articles 87 to 92.

What is trend analysis under clause 9.6 and why does it matter? Trend analysis is the periodic review of problem reports as a set to identify clusters, recurring causes, subsystems generating disproportionate problems, and severity drift over time. It turns individual tickets into signals about the health of the software and the development process. Clause 9.6 is the most-overlooked sub-activity at audit because it produces no natural artefact from day-to-day engineering work and has to be scheduled explicitly.

Does clause 9 apply to Class A software? Yes. Clause 9 applies to all software safety classes under EN 62304:2006+A1:2015. The activities scale with the class, but even Class A software runs problem intake, investigation, change control, records, and verification.

Can we use GitHub Issues or Jira as our problem resolution system? Yes. Any issue tracker that supports the required fields — unique identifier, reporter, version affected, investigation, risk evaluation, change link, verification evidence, closure state — can carry the clause 9 process. The regulatory work is to document the tracker as the problem resolution system, define the required fields and workflow, and run the trend analysis on top. A second tool layered on the engineering stack usually adds friction without adding compliance.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17. Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), Clause 9 — Software problem resolution process. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for the risk evaluation step in clause 9.2.
  4. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for the QMS-level CAPA process that problem resolution feeds into.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on clause 9 of EN 62304:2006+A1:2015 and the problem resolution obligations that apply to medical device software under MDR Annex I Section 17. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the harmonised tool that operationalises the problem resolution requirement, not an independent authority. For startup-specific regulatory support on software problem resolution, issue tracker configuration, and trend analysis, Zechmeister Strategic Solutions is where this work is done in practice.