Navigating MDSW, IVDR, and MDR: New EU Guidance Decoded

As the 2020 deadline for compliance with the EU’s new Medical Device Regulation (MDR) fast approaches, the EC’s Medical Device Coordination Group (MDGC) has just issued new guidance which further clarifies which types of software are likely to come under its remit.

The document is 28 pages long and contains much hoped for clarification on both the MDR and IVDR, (the In Vitro Device Regulation - which will apply from 2022), showing what kinds of product will be classified as Medical Device Software (MDSW) and what classification they may be given, when the new regimes kick in.

It includes helpful flow diagrams and plenty of real-world examples which will further assist developers decide where their product is likely to sit from a regulatory stand point and the steps they will need to take to launch and market it in the EU. There are also welcome examples of those pieces of software that may not be considered MDSW at all.

So, what will define MDSW (Medical Device Software) in the future?

The guidance provides useful definitions of what will constitute MDSW:

“Software intended to be used alone or in combination, for a purpose as specified in the definition of a medical device in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device."

The guidance gives specific examples which illustrate these distinctions.

(i) MDSW that can directly control a piece of hardware (medical device) for example:

“MDSW intended to measure and transmit blood glucose levels, calculate insulin dose required and drive the insulin pump to administer the calculated dosage (closed loop insulin delivery system).”

(ii) MDSW that can ‘stand alone’ - providing immediate decision-triggering information, for example:

“MSDW smartwatch app, which is intended to send alarm notifications to the user and/or health practitioner when it recognises irregular heartbeats for the purpose of detecting cardiac arrhythmia”

(iii) MDSW can provide support for health professionals, for example:

"MDSW that provides insulin dose recommendations to a patient regardless of the method of delivery, whether via an insulin pump, insulin pen or insulin syringe.”

Classification clarification

MDSW that has its own intended purpose and also "drives or influences the use of a (hardware) device for a medical purpose is to be classified on its own, based on the intended purpose achieved." But in these cases, the MDSW's risk class cannot be lower than the risk class of the hardware medical device, the guidance says.

Decision trees

The document also contains two decision trees intended to help the easier identification of MDSW.

The first decision tree features five steps to qualify whether a product is MDSW.

The second decision tree guides device makers on whether the MDSW would fall under the MDR as a medical device or under the IVDR as an IVD.

When software is not a medical device - and when it is

The guidance reminds us that not all software used in healthcare settings qualifies as MDSW. For example, software used for staff planning, invoicing and ‘simple searches’ wouldn't qualify.

However, there are other distinctions that are not always so obvious.

If software is designed to process, analyse, create or modify any medical information, it could qualify as medical device software, if an intended medical purpose governs its creation or modification.

But the guidance draws a distinction between software that alters the representation of data for medical purposes and software that alters data for merely aesthetic or compatibility purposes (which would not qualify as MDSW).

Further guidance on Rule 11

Rule 11 has been causing some consternation in medical device development circles, so the clarification offered in this document may be welcome.

In line with part of the MDR and guidance from the International Medical Device Regulators Forum, the MDCG further explains Rule 11 in their new guidelines. This includes how it is intended to address the risks related to the information provided by an ‘active device’

A table in the annex of the guidance shows how a categorisation may be affected by the “significance of the information provided by the active device in relation to healthcare decision (patient management) combined with the healthcare situation (patient condition)."

Conclusion

In recent months as the date for MDR and IVDR compliance has approached, the EC has been producing a steady trickle of guidance to help clarify grey areas and frequently asked questions of medical device developers.

Medical device developers should, therefore, continue to familiarise themselves with these and the latest publication from the MDCG, to ensure that they understand what regulatory regime their inventions are likely to come under and what they will need to do to comply.