10 facts you need to know about the MDR as a medical software manufacturer

Do you develop software that is used for medical purposes? Is this software part of a clinical information system (CIS)? If so, you should already know about the Medical Device Regulation (MDR) in the EU. Learn about the most important changes to software as a medical device (SaMD) here.

Software is a medical device if the intended use falls into the scope of the Medical Device Regulation (MDR). The MDR brings changes in concepts, definitions and procedural requirements that affect all players in the medtech industry, particularly the manufacturers of medical device software.

As a medical software manufacturer, here are the 10 facts you need to know about the MDR.

Content:

1. The MDR provides transition periods for certain devices – but you need to be compliant with its provisions already

After many years of discussion, the European Parliament and Council adopted the Medical Device Regulation (MDR) in May 2017. The MDR regulates the required steps until a medical device for human use can be placed on the market, as well as the following post-market actions. It is applicable since 26 May 2021, and replaces the Medical Device Directive (MDD). We use medical device software as an umbrella term for software dedicated to improving the healthcare delivery process; the MDCG introduced the term Medical Device Software (MDSW) in its Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR.  Some examples of well-known medical device software are as follows:

  • Clinic Information System (CIS)
  • Electronic Prescription (EP) System
  • Clinical Decision Support Systems (CDSS)
  • Radiology Information Systems (RIS)
  • Laboratory Information System (LIS)

In the German-speaking region, the terms Klinikinformationssystem (KIS) and Praxis-Informationssystem (PIS) are often used.

2. The definition of a medical device is extended

The MDR introduces a small extension of the definition of a medical device. Medical devices include devices with the specific medical purpose of prediction and prognosis of a disease. Additional medical device software might fall under the scope of this definition.

3. Changes mainly apply for standalone software

Software can be classified as standalone and embedded. The latter is software integrated into medical devices, such as the software in a blood pressure monitor or an MRI scanner. Standalone software is independent of any other device but might influence the use of other devices or could be used in combination with other devices, such as an electronic prescription software or a CDSS.

For example, a CDSS (standalone software) issues an alarm when incoming data from an ECG monitor (embedded software) fulfills certain patient-specific rules.

The implementation of the MDR does not introduce relevant changes in the regulation of embedded software. In contrast, standalone medical software products are affected by changes in the classification rules in the MDR compared to the previous regulations. Standalone software is classified in its own right.

4. Don’t panic, not everything changes

Note that despite the introduction of changes, many basic rules remain the same.

  • An Electronic Patient Record (EPR) system, which only replaces the paper files, would still not be considered a medical device.
  • A Picture Archiving and Communication System (PACS), which only shows and saves pictures, would still not be considered a medical device.
  • A PACS, which allows informing further treatments like radiation therapy, picture manipulation, or includes a function to compare pictures in order to specify the progression of a disease, is most likely considered a medical device.

5. Software for life-style and well-being purposes are no medical devices

Software for general purposes, even when used in the healthcare setting, is not considered a medical device. The manufacturer specifies the intended use.

6. New classification rule for medical software

A new rigid, software-specific classification rule pushes devices into the higher risk classes II or III (Rule 11). To date, medical device software (MDSW) has often been classified as a class I product. Under the MDR, this changes drastically. As a result, almost all medical device software will be up-classified into higher risk classes.

Rule 11 (MDR):
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.

To give an example of a potential up-classification: A diagnostic image analysis software provides information on whether an acute stroke is haemorrhagic or ischemic. The corresponding treatments are fundamentally different, and their correct use is crucial for the survival and future health status of the patient. As the software is used to make decisions with therapeutic purposes that may prevent or cause death, it is likely to be classified as a class III device.

 

changes to medical software under MDR

Medical device software that falls under the scope of the MDR is considered a medical device and needs CE marking.

7. Medical devices sold in the EEA need CE marking

Medical devices need a CE (conformité européenne) marking in order to be placed on the market in the European Economic Area (EEA) and Switzerland. More on the basics of CE marking in the EU can be found here. Medical device software that falls under the scope of the MDR is considered a medical device and needs CE marking.

8. Different ways to get CE marking depending on the risk class

The specifications to get CE marking for a medical device depend on its risk class. The higher the risk class, the more requirements a product must conform to in order to get CE marking. In other words, the process of obtaining a CE mark is based on the risk class of a medical device:

  • Class I: Medical device manufacturers can perform conformity assessment and apply CE marking on their own. They need to notify their national competent authority.
  • Class II or III: Medical device manufacturers need to get their CE marking approved by a Notified Body (NB). Instead of self-assessment, the NB assesses the device conformity and approves the CE marking with the NB-specific 4-digit identification number.

9. Increased post-market responsibilities

Expanded post-market activities, such as the implementation of a post-market surveillance system, need to be performed by medical device manufacturers.

10. EUDAMED introduces additional requirements

A European database on medical devices (EUDAMED) will be introduced in order to strengthen the market surveillance and ease traceability, as well as to ensure that the public is adequately informed about devices placed on the market. Before placing a device on the market, the manufacturer shall enter the information referred to in Section 2 of Part A of Annex VI and keep the information updated.

How Decomplix can help

Decomplix provides assistance in each step of the medical CE certification process for product manufacturers, including medical software. You can learn more about our services here.

(last updated in November 2021)

 

Pictures: metamorworks, Dragon Images/Shutterstock.com

More articles