ISO 13485 7.3.9 Change control in medical device software

[nodonnell]

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!

 

[Mark Meer]

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

 

[nodonnell]

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]

...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).

 

[nodonnell]

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]

...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.

 

[Gisly]

nodonnell, have you looked at AAMI TIR:45, as it may give some "industry best practices" regardless how Agile your processes may be...