Some Medical Device Regulation (MDR) changes affect all medical device manufacturers. Some of these changes are particularly aimed at manufacturers whose products contain software or are standalone software. Read on to find out what these manufacturers should be aware of.
This article describes the MDR requirements for medical devices that contain software or are software. In another article, you will find a comparison of the MDR and IVDR requirements for software.
1. MDR: Amended definitions and classification compared to the MDD
a) Software, medical device, accessories for a medical device
Software used to predict or diagnose diseases is considered a medical device. The new definition of terms in the Medical Device Regulation (MDR) makes this clear.
Software continues to be considered an active medical device, although this was no longer the case in the interim MDR drafts.
The software can be an accessory (again). This was always the case, but an unfortunate translation of the MPG (Medical Devices Directive) had caused it to disappear.
b) MDR for software classification
The classification rules have also changed. Rule 11 states the following:
Software intended to provide information that (may) be used to make decisions related to diagnosis or treatment falls into class IIa. Exceptions:
The software could directly or indirectly cause
- death or irreversible severe health disorders: In this case, the software falls into class III.
- a severe health disorder or surgery: the software falls into class IIb.
Software intended for monitoring physiological processes falls into class IIa. The exception is if changes to vital parameters can pose an immediate risk to the patient, in which case the software is classified as class IIb.
All other software falls into class I.
A discussion of Rule 11 shows the difficulty that the wording poses for manufacturers:
With this definition, almost all software falls into Classes IIa and higher.
Another article highlights the few cases of standalone software in Class I.
It is still the case that software that controls or influences another medical device falls into the same class as the medical device and that standalone software must be classified independently.
2. Essential requirements of the MDR for software
a) Compatibility and interoperability
The Medical Device Regulation (MDR) requires that risks must not arise from a lack of compatibility between medical devices. In this context, it explicitly mentions software.
The MDR makes the same demand with regard to interoperability:
“Devices that are intended to be operated together with other devices or products shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe.”
You can find the MDR definition and explanation of the term interoperability here.
The MDR writes in Annex I the essential requirements:
Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts;
b) IT safety, mobile platforms
The MDR has added a new chapter to Annex I: Electronic programmable systems – Devices that incorporate electronic programmable systems and software that are devices themselves.
The regulation has added the text in bold to the existing essential requirement:
For devices that incorporate software or that are medical software in themselves, the software must be validated according to the state of the art, taking into account the principles of the software life cycle, risk management, including information security, validation, and verification.
The requirement regarding mobile devices is also completely new:
“Devices that are intended to be operated together with other devices or products shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe.”
Another requirement that concerns IT security is that manufacturers must determine the minimum requirements for hardware, IT networks, and measures regarding IT security, including protection against unauthorized access.
The video training courses at the Medical Device University provide step-by-step instructions on how manufacturers can achieve IT safety for their products and ensure compliance with the regulatory requirements for IT safety.
3. Requirements for the technical documentation of software
If applicable, manufacturers must describe the software in the technical documentation and provide detailed information, including software verification and validation.
The MDR understands the term software validation not only as validation in the sense of a classic review of whether the intended purpose can be achieved but (like the FDA) as all software quality assurance measures. In particular, the MDR designates the following as technical documentation:
- Software design
- Software development process
- Software verification
- Software validation (now in the narrower sense)
- Further tests (in-house and in a simulated or real-life environment)
- Information on the runtime environment, such as different hardware configurations, operating systems, etc.
4. Further requirements
a) Unique Device Identification
Like all medical devices, the (standalone) software is subject to the requirement for clear identification using a Unique Device Identification (UDI).
Read more about UDI and implementation in software in this article. The MDR sets out specific requirements for medical device software.
b) Requirements for notified bodies
The MDR places specific demands on the notified bodies, in particular with regard to their competence. The Medical Device Regulation states in the annex:
The qualification criteria shall refer to the scope of the notified body’s designation […] providing sufficient level of detail for the required qualification […]. Specific qualification criteria shall be defined at least for the assessment of the pre-clinical evaluation, clinical evaluation, […], functional safety, software, packaging, […].
This requirement affects you at least indirectly: you will find more and more competent auditors
5. Conclusion and summary
Compared to the EU directives, the EU regulations MDR and IVDR place more specific requirements on software, regardless of whether the software is a medical device or a part of a medical device.
However, these requirements are still vague, so auditors and reviewers are using harmonised standards, particularly IEC 62304, for conformity testing.
Further requirements exist for specific software systems, such as IT security requirements for networked medical devices or requirements for medical devices that use artificial intelligence procedures such as machine learning.
The Johner Institute helps all manufacturers worldwide to comply with the regulatory requirements for medical devices and IVDs that are or contain software:
- Designing software processes to be legally compliant and efficient
- Finding and eliminating nonconformities in processes, products, and documents
- Training and developing development teams
Change history
- 2024-11-12: Article updated and restructured. Links added.
- 2017-11-17: The first version of the article was published.
