CE Marking of Digital Health Technologies: Stricter Rules for Medical Device Software under the EU MDR

Introduction
Increasingly, the world is engaged in conversations surrounding mobile and digital health applications. These types of platforms – broadly defined – encompass everything from pedometers, fitness apps, exercise diaries and even products that monitor health conditions such as diabetes, heart disease and depression.

European manufacturers of such digital health technologies, medical applications and wearable body sensors as examples, must carefully consider the new rules and regulatory requirements set forth within the Medical Devices Regulation (MDR), adopted by the European Parliament and Council in May 2017. The new EU MDR, with a mandatory compliance date of 26 May 2020, replaces the former Medical Device Directive (MDD), and introduces new concepts, definitions, classification rules and procedural requirements for medical device software – and particularly for software products currently regulated as Class I medical devices in Europe. Many digital health technologies will now fall into the scope of the new European MDR.

Careful Examination of EU MDR for CE-Marked Digital Health Apps
Manufacturers of digital health applications must carefully examine new MDR requirements for CE-marked technologies prior to any type of commercial distribution to determine where they fall into the following definition of a ‘medical device’ under the new regulation:

Article 2: Definitions (abbreviated) 

 (1) ‘medical device’ means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:

• diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
• diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
• investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,

— providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations,

• and which does not achieve its principal intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its function by such means.

 The MDR adds new and specific medical device qualifiers not previously considered in the transitioning “Medical Device Directive MDD:M5 – Prediction and Prognosis of Disease.” These new definitions extend the already established concept of physiological data monitoring, and processing of physiology data, with advanced digital health care technologies capable of potentially predicting or providing a prognosis of potential future states of disease identification, an advanced concept of diagnostics. In principle, it affects all digital health apps and apps that have an intrinsic tendency to collect and evaluate data. This of course, includes wellness and well-being technologies, possibly including associated fitness platforms and wearable body sensors, as noted above.

However, the MDR has implemented a new classification rule for software that must be considered when applying the definition to general medical devices:

Annex VIII of the MDR: Section 6.3. Rule 11

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:

• death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or
• a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb.

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb.

All other software is classified as class I.

The new Rule 11 surprisingly does not mention or refer to the new terminology ‘prognosis and prediction.’  It is not known if this absence is a mere oversight, or if the concept of prevention and prognosis for a future disease state are embedded into the following definition: “Software to provide information … used to take decisions with diagnostic or therapeutic purposes.”

However, the underlying principle in the first paragraph of Annex VIII Rule 11 suggests that information that is used to make a diagnostic and/or therapeutic decision for a patient falls under this rule. This provision is understood as information that provides timely (i.e. immediate) – and in certain cases – near-future decision-making processes for a specific patient by a qualified health care professional. It does not suggest collecting patient data for the intended purpose of a prognosis and/or prediction of a future state of health for a patient.

The subsequent outlined risk class stratification follows the established principles of potential impacts and patient harm, and ranges from Class IIa to Class III if death or an irreversible health outcome is likely.

The second paragraph starting with Software intended to monitor physiological processes appears to be less novel as compared to the current MDD:M5 Annex IX Rule 10, third indent, providing the same principle and wording.

Medical Software is an Active Device

In close analogy to the MDD:M5, the MDR2017/745 defines Software as active medical devices.

Article 2: Definitions

(4) ‘active device’ means any device, the operation of which depends on a source of energy other than that generated by the human body for that purpose, or by gravity, and which acts by changing the density of or converting that energy. Devices intended to transmit energy, substances or other elements between an active device and the patient, without any significant change, shall not be deemed to be active devices. Software shall also be deemed to be an active device.

The above definition suggests that medical device software is always connected with its dependent hardware platform(s), including physical interface(s) for information exchange.  As hardware/software needs energy in the form of electricity in order function, the hardware is subject to the medical device approval process for digital healthcare apps. This concept of ‘software as an active medical device’ is outlined in many references in the MDR. The below is not an all-inclusive selection of these references, but provides information on requirements.

Annex VIII: Classification Rules 

Chapter II: Implementing Rules

3.3. 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.

Annex II: Technical Documentation 

6. Product Verification and Validation

6.1. Pre-clinical and

(b) detailed information regarding test design, complete test or study protocols, methods of data analysis, in addition to data summaries and test conclusions regarding in particular:

