How will Europe’s new device regulations affect medical software?

I

n order to allow the European medtech industry room to focus on the Covid-19 crisis, the EU’s new Medical Device Regulation (MDR), originally due to come into place on 26 May 2020, was delayed until 26 May this year.

Designed as an update to the Medical Devices Directive (MDD) for 1993, MDR has a more lifecycle-focused regulatory approach, where MDD concentrated heavily on device approval.

The regulations also mean big changes for medical device software (MDSW) developers, leaving them facing a significantly stricter regulatory framework than they have historically been used to.

International law firm Morrison & Foerster partner Dr Wolfgang Schönig says: “I think there are three key changes when it comes to MDSW.

“One, it is likely that more apps will be governed by the revised regulation, because the scope has been broadened to cover both prediction and prognosis applications, whereas previously it was only prevention. This might result in a larger number of software solutions falling within the scope of the MDR.

“Two, it’s now very likely that most of the applications that are out there will be classified class 2a or higher and that will bring about a few additional requirements for the providers of these applications.

“Three, regardless of whether you are class 1 or higher, MDR is imposing additional quality assurance and documentation requirements that will be applied to everyone, even those who may be lucky enough to remain in class 1.

The MDR is now imposing ongoing digital vigilance requirements, post-market surveillance requirements, you have to monitor what’s going on out there in the market with respect to your product. It’s a significant additional administrative burden for software companies.”

Here, we round up some of the biggest changes coming into play.

Under MDD, the purpose of a software product and its intended use has a significant role to play in how the device is categorised.

“It heavily depends on how you advertise your solution,” says Schönig. “If you make any claims around medical use of health-related qualities of the service, you must comply with MDR.

“What is out of MDR are things like pure patient education platforms, video consultation or data transmission – even if data about my heart rate is being transmitted to my physician, that does not make the device doing the transmitting a medical device.”

Companies have control over whether or not they fall under MDR, by carefully checking what they’re saying about their product. For example, a wellness-focused app that helps a user track their exercise, fitness and general health does not have a medical purpose.

However, a similar platform that encourages them to track these metrics in order to help manage a chronic illness like diabetes would be classed as a medical device and would thus be subject to MDR.

However, MDR has broadened the definition of a medical device, meaning some MDSW platforms that weren’t subject to MDD are subject to MDR.

Under MDD, platforms need to seek CE certification when they could impact diagnosis, prevention, monitoring, treatment, or alleviation of disease. Under MDR, prediction and prognosis are added to this list too.

This addition is particularly significant when looking at the various Covid-19 apps which have emerged across Europe, which often make a prognosis with regard to the user’s chances of having the disease.

In the EU, medical devices are categorised into four risk types, from lowest-risk to highest-risk: Class I, Class IIa, Class IIb and Class III. These classes determine which procedures are required to obtain CE marking, ranging from straightforward self-certification for Class I to a full review by a notified body (NB) for Class III.

“Risk class has a big impact on what you need to provide in terms of documentation and how much you need to involve notified bodies and other third parties to get your product certified so that you can lawfully market it,” says Schönig.

Under MDD, many standalone MDSW programmes, such as artificially intelligent mobile apps that allow users to take pictures of moles on their skin to see if they might be cancerous, are classified as Class I devices. Under MDR, this all changes.

Devices which provide information that could inform therapeutic or diagnostic decisions will now be in Class IIa or higher, depending on the severity of the condition in question.

Schönig says: “What everybody is looking at now is whether they’re still in class one, or if their service is providing information that is used for diagnostic or therapeutic practice.”

This doesn’t completely eliminate the room for Class I categorisation of MDSW. An app that uses an algorithm to process user data and calculate where they are in the menstrual cycle, for example, can still find a place in Class I, as the platform isn’t explicitly user to make diagnostic or therapeutic decisions.

While MDD focused primarily on the pre-approval stage of a medical device and the steps a manufacturer needed to take to obtain CE marking, MDR focuses on the entire lifecycle of a product.

As a result, quality assurance and documentation requirements for MDSW have become significantly more stringent.

Schönig says: “It’s not only the lifecycle in terms of a product being out on the market and what is happening with it. The entire supply chain is now subject to much more scrutiny and regulation requires that manufacturers ensure that suppliers are also compliant.

“Companies will have to constantly update information on their product, and any change to the product will require recertification. There are also pretty strict rules on incident reporting so that NBs can assess if a case is just a one-off or a substantial problem.”

Due to the lifecycle focus of MDR, a Unique Device Identification (UDI) system is in the process of being established. The UDI is designed to make identifying specific medical devices easier and make them more traceable on the market, comprising of a device identifier (UDI-DI) specific to manufacturer and device and a production identifier (UDI-PI) identifying the unit of production.

“UDI is a function of this entire lifecycle approach,” says Schönig. “Each product now needs a unique identifier so that we can now trace back. If there is a problem with a software application, we need to know who the producer is, which batch or product number we are talking about.”

UDI-DI will be required of MDSW. It has been required of high-risk devices in Class III since 26 May 2021, but for the rest of the industry it’s not as urgent. Class IIa and IIb devices aren’t due until 26 May 2023, while Class I devices will not need to comply until 26 May 2025.

Schönig says: “It’s just an additional layer of transparency in the market, so that we can trace back if there is an incident. The grace periods here are pretty generous. While the EU is still setting up a general database for UDI, it doesn’t exist just yet. It’s not an urgent issue.”