Guidance on the Classification of Medical Device Software (MDSW) for EU MDR

The MDSW is defined as a Medical Device regardless of its location of use. Software driving or influencing a medical device’s use can qualify as a device. Software intentionally to process, analyze, create or modify medical information will be considered medical device software if it has a medical intended purpose. Not all software used within healthcare will be qualified as a medical device as part of a system or accessory. For example, a patient appointment scheduling system could not qualify as medical device software as a system that would not be suitable for use in a patient’s appointment or due to the intended use of such software as patient app software, scheduling system software, etc.

As medical devices in Europe – A new regulatory regime ought to introduce.

The new EU Medical Device Regulation 2017/745 is meant to define the risk of software. The software will be considered medical device software under the new EU medical device regulation.

We now turn to the issues of risk classification of MDSW.

Medical device software (MDSWs) classification has significant consequences for manufacturers because the product life cycle reporting strongly depends on the risk factors.

Consequently, proposed changes in type are a leading cause of concern owing to up-classification.

For manufacturers, an exemplary approach to Rule 11 leads to situations where a previous class I device could now be class III, leading to a more significant overall clinical evaluation and compliance effort.

The characteristics of software that make the medical devices in the first place must fall under Class IIa or higher. The principal exception is software having no medically related purposes.

Since a vast majority of MDSWs deliver the information that will use for decisions with a diagnostic or therapeutic purpose, it is understandable that many of them will be starting in class IIa.

To illustrate, software monitoring physiological processes must perform diagnoses using image analyses for treatment decisions. Software with a diagnostic function supporting a lifestyle the path would warrant the highest classification.

An example of software cited might fall under Class I, a patient-facing conception-support app that calculates a user’s fertility status based on various inputs.

The Guidance implicitly states that a very narrow group of software devices could fall under Class I. For example, software that does not have a medical purpose and is not an accessory is under the EU Medical Device Regulation’s specific deeming rules.

Hypothetically, even if the software performs a relatively innocuous, medically related function. A device is class III if the resulting decision could result in death or irreversible deterioration. On a real note, though, very few decisions in the healthcare ecosystem would ever not result in death or irreversible decay in certain circumstances.

MDSW, IVDR, MDR, and the new guidance from the EU

EC’s Medical Device Coordination Group has issued new guidance on the EU’s new Medical Device Regulation. The new regulations will apply from 2020 and apply from 2022.

They show which software products will be classified as Medical Device Software (MDSW). It includes helpful flow diagrams and plenty of real-world examples, which will further assist developers in deciding where a product is likely to sit from a regulatory standpoint and launch software in the EU.

There are also welcome examples of that software that may not be considered MDSW, such as those developed in 2007.

Introducing the term “Medical Device Software” MDSW, the MDCG describes the two sub-types as

Independent MDSW providing information for diagnostic or therapeutic purposes:

• Rule 11 a) Software providing information for diagnostic or therapeutic purposes (classes IIa – III)
• Rule 11 b) Software monitoring physiological processes (classes IIa – IIb)
• Rule 11 c) all other Software (class I). MDSW driving or influencing the use of a hardware medical device. In this case, software must fall within the same class of device that it drives or influences.

What about fitness and wellness applications?

Fitness and well-being apps provide information on lifestyle, fitness, or well, but MDSW includes information for treating a disease or clinical condition.

MDR states that fitness and wellness applications are not fitness or wellness applications. Software intended for general purposes is not a medical device.

Software intended to be used in a health setting is not designed for use in such a way as a medical tool. Manufacturers could first place software on the market for general health purposes and use it to gather data on usability and generate evidence until it is sufficient to make a medical claim.

Software is designed to gain experience and generate data until the evidence is sufficient.

Some of the key points addressed in MDCG 2019-11 are:

A manufacturer must first establish the intended purpose to qualify as a medical device software and determine the risk class. The significant task is mainly to influence the product claims made by a manufacturer. For example, is the software used for direct diagnosis, interpretation, or simply reporting vitals captured?

Additionally, this depends on what the software intends to analyze

