Explaining MDCG 2019-11: Software Qualification & Classification for MDR & IVDR

Medical device software (MDSW) in the European Union is regulated by the European Commission (EC) via EU MDR and EU IVDR, and the classification rules for MDSW can be found in Annex VIII of both regulations. 

However, most software manufacturers will still have plenty of questions about whether their software qualifies as MDSW and, if so, how the risk classification rules apply to their specific device. 

In response to this uncertainty, the EC’s Medical Device Coordination Group released MDCG 2019-11. This guidance document provides software manufacturers clarification and practical examples for the qualification and classification of software that falls within the scope of EU MDR and EU IVDR.

This article will walk you through some of the major points in MDCG 2019-11 and help you understand how to use it to qualify and classify your medical device software.

FREE DOWNLOAD: Click here to download our Ultimate guide to Software as a Medical Device (SaMD).

How does MDCG 2019-11 define Medical Device Software (MDSW)?

MDCG 2019-11 defines medical device software (MDSW) as:

Software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the medical devices regulation or in vitro diagnostic medical devices regulation, regardless of whether the software is independent or driving or influencing the use of a device.

MDCG 2019-11 then lists four notes that further explain when software may be considered MDSW:

1. MDSW may be independent, by having its own intended medical purpose and thus meeting the definition of a medical device or in vitro diagnostic medical device on its own (i.e. alone).

2. If the software drives or influences a (hardware) medical device and also has a medical purpose, then it is qualified as a MDSW.

3.  Software may be qualified as MDSW regardless of its location (e.g. operating in the cloud, on a computer, on a mobile phone, or as an additional functionality on a hardware medical device).

4. MDSW may be intended to be used by healthcare professionals or laypersons (e.g. patients or other users).

Before we go any further, let’s look closer at number two in this list, which states that software which drives or influences a hardware medical device may be qualified as MDSW if it has a medical purpose. 

Now, in the US, the Food and Drug Administration (FDA) uses the term Software as a Medical Device (SaMD) instead of MDSW. And while SaMD and MDSW have similar definitions, they aren’t exactly the same.

For a device to be classified as SaMD, it must operate independently of any hardware medical device. If it drives or influences the device, it is known as Software in a Medical Device (SiMD). However, the second note in MDCG 2019-11 makes it clear that software may qualify as medical device software in the EU even if it drives or influences a hardware medical device.

This may seem like semantics, but as we’ll see later on, it can affect the way your device is classified in the EU. So it’s important to understand this difference and its implications for your device.

What are the qualification steps for medical device software in MDCG 2019-11?

MDCG 2019-11 also includes decision steps for deciding whether or not your software qualifies as medical device software. The guidance includes the steps for qualifying both medical devices and in vitro diagnostic devices. 

You can find a lengthier description of each step in the guidance document, but here we’ve reproduced an infographic that does a good job of visually representing them.

If you’ve worked through the decision tree and come to the conclusion that your software is MDSW, then your next step is to determine whether MDR (for medical devices) or IVDR (for in vitro diagnostics) requirements apply to your medical device software. 

MDCG 2019-11 also contains a handy infographic for making this determination:

Note that the third step of the infographic asks if the intended purpose is “substantially driven by IVD data sources” and only allows for a ‘yes’ or ‘no’ answer.

However, it’s possible that the intended purpose of the MDSW output data meets the definition for both a medical device and an in vitro diagnostic device set out in MDR and IVDR. In that case, you would need to weight the data sources based on their significance. MDCG 2019-11 includes examples of how to do this in Annex II.

How is MDSW classified under EU MDR and IVDR according to MDCG 2019-11?

Both MDR and IVDR contain implementing rules and classification rules for medical device software. The implementing rules tell you how to apply the rules for classifying your MDSW. For instance, there are two implementing rules in MDR that MDCG 2019-11 calls out specifically due to their importance:

• Rule 3.3 - “Software, which drives or influences the use of a device, shall fall within the same class as the device. If software is independent of any other device, it shall be classified in its own right.”

• Rule 3.5 - “If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device’s intended purpose, the strictest rule and sub-rule resulting in higher classification will apply.”

This means that if more than one rule or sub-rule applies to your medical device software, you’ll apply the rule that results in the highest classification of your device. Also, note that MDSW that drives or influences a device takes the same classification as that device. 

This is where the difference between SaMD and MDSW comes into play. Software that would not be classified as SaMD in the US may still be classified as MDSW in the EU—and take a potentially high risk classification depending on the device it is driving or influencing.

Rules of Classification and Implementation per MDR

There are 22 classification rules in Annex VIII of MDR. However, Rule 11 gets the most attention in MDCG 2019-11, and for good reason. 

The risks of medical device software are often substantially different from those of a traditional hardware device; they are related more to the consequences of a failure to provide accurate information. 

So, Rule 11 was added to address these risks and help manufacturers appropriately categorize their MDSW according to the significance of the information it provides and the severity of the situation or patient’s condition. 

Annex III of MDCG 2019-11 includes the following infographic for clarification:

In practice, this means that nearly all medical device software will be classified as at least Class IIa.

Rules of Classification and Implementation per IVDR

MDCG 2019-11 makes note of implementing rules 1.4 and 1.9 in Annex VIII of IVDR, which are substantially similar to rules 3.3 and 3.5 in MDR:

• Rule 1.4 - “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 1.9 - “If several classification rules apply to the same device, the rule resulting in the higher classification shall apply.”

Now, as I wrap up here, I’d like to reiterate that this is just a summary of some of the salient points in MDCG 2019-11, and you will benefit greatly from reading the entire guidance document yourself. The guidance also has several helpful annexes which contain examples and further explanation of many of the items covered in this article.

FREE DOWNLOAD: Click here to download our Ultimate guide to Software as a Medical Device (SaMD).

Translate development efforts into regulatory success with Greenlight Guru

If you feel overwhelmed by the size and scope of MDR and IVDR, you’re not alone. Even seasoned medical device professionals are still working to understand the implications of the new regulations for their companies and devices. 

Add software development to that mix, and you have some extremely tricky subjects on your hands.

Fortunately, Greenlight Guru's QMS acts as a bridge between your development work and regulatory requirements, providing the necessary guardrails to ensure compliance without stifling innovation. 

We understand that speed is crucial in software development. With Greenlight Guru, you'll be able to keep pace with your development cycles, ensuring that compliance is built into the process from the start. Get your free demo of Greenlight Guru's QMS ➔