Relationship between IEC 62304 problem resolution and ISO 13485

[Sofie]

Hi,

We are developing medical device software and are looking for some more insights into how to (best) map IEC 62304 clause 9 software problem resolution with ISO 13485.

There are probably different options for implementing both standards in quality management system processes. Is there a best practice or can someone share experience on the following?

• Does IEC 62304 problem resolution correspond with ISO 13485 clause 8.3 control of nonconforming product (e.g. residual anomalies - release under concession)?
• Include problems encountered after release in our more generic complaint handling process (incl. resolution) and apply a separate process for pre-release problem resolution? Or 1 problem resolution process linked to complaint handling?
• Probably similar: ISO 13485 includes requirements for complaint handling (8.2.2) & requirements for nonconforming product after delivery (8.3). Does it make sense to implement both in the complaint handling procedure or are there any reasons to separate them?

 

[ECHO]

Most of the companies I worked at use JIRA for defect tracking. You can use JIRA in a number of ways but generally you assign a ticket to a known issue within the software. Once you created a ticket, you can assign it severity, priority and a certain workflow.

ISO 13485 is designed to handle different issues than "problem report" as defined in IEC 62304.

I personally won't recommend combining the complaint handling process with the software defect tracking process. You could easily paint yourself into a corner if you decide to combine the two.

 

[Sofie]

Thanks for sharing your experience. Could you provide some more detail on why you prefer to keep the software defect tracking separate? I am mainly looking for potential (dis)advantages of different implementations of the standards.

 

[blah01]

Some more feedback in case it helps...it might help to keep it in context in terms of how 62304 makes a distinction between "feedback" and "problems"...
• 6.1.a mentions to have a process for collecting and analysing feedback...
• 6.1.b requires to establish criteria when feedback is deemed to be a problem...(also see 6.2.1.2)
• Once feedback is deemed to be a SW problem, then clause 9 kicks in.

We actually do use JIRA here, however customer feedback first goes into our general complaint handling system from which we do periodic reviews to flush out known or potential SW issues (i.e. problems) that require further investigation. Those issues are the ones that get logged into JIRA and then processed accordingly and adhere to clause 9 of 62304. Note that in our case our SW is part of a device and is not a SaMD therefore we have customer complaints that are not tied to SW.

Hope this helps.

 

[ECHO]

Thanks for sharing your experience. Could you provide some more detail on why you prefer to keep the software defect tracking separate? I am mainly looking for potential (dis)advantages of different implementations of the standards.

I think blah01 did an awesome job explaining. What he explained is what I am used to.

I can think of 1 example of how a combined complaint process and SW defect tracker can give you headaches. Let's assume for a minute that we did combine them. (I am assuming the software defect tracking is rolled into the complaint management system. If an engineer is working on adding a new feature for your software, how would the engineer manage bugs between engineering releases? Since the new feature is not a product released to patients, would you want to keep them in your complaint system? Thinking of how this could affect your PMS process makes me cry a little on the inside.
Another concern I have is, how would you handle bugs you decide to fix in a future update? For the current release, you will need to show that it is not a safety concern. If your SW defect tracker was rolled into your complaint system, would you close it and plan to re-open it at a future date? (I am not even sure if that is allowed) Or would you create another complaint to implement the fix?

As far as I know, there is no regulation stating that you can't combine the 2 processes. However, I think you will find that you painted yourself into a corner when you try to implement it and execute it. I have not even touched on what blah01 mentioned above.

If you can explain your device a little further, I might be able help brainstorm a bit more effectively. Is your software SaMD? How complex is it? How many users are you expecting to have? How big would your software team be (software engineers, test engineers, quality engineers)? Are you planning on pushing multiple software updates to the field? Are you planning on keeping multiple versions live?

Have you asked your sw engineer or sw quality engineer in house on what they think? Even if they don't have medical device experience, they should have past experience handling defects. Since they are the ones who have to live with this process, I think your first step is to get their opinion, suggestions and most importantly, their buy-in.

 

[Sofie]

Our software is SaMD, provided as a service, and we have 5-10 people in the development team. We might have multiple versions in future.

I did not intend to handle pre-release problems in complaint handling .

The explanation of IEC 62304 6.1 makes sense. Feedback enters the complaint system (incl. evaluation, investigation, reportability, customer communication, etc.). My main question was whether to fully record clause 9 activities (cause, impact on safety, resolution, …) in the complaint form, or to enter the problem in the problem resolution system where also the pre-release problems are managed. It seems that the latter one is preferred. Would you then close the complaint if it is decided that the bug does not need to be fixed for the current version?

 

[blah01]

My main question was whether to fully record clause 9 activities (cause, impact on safety, resolution, …) in the complaint form, or to enter the problem in the problem resolution system where also the pre-release problems are managed. It seems that the latter one is preferred. Would you then close the complaint if it is decided that the bug does not need to be fixed for the current version?

Assuming that your problem resolution system create "ticket numbers" like JIRA would, then my suggestion would be to record the problem ticket# in your complaint case for traceability, and then keep the details of the investigation and outcome in your problem resolution system. This way your engineers simply use your problem resolution system and you still have traceability to the initial feedback/complaint case.

This way you could close the complaint when you've created the problem ticket# and let that system report on it. However I don't know the specifics on how you generate reports to track all this stuff so this suggestion is just a high-level one.

Something to keep in mind though is that if the initial complaint is related to a safety concern, then depending on which jurisdiction you are delivering this product there will be medical device mandatory reporting regulations to abide to which sometimes imposes a timeline within which to report the problem and therefore the timing of when the complaint is raised (not the problem report) will be critical and need to be tracked as part of the problem resolution. Also, if you choose to close a problem report raised from feedback received, then per 9.2.d you need to capture the rationale why you did not implement a change to address it.

Hope this helps.

 

[Sofie]

I like the suggested approach. Thanks a lot, all of your feedback was very helpful!

 

[Tidge]

Thanks for sharing your experience. Could you provide some more detail on why you prefer to keep the software defect tracking separate? I am mainly looking for potential (dis)advantages of different implementations of the standards.

I would like to add another voice to the chorus of "keep development issue tracking separate from post-launch issue tracking."

One of the headaches I've encountered with a combined system is that the procedural requirements for understanding anomalies during development is very different than issues that are reported once a product is on the market. Within a combined system, there is a serious risk of misapplying the procedural requirements of (or the methodology of approaching) one type of anomaly for the other. Some simple, hopefully illustrative examples:

1) During development, a 'failed test' can drive an update to a requirements, a code change, or a test method change... but generally the final result will be a 'passed test'. There are at most three people (not counting any independent quality review) that could be assigned actions: The designer, the code writer, or the tester.

2) After launch, a customer complains about the layout of a software-controlled user interface. The implications of this complaint are more varied, and will likely involve a variety of participants far outside the development and test team. The involved parties may be marketing, regulatory, and clinical, as well as the responsible design team.

If you favor a combined system, there are some immediate questions. Do you want to risk opening up every software defect uncovered during normal development to be considered for a corrective action? Do you want marketing present during code reviews? Do you want the complaints-handling group to be entering issues into the bug tracker? It is expected for the latter case that there exist an explicit feeder between customer complaint systems and corrective action systems whereas per development processes that expectation really only exists for residual anomalies at the end of the development phase.

Another headache from combined issue tracking is that the list of issues from development can dilute or obscure any residual anomalies and/or externally reported issues. Some folks may consider this a feature and not a bug!