How to ensure CE for stand-alone software upgrades for a combined HW/SW system

Berto_gi

Starting to get Involved
Hi All,

I have a question regarding a system which has both hardware and software components. The hardware does get updates every now and then but the software is constantly updated for a variety of reasons including new feature and bug fixes. The backward compatibility of the software with previous hardware versions is also ensured. Up till recently this hardware and software combination has been considered as a single medical device (no accessories) and as such one entry in the DoC.

However a more keen look at the MDR implies that software-only upgrades might not be able to be sold and used with pre-exisiting hardware since the software on its own is neither an accessory or a stand-alone medical device.

Has anyone here experience in this area and some advice regarding how to best separate the hardware and software to enable selling software upgrades to pre-existing customers?

Thanks
 

yodon

Leader
Super Moderator
However a more keen look at the MDR implies that software-only upgrades might not be able to be sold and used with pre-exisiting hardware since the software on its own is neither an accessory or a stand-alone medical device.
What specific clauses from the MDR lead you to this conclusion?
 

Berto_gi

Starting to get Involved
What specific clauses from the MDR lead you to this conclusion?
Thanks for your reply.

Actually, this was a direct comment from the Notified Body during the first audit under MDR. The DoC was examined and the auditor asked if we intended to distribute software upgrades only or only as complete system overhauls. The auditor implied that this will not be possible under MDR as long as we do not separate the software which is upgraded from the rest of the system.

An independent RA consultant also confirmed this, however the NB and consultant both cannot advice on the best route to go. Ideally we would like to avoid creating two separate medical devices due to the effort of maintaining two technical files.
 

Berto_gi

Starting to get Involved
Take a look at Article 23(2), might be applicable in this case.
Thanks for your time

That clause would imply that the software should be considered to be a medical device. That however will mean maintaining two technical files and registration files, translation of user documents and more. This is what I am trying to avoid if possible. Especially considering that the software can only process information obtained from that particular hardware.

Any experience on a medical device/accessory combination that could work here?
 

yodon

Leader
Super Moderator
I wonder if a distinction of the types of change would help the discussion. If you're just doing bug fixes and changes that don't significantly change the safety or performance, you shouldn't need a new CE mark (the MDR does go into a discussion of software change impact on UDI in 6.5 but I didn't see anything beyond that).

I presume the hardware can't run without the software and the software can't run independently of the hardware so you have a system and I would frame bug fixes and minor enhancements more closely to "service & maintenance" than a "complete system overhaul."

I think it would be reasonable to ask for specific wording from the MDR that they feel is driving their position.

Would anybody really expect you to have to wait for a new CE mark if you identified a critical cybersecurity patch needed?
 

Berto_gi

Starting to get Involved
I wonder if a distinction of the types of change would help the discussion. If you're just doing bug fixes and changes that don't significantly change the safety or performance, you shouldn't need a new CE mark (the MDR does go into a discussion of software change impact on UDI in 6.5 but I didn't see anything beyond that).

I presume the hardware can't run without the software and the software can't run independently of the hardware so you have a system and I would frame bug fixes and minor enhancements more closely to "service & maintenance" than a "complete system overhaul."

I think it would be reasonable to ask for specific wording from the MDR that they feel is driving their position.

Would anybody really expect you to have to wait for a new CE mark if you identified a critical cybersecurity patch needed?
So this is correct. The software drives the hardware. The software can run independent from the hardware but relies on data previously acquired by the hardware.

The bugfixes or patches are not the problem. My understanding is that these are anyway not significant changes. However software upgrades which would typically trigger a new DoC such as platform change (maintenance purposes) or algorithm change to improve accuracy or new ways of interpreting the data. This is where the issue lies. Basically the NB is saying such software upgrades can only be sold in combination with the hardware and not independent. So the issue is how to classify this on the DoC such that these non-bugfix software upgrades can be sold independent of the hardware.

I will also ask again about the specific wording from the MDR.
 

AlexisRuiz2772

Starting to get Involved
From my POV, your software falls under the definition of "software driving or influencing a device". The software has a medical purpose on its own to be a MDSW by itself?
As far I understood, in your following answer:
The software can run independent from the hardware but relies on data previously acquired by the hardware.
Yes, the device depends on the use of the device to perform its intended purpose.

I think this software cannot be separatedly sold from the device, because it is considered a component essential for the use of the hardware.

If the software is updated with more functions, it is a significant change and must follow the MDR requirements . No CE mark required for the software, but for the whole device included the software.

This means, the technical file will must have the SW life cycle documentation (IEC 62304, and soonly 81001-5-1)
 
Thanks for your reply.

Actually, this was a direct comment from the Notified Body during the first audit under MDR. The DoC was examined and the auditor asked if we intended to distribute software upgrades only or only as complete system overhauls. The auditor implied that this will not be possible under MDR as long as we do not separate the software which is upgraded from the rest of the system.

An independent RA consultant also confirmed this, however the NB and consultant both cannot advice on the best route to go. Ideally we would like to avoid creating two separate medical devices due to the effort of maintaining two technical files.
Do I understand correctly that the TF for your hardware and software
system has already been audited by NB? Have you classified software separately using rule 11? Or you have classified the software and hardware system as a whole, not just software classified under separate rule? Or have you classified ME and software separately (for example, applying rule 10 and rule 11 for class 2a within one TF for the system)? And what have you stated in the DoC project - correspondence to one or several rules?
 

Berto_gi

Starting to get Involved
From my POV, your software falls under the definition of "software driving or influencing a device". The software has a medical purpose on its own to be a MDSW by itself?
As far I understood, in your following answer:

Yes, the device depends on the use of the device to perform its intended purpose.

I think this software cannot be separatedly sold from the device, because it is considered a component essential for the use of the hardware.

If the software is updated with more functions, it is a significant change and must follow the MDR requirements . No CE mark required for the software, but for the whole device included the software.

This means, the technical file will must have the SW life cycle documentation (IEC 62304, and soonly 81001-5-1)
Thanks for you input.

I would look at it this way: the software is similar to an operating system for a PC which allows the PC to perform as intended e.g. (Windows). The main difference being that it is the only OS that can run the hardware (no Linux, Apple or other OS). However the software does evolve independent of the hardware - new workflow features, views and so on. This is comparable to moving from Windows 10 to Windows 11. So the scenario where the software is sold separately is in such a case, where a customer already purchased the HW/SW system and would like to obtain the newest software version only (e.g. upgrade to Windows 11 without buying a new PC).

So up till now, all changes to the software have led to a new version of the complete system - and the DOC reflects this. The technical file also includes teh SW Life Cycle documentation. However this makes it impossible to provide especially through sales channels, the upgraded software to existing customers without forcing them to buy the complete system.
 
Top Bottom