.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)
Share
- 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
