Hi, I'm looking for a bit of discussion and best practice around ISO 13485:2016 clause 7.3.9 - Control of design and development changes.
I work for a manufacturer of medical devices; one of our products is a software-only medical device. My goal is to ensure we're doing no wasted work, and I'm concerned that we're overcomplicating our conformance with clause 7.3.9.
We use Jira to manage work and keep records; we use the information stored in Jira to create our design history file, risk management file, etc. With respect to compliance with clause 7.3.9, we currently require a change impact evaluation on the related Jira ticket before a developer can commit code for that ticket.
A couple of questions:
I work for a manufacturer of medical devices; one of our products is a software-only medical device. My goal is to ensure we're doing no wasted work, and I'm concerned that we're overcomplicating our conformance with clause 7.3.9.
We use Jira to manage work and keep records; we use the information stored in Jira to create our design history file, risk management file, etc. With respect to compliance with clause 7.3.9, we currently require a change impact evaluation on the related Jira ticket before a developer can commit code for that ticket.
A couple of questions:
- The requirement is to review, verify, validate (as appropriate) and approve each change "before implementation". Is there a consensus on when a change goes from "unimplemented" to "implemented"? My assumption is that a change is only "implemented" at the point where the changed product is transfered to manufacturing (i.e., is ready for production use).
- With respect to software, is there a consensus on where a "change" begins and ends?
- Is a new version of software (which incorporates new features, bug fixes, etc.) a single "change" to the previous design output - the previous version?
- At a lower level, a single User Story might be one change, but if a complex User Story is broken down into 3 Stories to make it more workable, do we now have 3 "changes"?
- Is each chunk of committed code a "change" or is the final merge request the only "change"?
- Is fixing a bug a "change"?
- How about an engineering task like refactoring code?