Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Software change control process and defect tracking

racglobal

Involved In Discussions
#1
Hello

As a medical device manufacturer, our product is considered an electromedical device (i.e. IEC 60601 applies to us) , which is hardware containing software. My question concerns how software is controlled. The company has two teams, a software team that works independently at a different site. It does a lot of the coding. It has its own system of defect tracking, which is opaque to all of the rest of us. I have three questions:

1- Is the software defect tracking process supposed to be integrated into the QMS?
2-Everytime software needs to be upgrade, does it go through the same ECO process as we did for hardware design changes?
3-Is the software defect tracking akin to a complaint management system?

I look forward to your response. Thank you.
 

ECHO

Starting to get Involved
#2
1- Is the software defect tracking process supposed to be integrated into the QMS?
The tools you use for software development doesn't have to be same tools that you use for other quality activities, however, the software defect tracking process need to still be compliant to standards like 21 CFR part 11. Also don't forget to validate your tool.

2-Everytime software needs to be upgrade, does it go through the same ECO process as we did for hardware design changes?
Any change whether it is software or hardware should go through the same ECO process. There might be some tasks that you don't do, however, a justification is necessary. For example, I have seen a company get dinged for not writing a justification for not doing packaging testing for SW.

3-Is the software defect tracking akin to a complaint management system?
Take a look at Relationship between IEC 62304 problem resolution and ISO 13485

I have seen many software teams operate separately from the rest of the organization. As someone who has been on both sides of this, I don't think this is healthy for the company. Generally, the first step to bridge this gap should be writing a SOP for software development (IEC 62304) and putting a focus on how this SOP co-exists with the rest of the SOPs (ISO 13485, ISO 14971, etc)

I hope this helps.
 
Top Bottom