NBOG’s Best Practice Guide 2014-3: all you wanted to know about reporting software design changes
When should a manufacturer report devices changes or QMS changes to notified bodies, according to the 93/42/CE directive?
There hasn't been clear criteria, until the Notified Bodies Operating Group (NBOG) published the Best Practice Guide 2014-3 : Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System.
This guidance is the third of a series of 3 guidances published in november 2014 by the NBOG. The first two are more intended to be followed by notified bodies and should be known by manufacturers for their information.
The third one is the purpose of this post.
The guidance begins with a reminder of the EU regulations, a few definitions (pay attention to the definition of "critical supplier"). It then gives the recommended Steps of the manufacturer for the change assessment procedure.
Needless to say that you should review your Change Control procedure(s), in the light of these recommendations!
The recommendations insists on reporting substantial changes of the QMS or in the design of devices to notified bodies. The notified bodies made sure for a long time that manufacturers communicate on substantial changes, either by contract, or during audits, or through non-conformities. This guidance just sets a frame, which ensures that practices are harmonized between notified bodies.
This is good, but not the best part of the guidance.
Criteria for "substantial changes"
Section 5 of the guidances entitled Criteria for "substantial changes" is really the gem hidden inside the document.
For the first time, a European organization has established a set of criteria and listed examples to assess what a substantial design change is for a medical device and for a QMS.
The set of criteria is not closed. Hence the word should is employed on the introductory sentence of sections 5.1 Product changes, 5.2 Quality system changes, and 5.3 Changes to the product ranges. E.g. in 5.1: Product changes should be considered substantial if the change may affect .... But these criteria are still precise.
Precisions are given in the section 5.4 Particular cases, examples, with a section entitled Changes to software.
Ah, ah, changes to software
I don't know how many times I was asked the question: We've modified our software, should we report the change to our notified body? And I don't know how many times I answered: it depends. With the uneasy feeling that I passed for a consultant specialized in air fan! Thanks to this guidance I shouldn't.
The guidance addresses the vast majority of possible software changes, either in specifications, or usability, or algorithms, or bug fixes of different levels. The rationale behind the cases listed in the guidance is the calling into question of the intended use or of the risk assessment, caused by software change.
Based on the examples given in the guidance, it should (and I'm sure that it will) be easier to decide if software changes are substantial or not.
The curious case of operating system
The guidance considers that a software change that incorporates a significant change to the operating system on which the software runs should be considered a substantial change.
Needless to say that a variant of the question above is: We've installed our software on Windows <choose your version>, it runs perfect, should we report the change to our notified body? I think I'm going to continue to answer: it depends.
More seriously, by experience, the change of operating system is absolutely the most recurring case, for which deciding whether it is a substantial change or not, is not obvious.
It's true that change of OS should be questioned. But this case should have been extended to any SOUP the software uses to run.
What about the FDA?
For once, we can congratulate the NBOG for having succeeded in publishing a guidance with no equivalent on the US side!
The FDA published in 1997 the guidance: Deciding When to Submit a 510(k) for a Change to an Existing Device, with its famous decision-tree and its question B8, B8.1, B8.2, and B8.3 with considerations similar to those found in the NBOG’s Best Practice Guide 2014-3. But examples given are not as articulate as those found in NBOG's guide about software.
However, the FDA guidance is 17 years old! An eternity for software. Software wasn't as ubiquitous as today.
Anyway, NBOG’s Best Practice Guide 2014-3 is a very useful guidance, for software but more generally for all types of medical devices.