Subscribe to our Blog

, Experts' Insights , Medical Device Regulations

When Software is a Medical Device: What the MDR Says

Learn about SaMD as it appears in Rule 11 of Annex VIII of the EU Medical Device Regulation.

When Software is a Medical Device: What the MDR Says

We spoke to Rok Hrovatin, our Chief Compliance Officer, about software as a medical device as it is described in the EU Medical Device Regulation as it appears in Rule 11 of Annex VIII of the EU Medical Device Regulation.

Rule 11 of Annex VIII of the MDR focuses on software as a medical device (SaMD), i.e. software designed to perform a medical function without the need for actual hardware. It is therefore important for manufacturers of medical software to understand how to classify this software and what Rule 11 of Annex VIII of the MDR says.

How is medical software classified?

Software as a medical device (SaMD) is software that performs a medical function without the need for hardware. SaMD is classified in exactly the same way as a physical medical device, i.e. based on the risk associated with the use of the software for its intended purpose. There are however some considerations that must be taken into account. The classification of this “standalone” software is specified by Rule 11 in Annex VIII of the MDR.

I would like to emphasize that the importance of this classification step. It is one of the first steps in the development of software as a medical device and it is a very important step that you don't want to get wrong.

What does Rule 11 actually say? What are the key points?

Rule 11 of Annex VIII of the MDR is all about the classification of software as a medical device.

Rule 11 states that if the software provides information, which is used to make decisions towards a diagnosis or for treatment, then the software is Class IIa. If these decisions can cause death or irreversible deterioration of the state, or health of the patient, the software is Class III, while if such decisions lead to serious deterioration of health or to surgical intervention, then the software is Class IIb.

Rule 11 also describes software that is intended for the monitoring of physiological processes. This software is classified to be Class IIa. However, if vital physiological parameters are being monitored such that they would pose an immediate danger to the patient, then the software is Class IIb.

Finally, Rule 11 describes any other software as Class I, but there won’t be many cases in Class I. However, this is a free interpretation of the rule so my recommendation would be to reread and understand Rule 11 each time you have to classify software.

Which software is affected by Rule 11?

Essentially Rule 11 addresses all medical device software. There is no specific statement that “standalone” software will be considered. However, in practice, it is about the software as a medical device. So Rule 11 is about the software that does not influence the operation of a specific physical medical device.

How has the classification of software as a medical device changed under the new MDR?

With Rule 11 of Annex VIII in the European Medical Device Regulation (MDR), there is a much more precise classification of software, which didn’t exist before in the Medical Device Directive (MDD). As a consequence, there will be a number of cases where software as a medical device will have to be reclassified to a higher class.

To put things into perspective, can you give us some examples of software as a medical device?

First, I need to make clear that software as a medical device does not involve a physical medical device. So, the range of such software would be rather wide. Let’s look at some examples.

Smartphone Applications

A good example of a smartphone application is an insulin dose calculator based on the glucose level of a patient. Staying with smartphones, there is software that prepares and displays electrocardiogram signals, probably from a wearable ECG device.

Treatment Planning Applications

Then, we have treatment and dose planning software or tumour contouring software, both of them used for proton cancer therapy. These are also software as a medical device.

Diagnostic and Analysis Applications

Another example would be software used in diagnostics for anomaly detection of ECGs.

Image processing software used for the detection of cancerous tissue would be considered as SaMD. These applications are used for breast cancer detection or skin cancer identification.

There is also software for differential diagnosis from blood sample results, which is also another example of SaMD.

Can you clarify which of these example applications would fall into Class I, Class IIa, Class IIb, and Class III?

Before I do that, I have to clarify that the classification is driven by the precise intended use as it is specified by the manufacturer. So, just the title of the medical device software might not be enough to classify the software.

  • Class I
    • a fitness application for cardio health has the least risk
  • Class IIb
    • insulin dose calculator
    • treatment planning software or contouring software for tumours depending on the intended use
  • Class III
    • treatment planning software or contouring software for tumours depending on the intended use

Are there any specifics for SaMD when it comes to cybersecurity and the safety of patient data?

The MDR basically does not use the term cybersecurity, but there are still several direct requirements that address the topic. In General Safety and Performance requirements (Annex I of the MDR), requirement 14 addresses the risks originating from the interaction between software and the IT environment. Requirement 17 addresses protection against unauthorized access, and it also addresses cybersecurity through the information which must be provided to the user by the specification of the minimum IT requirements which must be established by the user. These also include protection against unauthorized access. So, while cybersecurity is not directly mentioned in the MDR, it is well covered by several requirements.

Where can our viewers find some helpful guidance on this topic?

My recommendation would be to stay with official publications, starting from the top, with the text of the MDR itself. Then, use the guidance documents provided by the Medical Device Coordination Group (MDCG). So, for SaMD, there's guidance 2019-11, which explains the qualification and classification of software. Cybersecurity is explained in guidance 2019-16 and the clinical evaluation of medical device software is discussed in 2020-1.

There are also standards that can be used, but I would like to stress that the standards haven't yet been harmonized under MDR. Therefore, the MDCG guidance documents are currently the best resources for explaining and interpreting the MDR requirements.

What standards relate to software as a medical device?

There are several standards for addressing specific areas of software, but there are five that have the most value to the medical device software development process. So, at this stage, one has to follow the requirements for the “state of the art”. This means starting from the top with a quality management system, and one would follow the requirements of ISO 13485:2016 to set up a quality management system geared for medical device development. Then, comes risk management activities as it is specified in ISO 14971:2019. Since ISO 14971:2019 does not directly address medical software, there is a technical report, IEC/TR 80002-1:2009, which provides guidance on the application of ISO 14971 to medical device software.

One should also not forget about risks originating from the use of software, and here IEC 62366 gives requirements for the implementation of usability engineering to medical devices.

Then, the most important standard for the development of medical software would be IEC 62304 which was published in 2006 and then amended in 2015. This standard addresses the development and maintenance of software throughout the software lifecycle processes.

These would be the most important standards which would have to be considered by anybody who is actually developing medical software. However, it is important to note that there are no harmonized standards under the MDR.

If you have any questions about this article or if you are interested in how you can reduce the time to market for your medical device, please contact us at The ArrowFast team of experts will be happy to help you.

ArrowFast Team

ArrowFast Team

ArrowFast Team - A group of Medical Device Engineering Specialists

  • Mail Linkedin Twitter


Get the latest MedTech posts, news & a monthly newsletter delivered straight to your inbox.


Would you like to talk with our team about developing a new medical device or other MedTech related topics?