- Why Us
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.
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:
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).
If the software drives or influences a (hardware) medical device and also has a medical purpose, then it is qualified as a MDSW.
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).
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.
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.
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.
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.
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.
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 Academy stands ready to help you get to the bottom of some of the toughest questions you have about the industry.
With courses on MDR, IVDR, software development, and much, much more, Greenlight Guru Academy equips you with the knowledge needed to answer some of the most difficult questions in the industry.
Sign up for Greenlight Guru Academy to get started on a learning path that benefits you, your company, and your device.
Tom Rish is a Medical Device Guru at Greenlight Guru who works with customers to utilize their QMS software to build safer products on expedited timelines. He is a Biomedical Engineer who began his career developing implant and instrument systems in the orthopedic industry. He enjoys helping customers successfully...