Special features of software
Software differs from traditional medical devices in one key respect: it changes rapidly. Releases, patches, cloud environments, interfaces, AI functions, and cybersecurity risks are all natural parts of its lifecycle. The MDR takes this into account. For software, Annex I requires, among other things, a state-of-the-art approach to the development lifecycle, risk management, verification, and validation, as well as minimum requirements for hardware, IT networks, and protection against unauthorized access. Cybersecurity is thus not a secondary IT issue, but rather part of the product’s safety and performance.
Especially with software, it is not the code that matters, but the medical purpose. A wellness app does not qualify as medical software simply because it is technically complex. Conversely, a seemingly simple application may very well fall under the MDR if its information is used for diagnostic or therapeutic decisions. The current MDCG guidance on the qualification and classification of software clarifies precisely this distinction.
Requirements in the MDR – where can they be found?
Anyone wishing to place software on the market under the MDR should read the relevant sections of the regulation very carefully. The most important sections are:
Annex I, which sets out the general safety and performance requirements. For software, the requirements regarding the development process, risk management, information security, validation, and IT environment are particularly relevant here.
Annexes II and III govern the technical documentation as well as the requirements for post-market surveillance. For software, this also includes evidence of software verification and validation as part of the product documentation.
Annex VIII, in particular Rule 11, is central to the classification of medical software. The 2019-11 MDCG, revised in 2025, explains the three basic principles of Rule 11: software that provides information for diagnostic or therapeutic decisions; software that monitors physiological processes; and “all other software.” Depending on clinical relevance, the classification can range from Class I to Class III.
Article 52 and Annexes IX through XI describe the conformity assessment. For Class I devices, the declaration of conformity is generally issued by the manufacturer itself; for Class IIa and higher, the involvement of a Notified Body is required.
Annex XIV, finally, is the central reference for clinical evaluation and Post-Market Clinical Follow-Up (PMCF). Especially with software, this is an area that is often established systematically too late.
The most important standards for medical software
The MDR specifies the regulatory requirements. In practical implementation, however, some standards are particularly important because they define the “state of the art.”
IEC 62304 is the core standard for the software lifecycle of medical software. It describes processes for the development and maintenance of software when the software itself is a medical device or an integral part of a medical device.
ISO 14971 is the reference standard for the risk management of medical devices, explicitly including Software as a Medical Device.
ISO 13485 is the central quality management standard for medical devices across the entire product lifecycle. For manufacturers seeking to establish a robust MDR-compliant organization, it serves as the practical operational foundation.
IEC 62366-1 covers usability engineering. This is particularly relevant for software because incorrect operation, misleading user guidance, or unclear alarms can have immediate safety consequences.
IEC 82304-1 is particularly relevant for health software on general IT platforms, i.e., for products without dedicated hardware. The standard addresses safety and security at the product level and is therefore of great importance for many standalone software products or Software as a Medical Device (SaMD). It is particularly noteworthy that IEC 82304-1 defines specific requirements for the validation of SaMD and is simultaneously referenced in IEC 62304, which is harmonized under the MDR.
Classification: The Crucial First Step
The most common and important initial question is: What class does my software fall into? It is precisely here that many projects fail—not because of the technology, but due to an unclear intended purpose. According to MDCG 2019-11 Rev.1, Rule 11 is essentially applied based on whether the software provides information for diagnostic or therapeutic decisions, monitors physiological processes, or falls into the residual category. Examples in the guidance show that diagnostic or therapy-supporting software can quickly fall into Class IIa, IIb, or III, while “all other software” is Class I.
From a Notified Body’s perspective, it is therefore clear: Classification is not an administrative step at the end, but the foundation for the entire marketing authorization strategy. It influences the scope of clinical evidence, the depth of technical documentation, PMS/PMCF requirements, and, of course, the question of whether and to what extent a Notified Body must be involved.
Clinical Data: It Won’t Work Without Clinical Evidence
For medical software, clinical evidence is not a “nice-to-have.” MDCG 2020-1 explicitly states that medical software with its own intended purpose and claimed clinical benefit requires clinical evidence as part of its conformity assessment. The goal is to demonstrate that the software is safe, achieves its performance, and delivers the claimed clinical benefit.
In practice, this means for software: It is not enough to simply show that the algorithm works technically. It must also be assessed whether the software provides the correct information in a clinical context, how this information is used, and whether it actually results in a demonstrable benefit. The clinical evaluation is not a one-time document, but an ongoing process.
Post-Market Clinical Follow-Up (PMCF)
PMCF is often underestimated in the context of software. The MDR defines PMCF as a continuous process that updates the clinical evaluation and must be anchored in the manufacturer’s PMS plan. This is precisely what the MDCG PMCF Template explicitly describes.
PMCF is particularly important for software because usage contexts, operating systems, interfaces, cyber threats, and clinical usage patterns are constantly changing. Manufacturers therefore need not only a sound marketing authorization strategy but also a robust system to collect and evaluate real-world performance and safety data after market launch and to feed this back into product improvements.
How does the certification process work from a Notified Body’s perspective?
The path to certification can be summarized in six key steps.
First: The intended use must be precisely defined. This is the only way to clearly determine whether the software falls under the MDR.
Second: The software must be correctly classified—typically based on Annex VIII and Rule 11.
Third: The company needs an appropriate quality management system and a verifiable, state-of-the-art development process, typically based on ISO 13485, IEC 62304, ISO 14971, and other standards depending on the product.
Fourth: The technical documentation must be complete, structured, and traceable—including software verification and validation.
Fifth: Clinical evaluation, PMS, and PMCF must be structured appropriately for the product.
Sixth: If the classification requires the involvement of a Notified Body, the formal conformity assessment follows the procedures set forth in the MDR.
