Hi! Thanks for the additional information.
Concerning the change: I would agree that it would be a significant change for a legacy device (which is what MDCG 2020-3 is for). For an MDR device with an Annex IX certificate I would consider the change only significant, if the addition of AI/Machine learning has a significant impact on your quality management system or is beyond the current scope of the certificate (MDCG 2020-3 does not apply here, there currently is no MDCG guidance detailing what is a significant change in these cases). In this case the NB would issue a respective amendment to the certificate. Since in your case the preparation of the certificate and the change seem to have overlapped, it might be that this will be already reflected in the initial certificate.
Concerning the separation of hardware device and firmware: It is kind of strange of the NB to simply require a separation of the two in the device listing, because in my view this also has effects on your technical documentation and conformity assessment procedure. Does this also mean that you have introduced a separate UDI-DI for the firmware device (and maybe even an additional Basic UDI-DI)? Whatever the changes are here, be careful that they are reflected in all of your documentation. However, this separation would make future similar changes probably easier for the MDR devices and allows more flexibility in dealing with the update of MDD devices.
Concerning the MDD devices already placed on the market: The safest solution from a regulatory point of view is probably to leave these devices unchanged and just supply them with safety/security updates tailored to the old version of the software for as long as the expected lifetime you declared for them requires. If you want to update nevertheless, then I think framing the update in a way that would transform them into new, MDR compliant devices with respective re-labelling is not feasible as it requires too much work. An FSCA is not required/possible because you do not have a safety/security problem.
A possible way might be to adapt the intended purpose of the firmware device (that you now have) to include the installation on the MDD devices and demonstrate that this combination is compliant (ideally by showing that the MDD hardware is identical to the MDR hardware). In this way the labeling of the hardware could remain (old CE mark and no UDI) and the labeling of the software displayed on the user interface would reflect the firmware device (new CE mark and UDI). This stretches the question if you modified the old device in a way that affects its intended purpose (pretty sure not) or its compliance and thereby designed a new device, but since you are the manufacturer of both devices I guess this can be argued. Because both CE marks will display the number of your notified body this probably should be cleared with them (ideally the NB remained identical during transition).
If you have additional questions, just let me know or contact me directly.
Best regards
Christoph
------------------------------
Christoph Kiesselbach
Reutlingen
Germany
------------------------------
Original Message:
Sent: 08-Nov-2023 10:52
From: Anonymous Member
Subject: EU MDR Transition for Hardware containing Software
This message was posted by a user wishing to remain anonymous
Hi! Thanks for your questions. My answers are bulleted:
The software is inseparably tied to the physical device (as firmware or comparable) and not a medical device in its own right, correct?
- That's correct. We have always treated the embedded sw as a medical device though, because I've found the rules around medical devices containing software to sometimes be nebulous. Better safe than sorry.
- That said, my NB asked me to update the device listing when I submitted this change, and to include the software as a device. This was not the case when I first put in my application. So I guess perhaps it is now officially considered its own medical device, even though it is embedded.
- (There is also a standalone software that the doctor can install on their desktop computer that is identical to the embedded software, but this hasn't gotten the update yet. The embedded software and the standalone software get updated on a staggered timeline, since we try to get approval of the embedded software first before taking the time to update the standalone software.)
What was the significant change that made an NB approval under the MDR necessary for a class IIa device? Assuming that you have an Annex IX certificate, an approval would only be required for changes that significantly affect your QMS or the device range - did you make changes affecting the intended use?
- Yes, it is an Annex IX certificate.
- We are adding an AI/Machine Learning algorithm. We used MDCG 2020-3 to determine that it was a significant change.
- No change to intended use though
Was the significant change related to a safety or security problem?
Original Message:
Sent: 08-Nov-2023 04:08
From: Christoph Kiesselbach
Subject: EU MDR Transition for Hardware containing Software
Hi Anon,
that is an interesting question. To be able to at least try to answer it, could you share some more information with respect to the following questions:
The software is inseparably tied to the physical device (as firmware or comparable) and not a medical device in its own right, correct?
What was the significant change that made an NB approval under the MDR necessary for a class IIa device? Assuming that you have an Annex IX certificate, an approval would only be required for changes that significantly affect your QMS or the device range - did you make changes affecting the intended use?
Was the significant change related to a safety or security problem?
Best regards, Christoph
------------------------------
Christoph Kiesselbach
Reutlingen
Germany
Original Message:
Sent: 07-Nov-2023 14:27
From: Anonymous Member
Subject: EU MDR Transition for Hardware containing Software
This message was posted by a user wishing to remain anonymous
Hello!
Our NB has greenlighted us for EU MDR and I am just now waiting on our certificate!!!
We manufacture a Class IIa device which is hardware containing software.
The physical device is CE marked. However, we just had a significant change to our software, which the NB approved under the MDR certificate.
For all of our legacy devices in the field with our OLD CE mark physically marked on the device, will I be able to update the SW to the new version with the significant change? Will I simply need to change the CE mark in the software Help/About screen to the new CE mark number? Will it call into question why there are two different CE marks on the device?
Or will I need to relabel the thousands of machines in the field to upgrade the software?