SBS - The Best Value in QMS software

ISO 13485 7.3.9 Change control in medical device software

#1
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:
  1. 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).
  2. With respect to software, is there a consensus on where a "change" begins and ends?
    1. Is a new version of software (which incorporates new features, bug fixes, etc.) a single "change" to the previous design output - the previous version?
    2. 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"?
    3. Is each chunk of committed code a "change" or is the final merge request the only "change"?
    4. Is fixing a bug a "change"?
    5. How about an engineering task like refactoring code?
I understand that this is a complex topic and not an easy knot to pick apart, but I'd appreciate any insight from you wise folk!
 
Elsmar Forum Sponsor

Mark Meer

Trusted Information Resource
#2
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).
That is correct. All change activities must be completed before transfer to production.

With respect to software, is there a consensus on where a "change" begins and ends?
Change begins when there is an identified need for a change (and decision to take action), and ends when all required change activities (according to you QMS) are completed.
Any change to the software (including bug fixes or refactoring code) should be in the scope of the process, though the burden of activities should be commensurate with the scale/impact of the change. If multiple things change at once to address the identified need for change, these can all be bundled together into a single change request.

Generally speaking the process should involve:
  1. A detailed list of everything that needs changing or will be updated
  2. A risk analysis of the impact of said changes, and commensurate assignment of verification & validation activities that will be required
In the example of a minor bug fix, (1) may be a modular piece of code; and thus (2) can rationalize that the change won't impact anything else, and so V&V activities might just involve checking that the bug is indeed fixed. On the other hand, in the case of major revisions (1) may be code that affects multiple functions; and thus (2) possible impact on functions is assessed as very possible, and therefore might necessitate a complete repeat of V&V activities.

Suggest you consult the IEC 62304 standard if you haven't already...

Luck!
MM
 
#3
Thanks Mark, that breakdown is appreciated. Part of the concern I have is that we are very thorough with our V&V and other risk controls for each change - adding a separate impact evaluation to comply with 7.3.9 doesn't currently feel like it adds any more value!

I'm familiar with 62304, yeah. We are slowly incorporating the requirements of 62304 too - my near-term focus is definitely on least-effort compliance with 14971, but I'll re-read 62304 to see if it might help us out.
 

Mark Meer

Trusted Information Resource
#4
...Part of the concern I have is that we are very thorough with our V&V and other risk controls for each change - adding a separate impact evaluation to comply with 7.3.9 doesn't currently feel like it adds any more value!
I'm not certain I understand. 7.3.9 deals with design changes, and explicitly requires impact assessment: "...determine significance of the change...", "...include evaluation of the effect of the changes...".

The standard text aside, impact assessment is critical to any change process, IMO, as it allows you to justify/tailor your V&V activities accordingly. This allows you to abide by your change process, while not making a mountain of work for yourself when you make relatively minor changes (e.g. bug fixes).
 
#5
The standard text aside, impact assessment is critical to any change process, IMO, as it allows you to justify/tailor your V&V activities accordingly. This allows you to abide by your change process, while not making a mountain of work for yourself when you make relatively minor changes (e.g. bug fixes).
Each change (Jira ticket) is reviewed and approved for work, code is written, and the work is independently reviewed and independently tested (62304-style: integration, system, and regression where relevant). Each change is subject to risk review and approval. A release candidate is created and then subject to validation (or revalidation) based on the changes included. All of these activities are documented.

I would argue that the determination of the significance of and the evaluation of the effect of changes is incorporated in these other activities. Hence capturing a potentially redundant "change impact evaluation" feels like busywork rather than value-add.

Do you think implementing the activities required by 62304 generally fulfils 7.3.9, or is some additional activity/output required?
 

Mark Meer

Trusted Information Resource
#6
...I would argue that the determination of the significance of and the evaluation of the effect of changes is incorporated in these other activities. Hence capturing a potentially redundant "change impact evaluation" feels like busywork rather than value-add.
Totally agree. No need for redundant documentation. All I'm suggesting is that the burden of processing software changes should have these assessments as inputs.

As a hypothetical example: say you wanted to correct a typo in some on-screen text. This will require a new S/W release (albeit minor), so should have change documented. In this case, however, the change may be as simple as making the correction in an isolated xml file, and it can be easily demonstrated that this won't impact anything else. As such verification can be as simple as confirming the typo is fixed (and, perhaps, a code review to confirm nothing in else in the xml was changed). The entire process - from change request to verification to approval to production transfer can be carried out within an hour.

Side note: I know that some companies have in their development procedures explicit allowances for certain "incremental"/"patch"/very-minor changes, but IMO all changes that result in a new software release should be subject to the entire process - just that the process itself allows for burden of activities to be commensurate with assessed impact.

Do you think implementing the activities required by 62304 generally fulfils 7.3.9, or is some additional activity/output required?
If your product is software-only, then compliance to 62304 is sufficient to meet 7.3.9 of 13485, IMO.
 
Last edited:

Gisly

Starting to get Involved
#7
nodonnell, have you looked at AAMI TIR:45, as it may give some "industry best practices" regardless how Agile your processes may be...
 
