Regulatory Requirements for Medical Device Software Under the MDR and IVDR

Software can be a medical device. Essentially, the intended purpose determines whether an app, an algorithm, or an embedded control program falls under the Medical Device Regulation (MDR), formally Regulation (EU) 2017/745, and In Vitro Diagnostic Regulation (IVDR), formally Regulation (EU) 2017/746. If the software is classified as a medical device under the MDR or IVDR, the same fundamental obligations apply as for hardware, supplemented by software-specific requirements for design and development, validation, and monitoring.

This article clarifies when software is considered a medical device or IVD, how it is classified, and which product-related requirements must be met throughout its life cycle. The basis for this is the intended purpose, the classification rules, and a series of software-related standards that reflect the state of the art.

Software as a medical device

The starting point is the intended purpose, i.e., the use specified by the manufacturer. According to Article 2(1) of the MDR, a medical device exists if the software serves one of the medical purposes listed there, such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of diseases. Software that meets this definition is referred to as Medical Device Software (MDSW) in accordance with MDCG 2019-11 Rev. 1. Additionally, it should be assessed whether the software can be considered an accessory for a medical device or whether it controls or influences the use of a medical device. Such software may also be subject to regulatory requirements, even if it does not qualify as standalone MDSW.

The MDCG 2019-11 Rev. 1 guideline describes how this assessment is carried out in practice. The key point is that not all health-related software is a medical device. Software that exclusively stores, archives, compresses, or forwards health data without modification is generally not a medical device. Applications for administration, lifestyle, or wellness are also generally not covered by the MDR or IVDR. Software that processes health information is subject to regulation only if this processing directly serves a medical purpose.

For software related to electronic health records, clinical information systems, or interoperable health data spaces, the distinction from MDSW, requirements for interoperability, data quality, data access, and data protection, as well as potential interactions with the European Health Data Space, should also be tested.

The specific function is therefore decisive. If software calculates, interprets, or links data in such a way that information for medical decisions is generated, this supports classification as a medical device. Merely displaying or transmitting data without providing its own medical interpretation, on the other hand, argues against such classification.

MDR or IVDR

Once it is established that the software qualifies as a medical device, it must be classified under the appropriate regulation. Here, too, the intended purpose is decisive.

Software that provides information based on data from in vitro examinations of samples taken from the human body for a medical purpose relevant to the IVDR is considered In Vitro Diagnostic Medical Device Software (IVD-MDSW) and falls under the IVDR. An example is software that analyzes laboratory test results from a blood sample and generates a result with diagnostic significance. Software with a different medical purpose that does not fall within the scope of the IVDR may fall under the MDR, provided it meets the definition of a medical device under Article 2(1) of the MDR. If software processes both IVD test results and other health-related data, MDCG 2019-11 Rev. 1 stipulates that the origin of the data critical to the medical conclusion is decisive.

This determination affects the entire subsequent conformity assessment process, as the MDR and IVDR provide for different classification rules, conformity assessment procedures, and evidence requirements.

Classification

The risk class determines the conformity assessment procedure and, consequently, whether a Notified Body must be involved.

Under the MDR, classification is based on Annex VIII. For software, Rule 11 is particularly relevant. In simple terms: Software that provides information for decisions made for diagnostic or therapeutic purposes is classified as at least Class IIa. It is classified as Class III if the decision could result in death or an irreversible deterioration of health, and as Class IIb in the event of a serious deterioration or a surgical procedure. Software for monitoring physiological processes is generally classified as Class IIa. For vital parameters posing an immediate risk, it is classified as Class IIb. In all other cases, software intended for medical purposes remains in Class I. Rule 11 is considered broad in scope, which is why many MDSWs fall into Class IIa or higher and require a Notified Body.

Under the IVDR, classification is based on Annex VIII of the IVDR, which defines Classes A through D. IVD MDSW is generally classified according to its intended purpose and the associated diagnostic context. Standalone software receives its own classification according to IVDR Rules 1 through 7.

Specific product-related requirements

In addition to the general safety and performance requirements (Annex I of the MDR or IVDR), several software-specific standards apply to software. The application of relevant standards is generally voluntary. To the extent that harmonized EN standards are listed in the Official Journal of the EU, their application may establish a presumption of conformity with the respective general safety and performance requirements they cover. Regardless of this, IEC 62304, IEC 62366-1, ISO 14971, IEC 82304-1, and relevant cybersecurity standards reflect the state of the art and are expected by Notified Bodies in practice.

Central to this is the software life cycle as defined by IEC 62304. The standard requires a structured process for planning, design and development, maintenance, risk management, configuration management, and issue management. It classifies software into safety classes A, B, or C based on the potential harm resulting from a malfunction. As the class increases, so do the requirements for documentation and verification. The current version is IEC 62304:2006, including amendment 1:2015. A second edition is currently still in the draft stage.

In terms of design, a distinction can be made between standalone and embedded software. For software that is not merely an integral part of a specific medical device, IEC 82304-1 may also be relevant. The term “standalone software,” which was frequently used in the past, should now be used only for explanatory purposes under the MDR/IVDR. The intended purpose, function, and regulatory role of the software remain decisive. IEC 82304-1 sets forth product-related requirements for healthcare software - such as accompanying documentation, Validation, and the market phase - and thus complements the process-oriented IEC 62304.

