.png?width=109&height=108&name=Pharma%20(2).png)
.png?width=111&height=108&name=Medical%20Devices%20(2).png)
.png?width=84&height=107&name=IVD%20(2).png)
.png)
Share
Are you aware that the introduction of MDR may have affected your CE-marked medical software (MDSW)? Or will affect the CE marking of your first or next medical device software?
MDR – Regulation (EU) 2017/745 on medical devices – states in much more detail how software should be considered within the medical device environment (compared to the older MDD).
To give you an idea through a simple comparison, the word “software” appears 7 times in the MDD and 54 times in the MDR…
What does that mean? Well, this simple word count already indicates there’s more information on software in MDR, mostly regarding requirements.
In other words: the CE marking pathway for medical device software (MDSW) basically became stricter with MDR than with MDD. There are more specific requirements to meet.
In this blog post, you’ll learn how MDR impacts MDSW and what has changed from MDD.
How does MDR impact MDSW compared to MDD?
Software considered as Active devices in both MDR and MDD
Broadly speaking, the requirements in both documents are the same, but the MDR goes into more detail about the requirements, while the MDD was quite vague about them.
Both MDD and MDR consider Software to be “Active devices”
More classification rules in MDR
If you have already analyzed MDR a little, you know that there are many more classification rules than in MDD and they are more detailed, so it will facilitate the risk class evaluation.
Similar implementation rules in MDR and MDD
With regards to the classification rules’ implementation for software: they are the same in MDD and in MDR, even if the wording is a bit different.
-
MDD: Standalone software is considered an active medical device (Rules 9-11). Software, which drives a device or influences the use of a device, falls automatically in the same class.
-
MDR: Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right (Rule 11).
Higher classification (and more constraints) under MDR
As is the case with the MDs, the MDR classification for SW is now generally higher than under MDD. This means that there are more requirements to meet compliance, especially regarding clinical data and Verification & Validation (see the section on Essential requirements).
For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of the development lifecycle, risk management, validation, and verification.
Which leaves a lot of room for interpretation… Different interpretations, in turn, may lead to discussions between Notified Bodies and manufacturers.
Notion of State of the Art reused in MDR
The notion of ‘State of the Art’ means that you must apply the latest regulations and the most recent IEC standards for SW development, risk analysis, etc.
This notion is also reused in the MDR with additional information about reducing risk, performance, mobile application, network security, and IFU:
14.2 Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: (d) the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts
17. Electronic programmable systems — devices that incorporate electronic programmable systems and software that are devices in themselves
17.1. Devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance.
17.2. For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation. 5.5.2017 L 117/100 Official Journal of the European Union EN
17.3. Software referred to in this Section that is intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise).
17.4. Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended.
(23.4 f) where applicable, information allowing the healthcare professional to verify if the device is suitable and select the corresponding software and accessories;
(23.4(ab)) for devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended.
As a result, manufacturers must update their technical documentation because there are more requirements to comply with the regulation.
Additional requirements to be included in the technical documentation for MDR
There are also some additional descriptions on the technical documentation including pre-clinical &clinical data and UDI implementation (Annex II), Clinical Evaluation & PMCF requirements (Annex XIV), and Clinical investigation (Annex XV) for MDSW.
In addition, there are some hints on how Notified Bodies need to review the technical file for SW (Annex VII).
As more requirements are placed on the technical documentation under the MDR, it is nice to have an idea of how that documentation will be assessed by the Notified Body.
And, for the first time, the regulation clearly provides some information on HOW the notified body should assess the documentation.
Conclusion: more stringent CE marking pathway in MDR
The CE marking pathway for MDSW has become more stringent with MDR than with MDD. There are more and more specific requirements to meet and classification by default leans towards a higher risk classification.
As a result, medical device manufacturers first need to check their risk classification and then review their technical documentation accordingly, especially the clinical evidence.
Need help reclassifying your software or updating your technical documentation? Our RA and PMO teams can:
- support you to identify the gap analysis between MDD and MDR for your Software.
- help you to get new CE marking
%20Checklist.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.png)