Thread starter Similar threads Forum Replies Date
A ISO 13485 procedure change and reflect to legacy manufacture items ISO 13485:2016 - Medical Device Quality Management Systems 2
D Reports under change management | ISO 13485:2016 & ISO 9001:2015 ISO 13485:2016 - Medical Device Quality Management Systems 3
M Change in Constitution / Ownership of firm -------ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 1
M ISO 13485:2016 Cl. 5.1 - Management commitment verbiage change ISO 13485:2016 - Medical Device Quality Management Systems 2
S Packaging and Label Change Requirements - ISO 13485/FDA 21CFR820 ISO 13485:2016 - Medical Device Quality Management Systems 3
B ISO 13485 & Change of Address/Location ISO 13485:2016 - Medical Device Quality Management Systems 8
D Question on using audit checklist ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 12
M ISO 13485 and document control for programs ISO 13485:2016 - Medical Device Quality Management Systems 6
M Customer Property - ISO 13485:2016 Clause 7.5.10 ISO 13485:2016 - Medical Device Quality Management Systems 9
pbojsen ISO 13485 Requirements versus FDA product classification and GMP exemptions - Audits ISO 13485:2016 - Medical Device Quality Management Systems 3
D Lead time to schedule an ISO 13485 audit General Auditing Discussions 2
S Does anyone have a checklist to prepare for ISO 13485, Stage I audit? ISO 13485:2016 - Medical Device Quality Management Systems 1
H QMS ISO 13485:2016 - ISO14971 IEC60304 etc ISO 13485:2016 - Medical Device Quality Management Systems 6
B Operational Procedures for ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 7
D ISO 14971 applicability in ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 7
E ISO 13485 in Clinical Trial conduct: Applicable or No ISO 13485:2016 - Medical Device Quality Management Systems 2
G ISO 13485 Certification - Can we get the ISO 13485 certification prior to shipment of the device? ISO 13485:2016 - Medical Device Quality Management Systems 6
N Does anyone use SGS for ISO 13485 / CE certification Registrars and Notified Bodies 0
Ed Panek ISO 13485:2016 Section 5.5.3 ISO 13485:2016 - Medical Device Quality Management Systems 3
ebrahim QMS as per ISO 13485, Clause 4.2 Requirements for regulatory purposes for Medical Devices Authorized Representatives. ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 scope (implantable) - Polymers for dental application EU Medical Device Regulations 9
D ISO 13485 & CE Certification for Surgical Gloves CE Marking (Conformité Européene) / CB Scheme 0
S Inventory Listing and ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 3
M ISO 13485:2016 Certification Scope ISO 13485:2016 - Medical Device Quality Management Systems 3
M Scope for ISO 13485 Certification of a Translation Service Provider ISO 13485:2016 - Medical Device Quality Management Systems 17
Q ISO 13485 7.5.6 Validation - Off the shelf Software ISO 13485:2016 - Medical Device Quality Management Systems 3
A ISO 13485 Certification for Resin Manufacturer ISO 13485:2016 - Medical Device Quality Management Systems 4
A ISO 13485 Sterilization Clause Applicability ISO 13485:2016 - Medical Device Quality Management Systems 7
K ISO 13485 and compliance of electronic signature ISO 13485:2016 - Medical Device Quality Management Systems 5
T ISO 13485 - Assembly instructions written vs. online ISO 13485:2016 - Medical Device Quality Management Systems 5
M ISO 13485:2016 internal audit checklist Medical Device and FDA Regulations and Standards News 8
N 93/42/EEC certification without ISO 13485 EU Medical Device Regulations 3
M How Specific in an ISO 13485:2016 Scope for a Contract Manufacturer ISO 13485:2016 - Medical Device Quality Management Systems 9
A ISO 13485 for Class 1 Medical Device ISO 13485:2016 - Medical Device Quality Management Systems 7
0 ISO 13485:2016 Chapter 8 Integration of the subsections ISO 13485:2016 - Medical Device Quality Management Systems 3
E ISO 13485 QMS certification as a Supplier ISO 13485:2016 - Medical Device Quality Management Systems 8
T ISO 13485:2016 Clauses related to process matrix ISO 13485:2016 - Medical Device Quality Management Systems 3
J Can signed agreements over-ride review of every "contract" under ISO 13485:2016? ISO 13485:2016 - Medical Device Quality Management Systems 2
J Implementing an ISO 13485 QMS Software ISO 13485:2016 - Medical Device Quality Management Systems 9
Q EN ISO 13485:2016/AC:2018 - AC:2018 being stated in the applicable harmonized standard listing Other ISO and International Standards and European Regulations 1
J Leveraging another company's ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 5
J New Job Position - Achieving ISO 13485 Certification ISO 13485:2016 - Medical Device Quality Management Systems 5
A Scope of ISO 13485 certificate ISO 13485:2016 - Medical Device Quality Management Systems 1
A ASL requirement when the supplier is certified for ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 6
K Medical Device Repairs and ISO 13485 Scope ISO 13485:2016 - Medical Device Quality Management Systems 7
M ISO 13485-2016 online certification ISO 13485:2016 - Medical Device Quality Management Systems 3
S Thoughts on managing ISO 9001, 13485, IATF 16949 and 17025 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 33
S Supplier Management ISO 13485: 2016- Which supplier needs to fill in a self assessment form? ISO 13485:2016 - Medical Device Quality Management Systems 6
J Possible to get ISO 13485 certified with only OEM Product? ISO 13485:2016 - Medical Device Quality Management Systems 4
D Definition of equipment for ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 1

Similar threads

Top Bottom