If software is a component of a medical electrical device or system, IEC 60601-1, including the PEMS (Programmable Electrical Medical System) requirements, must also be taken into account. For other active or implantable devices, specific products or safety standards may apply instead.

In addition, there are usability requirements per IEC 62366-1, which address usage-related risks, as well as cybersecurity requirements. For the latter, in addition to the software-related requirements from Annex I of the MDR/IVDR, Guideline MDCG 2019-16 Rev. 1 and the IEC 81001-5-1 standard are key reference points.

The following overview categorizes the standards according to their use cases:

Standard	Use Case
IEC 62304	Software lifecycle processes for all medical device software
IEC 82304-1	Product-specific requirements for standalone healthcare software
IEC 60601-1	Embedded software in medical electrical equipment
IEC 62366-1	Usability and usage-related risks
IEC 81001-5-1	Cybersecurity throughout the software life cycle
ISO 14971	Comprehensive risk management

Additional obligations throughout the life cycle

Ongoing obligations apply beyond design and development and conformity assessment.

Manufacturers must maintain an appropriate quality management system. For software, this includes, among other things, design and development processes, risk management, configuration and change management, as well as supplier and SOUP/OTS component control. ISO 13485 is the key standard for this.

Finally, the clinical evaluation pursuant to Article 61 and Annex XIV of the MDR, or the performance evaluation pursuant to Article 56 and Annex XIII of the IVDR, must be documented. It demonstrates the safety and performance of the software for its intended purpose.

The technical documentation in accordance with Annexes II and III of the MDR/IVDR must provide a complete and traceable record of the demonstration of conformity, including the software architecture, the verification and validation records, and the risk management.

After the device is placed on the market, a post-market surveillance system (the implementation of PMS, Articles 83 through 86 of the MDR or Articles 78 through 81 of the IVDR) and post-market clinical follow-up (PMCF) or, for IVDs, post-market performance follow-up (PMPF) must be carried out.

A distinctive feature typical of software is change management. Updates and new versions constitute changes and may be subject to documentation requirements. Whether a change is considered substantial - and thus requires the involvement of the Notified Body - depends on the nature and scope of the change. A documented process for reviewing changes is therefore an integral part of robust software management.

Related regulation: AI software

If the software incorporates artificial intelligence, the AI Act (Regulation (EU) 2024/1689) is also relevant. Medical devices with AI functionality that undergo a Conformity assessment by a Notified Body and meet the requirements of Article 6 of the AI Act are considered high-risk AI systems. The corresponding obligations take effect on August 2, 2028. The AI Act does not alter the MDR or IVDR classification but rather adds an additional layer. Guideline MDCG 2019-11 Rev. 1 has introduced the term “Medical Device Artificial Intelligence” (MDAI) for this purpose. However, regardless of the classification as a high-risk AI system and the requirements applicable only as of August 2, 2028, certain obligations under the AI Act - in particular, regulations on prohibited AI practices as well as selected transparency and AI competence requirements - are already applicable beforehand.

Practical approach

Formulate the intended purpose precisely, as it determines classification, regulation, and class.
Derive the classification and MDR/IVDR assignment based on the intended purpose and in accordance with MDCG 2019-11 Rev.1.
Determine the risk class and based on this, identify the conformity assessment procedure and the need for a Notified Body.
Align software processes with IEC 62304 at an early stage and consider the applicable standards depending on the product type (IEC 82304-1 or IEC 60601-1), as well as usability and cybersecurity requirements.
Plan for change management, PMS, and PMCF/PMPF processes from the outset and take the AI Act into account for AI components.

FAQ

Is every health app a medical device?

No. The intended purpose is the determining factor. Apps for lifestyle, wellness, or pure data management are generally not medical devices. Only a direct medical purpose as defined by the MDR/IVDR leads to classification as a medical device.

How can I tell whether the MDR or IVDR applies?

By the data basis for the medical claim. If it is based on in vitro testing of bodily samples, the IVDR applies. For other medical purposes, the MDR applies.

Does software often fall into Class I?

Rather rarely. Rule 11 of the MDR is broadly defined, so many software medical devices fall into at least Class IIa and require a Notified Body. The specific classification depends on the influence on medical decisions.

Do I have to apply IEC 62304?

The standard is not legally mandatory, but it is considered the state of the art for software lifecycle processes and is expected by Notified Bodies. Any deviation would need to be justified.

Are software updates subject to notification?

Updates are considered changes and may be subject to documentation requirements. Whether notification to the Notified Body is required depends on whether the change is substantial. A documented assessment process is required.

Conclusion

Medical device software is subject to the same fundamental obligations as medical device hardware, supplemented by software-specific requirements regarding the life cycle, Usability, cybersecurity, and documentation. The starting point is always the intended purpose, as it determines qualification, assignment to the MDR or IVDR, and classification. A proposed amendment to the MDR submitted in late 2025 may change the classification of software in the future, but it is currently still in the draft stage. An early, documented classification reduces the risk of subsequent Rework in the conformity assessment procedure.

If you would like to determine whether and how your software is regulated, we can assist you with qualification, classification, and selecting the appropriate path to market access. Please feel free to contact us.