From 26 May 2021 (originally planned for 26 May 2020) onwards the Medical Device Regulation (MDR) will replace the current regulations of medical devices known as Medical Device Directive (MDD). Although this has a great impact on the definition and procedural requirements of all medical devices, it definitely brings about major changes for developers of software that is intended to be used for “medical purposes”. And it will effect developers of applications that did not think or refuse to believe that their software / algorithms serve a medical purpose.
Here are 8 key facts (among many other) you need to be aware of, that will and should have a significant impact on your development and go-to-market process.
First let’s start with the definition.
What is medical software?
Medical Software is used as an umbrella term for any software or system used within a medical context. It comprises:
- standalone software used for diagnostic, therapeutic or prognostic purposes
- software embedded in a medical device (often referred to as “medical device software”)
- software that drives a medical device or determines how it is used
- software that acts as an accessory to a medical device
- software used in the design, production, and testing of a medical device or
- software that provides quality control management of a medical device.
Medical software is to be found in:
- Clinic Information Systems (CIS – German: KIS, PIS), also Radiology Information Systems (RIS) and Laboratory Information Systems (LIS)
- Electronic Prescription (EP) Systems
- Clinical Decision Support Systems (CDSS)
Until now, it was often possible to classify and market medical device software (MDSW) as medical device – class I.
This will change with the MDR and not only encompass standalone and embedded software.
Under the new MDR, “software” is generally defined as a set of instructions that processes input data and creates output data.
Since going into detail would go beyond the scope of this post please find all related information in the official guidance here, page 5.
The good news
For the most part, software to track life-style and well-being is not affected.
Examples of software used in healthcare that may be still qualified as software and not medical device software (if not used with additional modules or processing medical data) are
- A software that helps with a “simple search”, that refers to the retrieval of records (by matching record meta-data against record search criteria) or to the retrieval of information (e.g. library functions)
- Software/Applications aiming at prevention (e.g. a physical therapy training app offering workout recommendations)
- Software/Applications supporting patients through providing information relevant to their medical condition serving as a coach to assist behavioral change or patient adherence (e.g. blood pressure coach, antibiotics coach).
The bad news
Rule 11: the new software-specific classification rule applicable under the MDR pushes devices into the higher risk-classes II (a,b) or III. It affects all medical software, especially stand-alone and embedded software.
It also brings about a new definition of software: all software that is intended to process, analyze, create or modify medical information may be qualified as Medical Device Software (MDSW) if the creation or modification of that information is governed by a medically-intended purpose”.
Find a detailed overview in Article 1(4) and Annex XVI of the applicable guidance.
To give medical software developers a short recap we have prepared eight points to generally consider when you are developing software for medical purposes.
This is not intedend to be a comprehensive list, but an easy to read and understandable source of information that shall entice you to further investigate the topic
MDR for medical software developers
1. Medical devices intended to be marketed in the EEA and CH need CE marking
Medical software that is considered a medical device under the scope of the MDR needs CE (conformité européenne) marking before it can be placed on the market in the European Economic Area (EEA) and Switzerland. Find more information here.
2. Getting CE-marked is based on the classification and risk class of a medical device
The MDR classification rules are based on the potential risk for human health and should take into account the potential risks associated with the technical design and manufacture of the devices.
A quick overview with regard to registration of a medical device:
- Class I: Medical device manufacturers can perform conformity assessments and apply CE marking under their authority. There is no obligation to inform their Notified Body (NB) or Competent Authority (in CH: Swissmedic)
- Class II (a,b) or III: Medical device manufacturers need to get their CE marking approved by a Notified Body . The NB carries out the device conformity assessment. It issues the CE marking certificate including a NB-specific 4-digit identification number.
For specific types of class I devices a Notified Body is required: for those that are sterile, those that are reusable, and most importantly for those that have a measuring function.
See MDR 2017/745 Annex VIII for more.
3. Guideline 2017/745 is now officially published
In October 2019 the EU published the article “Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR”.
It defines the criteria for the qualification of software falling within the scope of the new MDR and provides guidance on the application of classification criteria for software.
Additionally, it provides information related to placing the software on the market and putting it into service.
No surprise, just looking at the volume of this document, it will be harder for manufacturers to classify medical device software as class I.
With the new software-specific classification rule, devices are now being pushed into the higher risk classes II or III (Rule 11). And with that a whole set of new regulations apply.
This guideline ought to become compulsory reading for all involved in medical software development: you cannot read it often enough!
4. Classification according to Rule 11 (MDR) makes most medical software to medical devices
According to Rule 11 software which is intended to provide information that is used to make decisions with diagnosis or for therapeutic purposes is classified as class IIa, except if the impact of such decisions may cause:
a) death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or
b) a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb.
This greatly increases the complexity of handling the Technical Documentation requirements and complying with software standards such as the IEC 62304, for download here.
It also means having to undergo a Clinical Evaluation Program, resulting in a Clinical Evaluation Report (CER) followed by stringent post-market obligations.
5. Clinical Evaluation - Compliance to MEDDEV 2.7/1 Rev 4 and MDR 2017/745
Requirements for clinical evaluation have increased considerably since the release of the latest version of the Medical Device Directive (MEDDEV 2.7.1 Rev 4 in 2016) and the MDR 2017/745 in May 2017.
The clinical process, subject to big changes, now involves several steps; the main documents to be followed and submitted to the authorities are the Clinical Evaluation Plan (CEP) and the resulting Clinical Evaluation Report (CER).
Clinical evaluation must be conducted as per classification of the medical device software in compliance with the outlined rules above. Find more details here and here.
The life cycle of medical devices depicted below summarizes clinical evaluation and post-market obligations under the MDR.
Another important change to the old MDD is, that claiming equivalence to an existing device (and to utilize its clinical data as reference data) becomes nearly impossible. Manufacturers can only claim equivalence, if they can demonstrate to have unlimited access to the full technical documentation of the equivalent device.
6. Emphasis on post-market responsibilities
Expanded post-market activities, such as the implementation of a Post-Market Surveillance (PMS) system or Post-Market Clinical Follow-up (PMCF), need to be performed by medical device manufacturers and consequently, also by the concerned software manufactures. It will help to detect and address potential issues earlier and could reduce the manufacturer’s liability and hence protect patients.
Watch out: Eventually, Medical Devices will have to be registered with the European Database on Medical Devices (EUDAMED) with the goal to further post-market surveillance and traceability. It will also ensure that the public is adequately informed about devices placed on the market.
As all information needs to be updated regularly, make sure you plan for additional resources for increased performance and safety reporting.
7. Notified Bodies (NB) and Competent Authorities
Notified Bodies will have increased responsibility for the assessment and CE marking of medical devices. They will encounter heightened scrutiny from Competent Authorities. NB will also be required to consult with the European Commission on their clinical evaluation and post-market follow-up plans and that adds to the pressure that notified bodies will forward directly to the manufacturer.
Furthermore, the likelihood of an unannounced manufacturer and supplier audit will increase. Manufacturers need to provide audit schedules to national authorities upfront.
8. All medical devices need to be re-assessed for compliance and certification
With the new MDR, all medical devices, new and existing ones need to undergo conformity assessment to comply with the requirements set forth in the MDR. Existing devices and also medical software need to be re-assessed and re-certified in order to stay on the market. Transition periods (grace periods) exist.
Think purpose first
The MDR heavily impacts the way in which medical device manufacturers operate.
Registering a medical device and/or a medical software now requires a lot more resources to comply to the MDR, driving up costs and increasing time to market tremendously.
Therefore, it is absolutely imperative to do all your homework and be really clear on your medical software specifications. Work out your intended purpose before you start, as this will determine the requirements for the qualification and classification of your software.
Consider all development stages from the idea to the market before jumping into the development of a software intended to be used in medical settings.
Do not improvise as this may cause important delays and unexpected costs. And for “EVERYONE” who is already using applications that directly or indirectly monitor vital signs, e.g. in care facilities, check whether your product falls under the MDR (or not) and is legally safe.
Think: purpose first and consider getting MDR experts on board early!
* Please note that this post does not claim completeness and comes without guarantee. It is intended to create awareness and serves informational purposes only. By the time you read it – it may be October 2021. Make sure to stay informed as legislation and applicable law are constantly evolving.