The New MDCG Guidance: What does it mean for software providers?

In October 2021, the Medical Device Coordination Group (“MDCG”) issued a new guidance on classification of medical devices. The MDCG guidance sets out general principles for classification of medical devices under the MDR, but also recommendations with specific regard to medical device software. As a software provider, here are the main things that you need to know.

Recent trends and developments in software and smart devices have resulted in software offering more and more functionality related to personal health. In addition to heart rate monitors and pedometers, software is now available that enables its users to monitor their blood oxygen saturation, blood pressure, menstruation cycles and even their fertility.

While it may seem tempting for a software developer to take advantage of this ongoing health functionality trend, it is important to be aware of the implications associated with processing this type of health data. Even if only providing basic functionality, a software product created for the processing of health data may, from the perspective of the regulator, potentially be deemed a medical device.

Because of their impact on human life, medical devices are generally highly regulated, with strict requirements in terms of, for example, product safety being established with regard to making this type of device available on a market.

In 2017,  the EU adopted Regulation 2017/745, the Medical Devices Regulation (“MDR”). Although medical device software was previously regulated in the EU via the Medical Devices Directive, the MDR brings further clarifications with regard to the circumstances in which a software product is considered to be a medical device, and how such software should be handled from a regulatory point of view.

In order to harmonise the implementation of these complex rules, an expert committee – the Medical Device Coordination Group (“MDCG”) – has been tasked with issuing guidelines for their application.

An updated set of guidelines, MDCG 2021-24, containing information relevant to all providers of software concerning aspects related to health data, was just recently issued, in October 2021. In light of this, we address the two main issues for software providers in relation to the MDR and the new MDCG guidance, namely the qualification of software as medical devices, and the further classification of such medical device software; the rules that establish the basic framework of which every such software provider needs to possess basic knowledge.

Medical Device Software – Qualification under the MDR
In order for software to qualify within the scope of the MDR and be required to comply with the obligations set out therein, it is necessary that the software is deemed to constitute medical device software.

In respect of its application, the MDR is, on a high level and with a few exceptions, limited to devices that are intended to be used for medical purposes. Therefore, the determining factor for whether a software product is covered by the regulation, is the purpose for which it is to be used.

For the process of establishing the purpose of use for a software product, the principal factor to consider is the intended purpose as described by the manufacturer, for example, the instructions and terms and conditions established by the manufacturer with regard to the product. If on consultation of such terms and conditions, it is found that the product is intended to serve either of the following relevant purposes for the benefit of individual patients, it may generally be considered to qualify as medical device software.

• Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease or of an injury or disability,
• investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,
• control or support of conception.

It is, however, not necessary that the software is intended to be used alone or independently for one of these purposes for it to be considered medical device software. Instead, software products that have an intended medical purpose and that are components of medical devices may also, under certain conditions, fall within the scope of the regulation. Additionally, a software product that is intended to be used together with a medical device or to assist the functionality of a medical device in terms of its purpose may fall within the scope of the MDR, as constituting an accessory to a medical device.

The scope of the MDR is thus extensive, and a software provider must be aware of the basics of the regulation in order to not fall victim to unpleasant surprises. For application of the MDR, it is, as stated above, necessary that the there is a connection between the software and a particular medical purpose, and that the use of the software for this purpose is beneficial for individual patients. Taking this into consideration, not all software used to process health data, or even used within healthcare, will be considered as medical devices.

While the distinction between these software products might at first hand seem clear, the MDCG examples in the new guidance illustrate that the line between useful functionality and medical devices is, in view of the advances in software development, becoming increasingly blurred.

Determining the Rules Applicable to Medical Device Software – Classification
In view of the variety of medical purposes covered by the MDR, the spectrum of medical devices is extensive, and even medical device software falling within its scope fall within a multitude of different categories in respect of, for example, purpose and functionality. Such software may therefore have completely different risk profiles, and do not all require the same regulatory approach. Consequently, medical devices, including medical device software, are divided into different categories, in order to determine the level of control that is deemed necessary to assure the safety and effectiveness of a particular device.

Under the classification rules, a medical device can be categorised into one of four main classes, based on considerations of the intended purpose of the device and of its inherent risk. The different classes are I, IIa, IIb and III.

Specifically regarding medical device software, the application of the rules is inter alia based on the software’s independence from other devices, including the following principles.

• Software intended to be used in combination with another device will be classified separately from the other device,
• software driving or influencing the use of a device falls within the same class as that device,
• and software that is independent of any other device shall be classified in its own right.

Similar to the qualification procedure, the classification process is then mainly determined by the intended purpose of the device, for which the manufacturer’s terms and conditions should be consulted. In this respect, the MDCG regards several additional factors as relevant, such as the intended population and the context of use (for example, home use) for the software and the information provided by the software, as well as the possible decisions to be based on that information.

If as a result of the assessment of the relevant factors, it is deemed that several classification rules are applicable to the software, the guidelines and the MDR stipulate that the strictest rule shall apply, resulting in the higher classification.

In practice, the classification rules of the MDR and the principles that have been adopted by the MDCG in their guidelines therefore often result in software being categorised in class II, which in comparison to class I imposes additional preconditions for market introduction.

Taking into consideration the fact that the higher MDR classes thus entail stricter regulatory requirements, developers of software that processes health data should take a keen interest in keeping up to date with the current guidelines for application of the MDR, as such knowledge may reduce the risk of their product being erroneously placed in the wrong class.

Concluding Remarks
For manufacturers of software or smart devices, it is clear that the MDR requires a number of complex assessments that will need to be performed prior to the manufacturing and introduction of new products. In view of the fact that the MDR is gradually entering into force in the EU, it is high time that all providers of software that processes health data establish routines for these assessments in order to avoid any unpleasant surprises arising from their products being subject to the regulation as medical devices in high classifications.