• the biocompatibility of the device including the identification of all materials in direct or indirect contact with the patient or;
• physical, chemical and microbiological characterization;
• electrical safety and electromagnetic compatibility;
• software verification and validation (describing the software design and development process and evidence of the validation of the software, as used in the finished device. This information shall typically include the summary results of all verification, validation and testing performed both in-house and in a simulated or environment prior to final release. It shall also address all of the different hardware configurations and, where applicable, operating system identified in the information supplied by;
• stability, including shelf life; and
• performance and safety.

This is a rather traditional understanding of medical device software as an active device, requiring verification and validation activities as used in a finished device e.g. embedded in dedicated hardware-based medical devices with a strong focus around physical harm, transmission of energy and/or transfer of substances to or from the body.

This understanding does not take into account that medical device software often performs to its intended medical purpose independent of a dedicated hardware platform. These types of devices are increasingly deployed on general-purpose hardware and delivered in diverse care settings on a multitude of technology platforms (e.g., personal computers, smart phones, and in the cloud) that are easily accessible. Additionally, these applications are increasingly interconnected to other systems and datasets via networks, Internet and other cloud-based platforms.

The complexity of medical device software, together with the increasing connectedness of systems, results in emergent behaviors not usually observed in medical device hardware.

So what happened to the terms ‘prognosis’ and ‘prediction’ in MDR Article 2: Section 1?

Does the lack of further clarification in the MDR suggest that advanced digital software algorithms and self-learning neuronal networks that predict or provide a form of prognosis of a future state of health from a collective of patient data are Class I Medical Software Devices? Unfortunately, Rule 11 is rather vague in this regard and the EU Commission and its many working groups may want to provide clarification and harmonization with other concurring regulatory frameworks.

What does this mean for digital wellness and fitness apps?

The MDR provides a clear definition in Article 1: Subject matter and scope: 

(19) It is necessary to clarify that software in its own right, when specifically intended by the  to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not.

The qualification of software, either as a device or an accessory, is independent of the software’s location or the type of interconnection between the software and a device.

Above Paragraph (19) clearly exempts general-purpose software without a medical purpose as defined in Article (1), as well as fitness and wellness apps, from being regulated as medical devices.

Paragraph (19) reconfirms that the intended medical purpose of digital health apps and wearable body sensors, and not their technological features and advanced capabilities, are the primary qualifier (MDR Article (1)) to determine if software is regulated under the incoming EU MDR.

Software considered a Medical Device	Software not considered a Medical Device
Intended Purpose for diagnostic purposes	Intended for Documentation Purposes Only
Intended Purpose for therapeutic purposes	Intended  For Research and Education
Monitoring of physiological processes	Not specifically intended for a medical purpose

For all medical devices, the MDD:M5 as amended provides that the product cannot be marketed in the EU unless a CE mark has been validly affixed to it in accordance with the provisions of the applicable EU legislation. This is equally true for the EU-MDR. However, it is important to note that the transition (grace) period set forth in Article 120 of the EU MDR for legacy medical devices, including software with medical purposes, does not apply for MDD:M5 Class I devices that are up-classified into Class IIa under the MDR. There is simply no MDD Certificate that can be leveraged for this grace period; in order to do so, a valid CE-Mark Certificate issued by a Notified Body must be in place to be eligible the MDR grace period.

In addition, all legal manufacturers of digital health technologies must consider the implications of the General Data Protection Regulation (GDPR), which will apply in the EU from 25 May 2018, and will replace the current EU Data Protection Directive. The GDPR will introduce new EU data protection requirements with increasing responsibility and liability of entities processing personal data, including personal health data of individuals in the EU, including through use of software.

How can NAMSA Help?
Manufacturers of digital health applications must carefully examine new MDR requirements for CE-marked technologies prior to commercial distribution to determine where they may fall into the definition of ‘medical device’ within the new EU regulation. This is critical in order to be meet the mandatory compliance date of 26 May 2020 for software products currently regulated as Class I medical devices.

NAMSA’s global regulatory experts welcome the opportunity to discuss with you the potential impact of the EU’s MDR on your medical device technology, and more importantly, the steps your organization can take to streamline preparedness activities.

Please contact us at communications@namsa.com, or visit our regulatory consulting webpage here to learn how we can assist your medical device organization with achieving success under the latest regulatory EU landscape.

References

• REGULATION GUIDELINE (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC
• “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations – IMDRF Software as a Medical Device (SaMD) Working Group (18 September 2014)