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), the new European regulation for medical devices. It might have a significant impact on your product.
As of now, software is a medical device if the intended use falls into the scope of the current regulations of medical devices known as Medical Device Directive (MDD). The upcoming MDR brings changes in concepts, definitions and procedural requirements which affect all players in the medtech industry, particularly the medical device software manufacturers. Here are 10 facts you need to know about medical software:
1. The MDR is soon applicable – You need to be ready
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 will be applicable from 26 May 2020 onwards, and replacing the current Medical Device Directive (MDD). Switzerland is currently adjusting its laws to the development in the EU.
We use medical software as an umbrella term for software dedicated to improving the healthcare delivery process. Some examples of well-known medical 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 software might fall under the scope of this definition.
3. Changes mostly 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 current regulations. Standalone software is classified on 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, are no medical devices. 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, software as a medical device (SaMD) has often been classified as a class I product. Under the MDR, this will change drastically. Almost all software as a medical device 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.
7. Medical devices sold in the EEA and CH 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 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. Similarly, the process of getting CE-marked 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 (in CH: Swissmedic)
- 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.
Pictures: metamorworks, Dragon Images/Shutterstock.com