For example, the disease or condition needs a time-critical treatment, how fragile the population gets impacted, etc. However, the risk categorization does not necessarily clarify the difference between “diagnosis” and “support of diagnosis,” “screening” and “triage,” and so forth. The need for “fragile populations” is not clearly direct and could require additional information depending on the criticality in question.

• Software, which drives a device or influences the use of a device, shall fall within the same class as the device. However, notable exceptions depend on the intended purpose of the software. One exception is, for example, melanoma image analysis software to use with a near-infrared laser light scanner, considered a Class IIa device under Rule 10 of the MDR. It shows that since the tool enables cancer diagnosis, the software should be classified as Class III. Herein, Rule 11 could have a significant impact on many software manufacturers.
• If software influences the use of a device and does not perform a medical purpose on its own, it may be qualified as an accessory and falls under the MDR/IVDR.
• Notably, software fulfilling a medical purpose cannot be an accessory.
• The Guidance also re-emphasizes that when two or more classification rules apply to the same software, the highest of the possible classifications applies.
• Regarding software independent of other devices but not an accessory (e.g., medical or patient-facing apps). The key considerations will be whether the software does more than data storage, archival, communication, or simple searches and whether these actions are for individual patient benefit.

A New Life Cycle-Focus

EU Medical Device Directive 92/42/EEC aims to establish the responsibilities of medical device companies throughout the life cycle of the product.

The MDR deploys a product life cycle-focused approach to ensure compliance with the MDSW with MDR. According to the directive, detailed and partly enhanced requirements concerning quality management, risk management, clinical evaluation, and technical documentation must comply with post-market for the time the MDR is in service.

The new requirements are not new, but they aim to ensure compliance with after-market with the new regulations and the manufacturer sells the product.

Our Thoughts

The sophistication and complexity of new technologies have resulted in greater reliance on software by patients and healthcare professionals alike, perhaps leading to the authorities’ imposition of a higher level of scrutiny.

While some think this may deter the development of new software technologies. The Guidance document explains that these rules align the MDR with broader international guidance on software and advice from the International Medical Device Regulators Forum.

Under the current rules, it is possible to have a modular approach to software qualification only if there can be a proper separation in functionality.

Different levels of risk are posed by software that acts directly regarding a patient and software which informs a clinician’s diagnostic or treatment decision. Software that is not treating or diagnosing a condition has a clear pathway to potentially justifying a lower classification.

Since classification is primarily based on the severity of the risk, death or irreversible deterioration could occur. It would be sufficient to re-classify the software as Class III. Regardless of the actual risk of failure of the device, even if minimal or almost non-existent.

Thus, with an understanding that hardly any MDSW will remain as Class I under Rule 11. Manufacturers and Notified Bodies must be aware of and prepare for an increased workload.

A robust pre-and post-market data collection system, coupled with sound risk management and quality management plan, is thus essential for manufacturers to facilitate seamless dealings with Notified Bodies and Competent Authorities.

Concluding Remarks under the medical device regulation

Many Class I MDSW is up-classified under the MDR; developers need to prepare themselves to qualify for the transitional period and utilize it for good use.

Manufacturers should familiarize themselves with their obligations regarding vigilance, PMS, and registration; and be ready for full compliance from may 21,2021. Manufacturers should prepare for MDR certification on May 21, 2021. Only an on-time certification can ensure a smooth transition into the new (delayed) framework.

In the rare case that a device has EC-verification as set out in Annex IV to the MDD. The placing of devices on the market is valid until May 27, 2022 (Article 120 (2) MDR).

The deadline is now available for the electronic device manufacturer. At the end of the transitional period, the approval of competent authorities is mandatory.

Manufacturers should start collecting clinical data on their MDSW, set up a QMS, and draft a Clinical Evaluation plan.

Key takeaways for Software as a Medical Device Manufacturer

CiteMed will help you comply with regulatory requirements for MDSW. The medical device can help you compete with fast-paced innovation.

We’re happy to provide a unique team to help guide your medical device supplier to regulatory compliance. We’re happy to provide a unique team to help guide your medical device supplier to regulatory compliance.