Software in Medical Devices, by MD101 Consulting

MDCG 2020-3 Chart C or chart B

The difficult step is obviously the chart C of the MDCG 2020-3, with criteria focussed on software. We have tough times, to say the least. But, contrary to what we'd thought at first, it is possible to answer "No" to questions C1 to C5 when software changes are minor detailed design changes and source code changes, leaving untouched the OS, components, general GUI layout, and so on.

Yet, we have hard times with the question B2 of chart B: Do new risks require control measures or are existing risks negatively affected?
Practically speaking, when we make a change to a software behaviour, that change shouldn't bring a new risk.
E.g.: it is possible to sort patients by name, surname, date of birth. We add weight and size, it doesn't bring a new risk. With can rely on the risks on sorting patients.

No new risk pops out and the existing mitigation actions are not impaired. We can answer "No" to question B2.

But, if we implement a new function, even a small one in terms of detailed design and source code, it can bring new risks.
E.g.: it is possible to modify patient data in the sorted table. Modifying patient data was already possible in some other panel in the software. That small change is easy to implement, the software is already able to modify patient data. It adds a risk when the user modifies data, which then changes the sorted order after modification. The mitigation action is to sort data automatically after a modification, and to still leave the focus on the the previously modified line.

A new risk pops out. Even though the change is minor with chart C, since we have to add a line in our risk assessment matrix, it is major according to question B2.

New risks, major change

That's so easy to find new risks when you make changes to software! That potentially makes every change a major change.
One solution is to reuse an existing risk in your risk management file, more or less similar to your new one; provided that the risk acceptance isn't changed. In this case, there's no new risk.
That's a bit playing hide and seek with the MDCG. But that's a possibility.

Likewise, the new change brings a risk that is evaluated at a very low or at the lowest risk priority number. In this case, we can consider that no new risk is added. We could do that with the ability to modify data in our example.
Anyway, that's a bit playing hide and seek either to reuse risks or to disregard very low risks.

Cybersecurity

One pass-through in the MDCG is to categorise a change as a cybersecurity measure. If that's feasible, the change is allowed according to question C6. It's almost always possible to categorise a change of SOUP version as a cybersecurity measure. New versions bring closures of known vulnerabilities.
Even though we have question C1: New or major change of operating system or any component?, changing SOUP versions is a minor change, thanks to the cybersecurity excuse. More generally speaking, it's not defensible to leave known vulnerabilities and the MDCG did take that case into account.

Some SaMD manufacturers could be tempted to pass in a release some other changes, poorly or not documented, hidden in the flow of cybersecurity updates. That's a solution I don't recommend :-).

Conclusion

We have some small possibilities to qualify changes requested by the users as minor. Even with this small window left opened in the MDCG 2020-3, Class I SaMD manufacturers will have to release one day new versions with major changes. That day is approaching, 2024 is eternity for software.

A major change of version, a change from class I MDD to class II+ MDR, a major change of paradigm.

Post-scriptum

Should I linger on the fact that a regulation locking SaMD in a version, deprive users from their requested changes? It is a way to miss a chance to bring some benefit to the patient (the new version with requested changes) at the cost of a minor risk (the undesirable side-effects of the requested changes). Minor risk, hence SaMD not in contact with the patient, without measuring function, used by medical professionals (and sometimes lay persons), and previously classified in class I MDD, never represent a major risk to the patient or the end-user.

The risk/benefit balance of class I MDD SaMD is degraded by the MDR lock-in.