Regulatory Focus™ > News Articles > 2021 > 1 > Medical device software under the EU MDR

Medical device software under the EU MDR

Posted 11 January 2021 | By Leo Hovestadt, MSc  | PDF Link PDF | ©

Medical device software under the EU MDR

The EU Medical Device Regulation (MDR) has been published with new medical device software (MDSW) requirements. Qualification guidance to determine if software is MDSW was combined with guidance for MDSW classification. However, the EU Medical Device Directive (MDD) guidance for clinical evaluation, which should have been replaced, is still in use. The change to the MDR has introduced new problems for clinical evaluation, so guidance has been introduced for equivalence, legacy devices, and the clinical evaluation assessment report (CEAR) of the notified body and for the clinical evaluation of MDSW.
Manufacturers who think their software as a medical device (SaMD) technical file will satisfy the MDR1 are in for a surprise. Approaches to MDSW under the MDR differ significantly from other regulations and are, in general, more strict.
For instance, an MDSW can be part of a hardware device, which is driven or influenced by the software, and in that case, the MDSW gets the highest classification of either the hardware or the MDSW. SaMD is standalone software and thus cannot contain hardware in the way MDR MDSW can. The MDR guidance contains a step called Qualification to determine whether software is MDSW. There is no such step for SaMD. MDSW is often confused with SaMD, resulting in the MDSW being assigned an incorrect, lower classification.
The implications of an incorrect classification can be significant. For example, skin cancer apps for early detection of melanoma and other types of skin cancer were gaining popularity during the development of the MDR. To address concerns about software in these apps and similar products, the MDR Rule 11 was developed. However, the rule was not sufficiently comprehensive, with the result that some apps received a higher classification than warranted, at times as high as class III. As a result, many devices that were safely on the market for a long time with an MDD or active implantable MDD CE-marked device had to do clinical investigations before market release under the MDR because of the class III classification.
It took a long time to develop guidance with a reasonable approach for Rule 11, which met the new regulations in the MDR. The new Medical Device Coordination Group (MDCG) guidance for the qualification and classification of MDSW2 software solved the problem but was very complex. Many consultants tried to explain the MDR by using their experience with the MDD,3 Medical Devices Documents (MEDDEV,4 or International Medical Device Regulators Forum (IMDRF)5 guidance, but they created confusion. The new guidance for MDSW has many new requirement for qualification,2 classification,2 clinical evaluation,6-10 and cybersecurity.11,12 It is important for MDSW manufacturers who want to place their devices on the EU market to carefully read all new guidance on MDSW.
Qualification is the activity that determines whether MDSW is covered under the MDR. The qualification method is mentioned in guidance MDCG 2019-11.2 Examples of qualification will be given in future MDCG guidance on borderline and classifications, which is currently being developed.
It is most important that the guidance’s qualification workflow is followed (Figure 1).
From the flow depicted in Figure 1, we can see that software accessories at step 2a or software driving or influencing a medical device at step 2b are covered by the MDR. Accessories are classified in their own right according to implementing Rule 3.2, and software driving or influencing a medical device are classified together with the medical device according to MDR Annex VIII implementing Rule 3.3. So at step 2a, Rule 11 has to be applied, and via step 2b, Rule 11 does not have to be applied, which can be a significant difference.
In step 5, there is a check to ensure that the software’s intended purpose meets the definition of a medical device under MDR Article 2 definition (Step 1), making it MDSW.
Classification according to MDR Annex VIII and MDCG 2019-112 is the activity that determines the risk class of a medical device. The classification rules are mentioned in MDR Annex VIII and guidance MDCG 2019-11 on classification. The risk class indicates what is required to obtain the Conformité Européenne (CE) certification of the MDR. (The CE mark indicates the manufacturer takes responsibility for the product’s compliance with EU requirements.) The classification rules for active devices apply for MDSW, because software under the MDR is an active device. All applicable classification rules have to be applied, and the rule with the highest classification determines the final classification of the device.
MDR Annex VIII, Rule 11 most often gives the highest classification. Not reading the guidance, however, again comes at a high price, as shown in the Table.
The text of Rule 11 is repeated in this table. For example, according to  Rule 11, all MDSW treating or diagnosing cancer (which is critical) is class III. However, under the MDD, in general, this is class IIb or lower, and sometimes even class I.
To avoid being assigned a classification that is too high, one should use the guidance MDCG 2019-11 and MDR Annex VIII implementation Rule 3.3. The MDCG 2019-11 guidance is based on the IMDRF SaMD working group’s N125 guidance, which is the source for Table 1. The IMDRF guidance recognizes that most software has an indirect influence on treatment or diagnosis and that therefore, the classification should be lower. So software that drives clinical management (see the middle column in the table) or software that informs clinical management (right column), should have a lower risk class. An example coming from the IMDRF guidance is radiation therapy treatment planning. This software is driving clinical management of radiation treatment delivery for cancer, which is critical. Applying MDCG 2019-11 puts this software in the middle column in the top row, and thus the classification is class IIb. It should be noted that the IMDRF SaMD working group’s N12 document5 contains a mistake, which is explained in the note from MDCG 2019-11 Annex III. (The N12 document mistakes are in 7.3 Criteria for Category II for i and iii; 7.4 Category III for i and ii examples.)
In Table 1, the software in the left column is often part of treating and diagnosing hardware. Here, implementing Rule 3.3a is important. It says that software driving a medical device or influencing the use of a medical device, should fall within the same class as the medical device, avoiding the problem of Rule 11 for hardware containing software.
MEDDEV 2.7.1 rev 4 clinical evaluation
The MEDDEV 2.7.1 rev 4 clinical evaluation6 guidance was written for the MDD, the predecessor of the MDR. This guidance was not written with MDSW in mind. Notified bodies expect that clinical evaluation follows this guidance closely, in combination with the MDR requirements. The notified body uses the CEAR template7 for this review. The manufacturer is well advised to study the CEAR in detail, which can be found in the MDCG 2020-10/1 CEAR template.7
The MEDDEV clinical evaluation guidance is currently the best that is available, until it is upgraded to the MDR. The most important gaps for MDR requirements in the MEDDEV clinical evaluation include the following omissions:
  • No references to the MDR, such as articles, annexes, and general safety and performance requirements (GSPR) sections.
  • No discussion about MDR Article 61(10) that technical data can replace clinical data under certain conditions.
  • Missing MDR requirements for:
              - Clinical evaluation plan ‒ Identifying GSPRs requiring (clinical) data and defining which level of clinical evidence is required;
              - Clinical investigation for class IIb implantables, and class III devices;
              - Postmarket surveillance plan, postmarket clinical follow-up plan, and clinical development plan;
              - Common specifications;
              - Stricter requirements for clinical data; and
              - Qualified assessment of sufficient level of clinical evidence.
Clinical evidence
Clinical evidence, according to the MDR, has to be based on a very strict definition of clinical data from an original or equivalent device, with clinical data coming mainly from clinical investigations. In addition, the quality of the available postmarket surveillance clinical data not considered good enough. This was problematic for a lot of medical devices with “sufficient clinical evidence” but where the clinical data did not meet the MDR requirements or the expectations of the reviewers. It was especially problematic for MDSW. Three guidance documents were developed to circumvent the problems:
  • MDCG 2020-6 guidance on sufficient clinical evidence for legacy devices.8 This guidance is not specific for MDSW but is helpful for the transfer of clinical evidence from the MDD to the MDR. In addition, Appendix III shows a useful overview of clinical evidence sources.
  • MDCG 2020-5 guidance on clinical evaluation.9 This guidance provides an additional and more realistic explanation of software equivalency.
  • MDCG 2020-1 guidance on clinical (MDR) or performance (IVDR) evaluation of medical device software.10 This guidance fills the gaps for MDSW clinical evaluation and explains how to create clinical evidence. The guidance requires clinical evidence for technical performance (for tool-based MDSW without direct clinical benefits) and, where applicable, clinical evidence for a valid clinic association and for clinical performance.
Clinical evaluation is required, according to the MDR Article 61(1), so this has to be created in addition to MDSW clinical evaluation. However, there is no explanation anywhere for how the two clinical evaluations should be combined. Figure 2 outlines a way this can be done.
In Figure 2, both clinical evaluations require that acceptance criteria have to be based on state-of-the-art, current practice of medicine (see left column). Clinical data has to be collected, appraised, and analysed (middle column). For MDR Article 61(1), clinical evaluation has to be based on clinical data from the device to be released or from an equivalent device. That restriction does not apply to MDSW clinical evaluation, which can use more data sources. Based on MDR Article 61(10), justifications can be written when there is MDSW clinical evidence in addition to MDR Article 61(1) clinical evidence, so that there is sufficient clinical evidence. Article 61(10) cannot be used for class III MDSW.
For MDSW clinical evaluations, for example, curated clinical data can be used from real-world data sources. The data still has to be appraised to guarantee its quality and applicability for the evaluated MDSW. Finally, the clinical evidence has to be assessed (right column). The assessment uses the acceptance criteria from the first box. Article 61(1) requires clinical evidence for safety (including for no unacceptable side-effects), clinical performance, and a positive benefit-risk ratio. For the MDSW, clinical evidence for a valid clinical association, technical, and clinical performance is required.
Cybersecurity guidance
The MDR contains a limited set of cybersecurity requirements, such as MDR Annex I: 14.2.(d), 17.2, 17.4, 18.8, and 23.4ab. When the MDR came into effect in May 2017, the WannaCry ransomware attacked hospitals around the world. In response to that event, MDCG 2019-16 guidance on cybersecurity11 was immediately developed to protect MDSW against cyberattacks. New releases of this guidance are expected soon, along with other requirements for cybersecurity patches.
This guidance also contains the manufacturer’s cybersecurity requirements to inform the hospital asset owner and system integrator how the MDSW can be protected. The manufacturer’s disclosure statement, or the Medical Device Security (MDS2) form, was developed for this purpose and is used to exchange essential cybersecurity information between the manufacturer and the hospital. If the MDSW handles patient data, then the General Data Protection Regulation,12 which requires the patient data to be protected, also applies.
The MDCG guidance for the MDR should be studied carefully because it contains solutions for problems and additional requirements for acquiring the MDR CE mark. The guidance related to clinical evaluation of MDSW, equivalence, legacy devices, and the CEAR contains solutions for performing clinical evaluation. The guidance for MDSW qualification and classification has a section on classification Rule 11. Applying the guidance for Rule 11 often avoids a higher risk classification. The cybersecurity guidance contains requirements that cannot be found in the MDR.

CE, Conformité Européenne; CEAR, clinical evaluation assessment report; IMDRF, International Medical Device Regulators Forum; MDD, Medical Device Directive; MDCG, Medical Device Coordination Group; MDR, [EU] Medical Device Regulation; MDSW, medical device software; MEDDEV, Medical Devices Documents; SaMD, software as a medical device.
  1. European Commission. EUR-Lex website. Regulation (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. Current as of 24 April 2020. Accessed 8 December 2020.
  2. European Commission. MDCG 2019-11 – Guidance on qualification and classification of software in Regulation (EU) 2017/745-MDR and Regulation (EU) 2017/746-IVDR. Dated October 2019. Accessed 8 December 2020
  3. EUR-Lex website. Council directive 93/42/EEC of 14 June 1993 concerning medical devices. Accessed 8 December 2020.
  4. European Commission. MEDDEV 2.1/6 – Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices. Dated July 2016. Accessed 8 December 2020.
  5. International Medical Device Regulators Forum. IMDRF SaMD working group (N12). Software as a medical device: Possible framework for risk categorization and corresponding considerations. Dated 18 September 2014. Accessed 8 December 2020.
  6. European Commission. Clinical evaluation: A guide for manufacturers and notified bodies under Directives 93/42/EEC and 90/385/EEC. MEDDEV 2.7/1 revision 4. Dated June 2016. Accessed 8 December 2020.
  7. European Commission. MDCG 2020-13 – Clinical evaluation assessment report template. Dated July 2020. Accessed 8 December 2020.
  8. European Commission. MDCG 2020-6 – Regulation (EU) 2017/745: Clinical evidence needed for medical devices previously CE marked under Directives 93/42/EEC or 90/385/EEC. Dated April 2020. Accessed 8 December 2020.
  9. European Commission. MDCG 2020-5 – Clinical evaluation – Equivalence. Dated April 2020. Accessed 8 December 2020.
  10. European Commission. MDCG 2020-1 – Guidance on clinical evaluation (MDR)/ performance evaluation (IVDR) of medical device software. Dated March 2020. Acessed 8 December 2020.
  11. European Commission. MDCG 2019-16 rev.1 – Guidance on cybersecurity for medical devices. Dated July 2020. Accessed 8 December 2020.
  12. EUR-Lex website. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). Accessed 8 December 2020.
About the author
Leo JC Hovestadt, MSc, is responsible for EU governmental affairs at Elekta, a radiation therapy company based in The Netherlands. He is involved in European and international work groups for writing guidance on clinical evaluation and investigation. Hovestadt has more than 25 years of experience with high-risk medical devices at Elekta and Medtronic. He can be contacted at
Citation Hovestadt LJC. Medical device software under the EU Medical Device Regulation. Regulatory Focus. January 2021. Regulatory Affairs Professionals Society.
©2021 Regulatory Affairs Professionals Society


© 2022 Regulatory Affairs Professionals Society.


Regulatory Focus newsletters

All the biggest regulatory news and happenings.