Previously, we talked about how the FDA regulates Software as Medical Device (SaMD), in this blog post we will discuss the situation across the Atlantic, how EU regulates SaMD, especially AI-based software.
EU Classification for Software as a Medical Device
Similarly to the US, in Europe software with a medical purpose has historically been defined as a medical device. This was first communicated in 1993, when the European Commission published the Medical Device Directive (MDD) 93/42/EEC and subsequently the In Vitro Diagnostic Medical Device Directive (IVDD) 98/79/EC, with an aim to harmonize laws related to medical devices within the EU, and to facilitate market access in any of its countries.
The European Commission put in place a system of collaboration with independent private organizations called Notified Bodies (NB), known as the NANDO (New Approach Notified and Designated Organizations) System. Their responsibilities include the review of conformity and certification of medical devices to be made available in the EU. NBs are supervised by the National Competent Authority (NCA, governmental body) of the relevant EU Member State; a CA is ultimately responsible to grant marketing authorizations for devices in its territory and monitor compliance with the national laws and regulations, including applicable EU law.
The European MDD put in place a categorization system for general medical devices, according to 4 main categories based on their risk classification, where Class I is for low-risk devices and Class IIa, IIb and III represent a range of medium to high-risk devices.
- For the medium (IIa, IIb) and high-risk (III) devices, it is necessary to request a NB to review the conformity and provide certification of the device.
- As the MDD categorization did not incorporate specific regulatory requirements for medical device software, most independent software devices were classified as Class I at the time. Class I devices can be placed on the market by the manufacturers without a conformity assessment (so called “self-certification” process), as long as the products conform to medical device legislation and are added into registers maintained by the applicable NCAs.
At the same time, IVDD’s categorization system was different, focusing on four classes depending on risk level (List A, List B, Devices for Self-testing (not listed in Annex II) and General). Low risk in vitro diagnostic (IVD) devices were under the “General” class that did not require conformity assessment to be placed on the market. Significant and highest risks were under List A, B & Device for self-testing, and as with MDD, they required an assessment by a NB to be able to get CE-marked and place the device on the market.
This followed a considerable shift in mindset in 2017, with the publication of the EU Medical Device Regulation (MDR 2017/745) and In Vitro Medical Device Regulation (IVDR 2017/746), to replace the MDD and IVDD and with an initial implementation deadline in 2021 (MDR) and 2022 (IVDR) respectively; information on extensions to the deadline and conditions of those can be found on the EU Commission website. The MDR and IVDR include stricter regulatory requirements impacting medical device software in particular, due to changes in classification (so called “up-classification”).
Software considered as a medical device (MDSW – Medical Device Software) applies to any type of data processing software fulfilling the device definition in MDR and IVDR. It also applies to software used as an accessory in combination with, or incorporated into, a hardware medical device (including in vitro medical devices).
MDR Rule 11 (in Annex VIII) is of key importance, stating that if a digital technology qualifies as a medical device software, then it will essentially be classified as Class IIa or higher, allowing for a very small portion of products to still be classified as Class I compared to MDD.
Similarly, most software under IVDD would fall under “General” category and would now be considered higher risk based on the new classification system under IVDR that follows a more risk-based approach. All IVDR rules need to be considered to determine the proper classification of MDSW.
The Medical Device Coordination Group (MDCG) is an expert group, established by MDR and IVDR EU Regulations on medical devices. Its members are experts representing competent authorities of the EU countries. Stakeholders / European based associations can also participate in the meetings. The MDCG advises and assists the Commission and EU countries in the implementation of both Regulations. It deals with key issues from the medical devices sector, from Notified Body oversight or standardization to market surveillance, new technologies and clinical investigation. As a result, following the publication of the EU regulations on medical devices, several guidance documents have been created to assist manufacturers and regulatory bodies in implementing the regulations, including guidance on software. Refer to the MDCG dedicated guidance website for more information (MDCG guidance on new technologies).
The EU, via MDCG, also adapted IMDRF’s framework for risk categorization of SaMD to support manufacturers in identifying the correct classification of their general software medical device products in accordance with MDR (ref. MDCG 2019-11). This is summarized in Table 1, in context of the MDR, and is based on two main criteria:
- The significance of the information delivered by the medical device, i.e., does it treat/diagnose (high), drive clinical management (medium), or inform clinical management (low)?
- The state of healthcare situation or criticality of the patient condition i.e., is the patient in a critical, serious, or non-serious condition?
| State of healthcare situation or patient condition | The significance of Information provided by the Medical Device Software | ||
|
High |
Medium | Low | |
|
Critical |
Class III |
Class IIb | Class IIa |
| Serious | Class IIb | Class IIa |
Class IIa |
| Non-serious | Class IIa | Class IIa |
Class IIa |
Table 1. The European Commission classification of medical device software (MDSW), according to the MDR (EU) 2017/745 as clarified in MDCG 2019-11, annex III.
EU Documentation Requirements for Software Products
One of the key documents to prepare prior to approaching a NB for a CE conformity assessment is a checklist against the General Safety and Performance Requirements (GSPRs, highlighted in Annex I of MDR and IVDR). The checklist should contain a list of harmonized standards or standards representing the state-of-the-art in their area of application as well as references to evidence of compliance against those. Such standards focus on the company and its processes, the product (not software specific), and the software. A non-exhaustive list can be found in Table 2 below.
| Concerned Entity | Standard | Description |
| Company | EN ISO 13485 | Standard for a Quality Management System for the design and manufacture of medical devices |
| ISO 27001 | Information security, cybersecurity and privacy protection — Requirements related to Information Security Management Systems | |
| Product | EN ISO 14971 | Application of risk management to medical devices. Processes & terminology for risk management. |
| EN 62366-1 | Application of usability engineering to medical devices. | |
| EN ISO 14155 | Good Clinical Practice for clinical studies with medical devices | |
| ISO 20916 | In vitro diagnostic medical devices – Clinical performance studies using specimens from human subjects – Good study practice | |
| EN ISO 20417 | Information to be supplied by the manufacturer of medical devices | |
| EN ISO 15223-1 | Symbols to be used with information to be supplied by the manufacturer of medical devices | |
| Software | EN 82304-1 | Applies to safety and security of health software products intended to market without dedicated hardware. This covers the entire lifecycle i.e., design, development, validation, installation, maintenance and disposal |
| EN 62304 | Describes the set of processes, activities, and tasks to establish a common framework for medical device software life cycle processes |
Table 2. Key standards applicable for medical device software in the EU.
Using one of the above standards as an example, software device manufacturers must have a compliant Quality Management System (QMS) (corresponding to ISO 13485) to ensure proper quality, safety, and performance standards throughout the software product lifecycle. It is presented in a series of documents (Policies, Procedures, Work Instructions, Templates etc.) describing technical information that need to be prepared, reviewed, approved, and maintained, including software development, risk management, and clinical evaluation. It also contains supplementary information on required human resources, infrastructure, monitoring processes, data measurements and analysis, and necessary actions to be taken to rectify issues.
For a SaMD product to obtain market authorization, it is essential to prove safety and performance with documented data confirming the acceptability of the clinical benefit-risk ratio defined through risk management activities. A Clinical Evaluation Plan (CEP, per EU MDR) or Performance Evaluation Plan (PEP, per IVDR) must be constructed with defined objectives, strategy, and the type of evaluation required for the intended use of the device. The clinical data can be:
- Extracted from scientific literature or from reports published in peer reviewed scientific literature on other clinical experience of a software device for which equivalence to the device in question can be demonstrated (and thus not only “claimed”).
- Generated from clinical studies of the candidate software, subject to CE marking.
Actual requirements for clinical data generation for SaMD will depend upon key factors, included but not limited to:
| Factors | Valid Clinical Association (MDR)/ Scientific validity (IVDR) | Technical performance (MDR)/ Analytical performance (IVDR) | Clinical Performance (MDR/IVDR) |
| Definition | Means the association of a MDSW output (e.g. concept, conclusion, calculation) with a clinical condition or physiological state. | Capability of a MDSW to accurately and reliably generate the intended technical/analytical output from the input data | Article 2 of MDR: the ability of a device, resulting from any direct or indirect medical effects which stem from its technical or functional characteristics, including diagnostic characteristics, to achieve its intended purpose as claimed by the manufacturer, thereby leading to a clinical benefit for patients, when used as intended by the manufacturer.
Article 2 of IVDR: the ability of a device to yield results that are correlated with a particular clinical condition or a physiological or pathological process or state in accordance with the target population and intended user. |
| Description of supporting evidence | The valid clinical association/scientific validity of the intended purpose of a SaMD product is usually supported by a critical literature review, e.g. answering the question: “Is the scoring provided by my algorithm in the target medical indication clinically sound?”
This could also be supported by relevant information on the scientific validity of devices measuring the same analyte or marker; consensus expert opinions / positions from relevant professional associations and results from proof-of-concept studies. |
The predetermined analytical performance targeted for an SaMD (i.e. accuracy, repeatability, sensitivity/specificity, etc.) will often be established based on the use of representative validation datasets.
For example, such validation will confirm that an SaMD can detect reliably and accurately the color of a test strip compared to human observation, taking into account environmental factors. |
A clinical validation of the SaMD is anticipated to confirm that users can achieve clinically relevant outputs through predictable and reliable use of the MDSW.
The clinical validation of the SaMD will be characterized by (A) the targeted clinical performance metrics (e.g. 50% increase in efficiency of a given surgical procedure or clinical sensitivity (%) and specificity (%) of a molecular test for the determination of the malignant or benign status of nodules) and (B) its usability in a representative clinical setting (i.e. end users, environment of use). |
| Additional considerations | For highly disruptive SaMD, such a fundamental question may not be fully addressed in existing scientific publications and will thus have to be established by the SaMD manufacturer in the context of a dedicated clinical investigation/ performance study. | The targeted analytical performance may have to be confirmed in a clinically representative environment. | Clinical performance can be validated either through a retrospective clinical study e.g. validating prognosis score in Alzheimer’s or Parkinson’s disease, or a prospective one validating treatment safety/ efficiency.
It is important to evaluate not only the clinical sensitivity and specificity but also positive and negative predictive values, where medical condition prevalence is considered. These latter two values and the clinical study design are taken into account when establishing a reimbursement strategy. |
All this clinical information is then compiled into the Clinical Evaluation Report (CER, per MDR)/ Performance Evaluation Report (PER, per IVDR). Guidance on clinical evaluation of medical device software has been published by MDCG, under MDCG 2020-1.
Finally, it is required to include all the above information, along with software description, labels and instructions for use, in a Technical File for regulatory review by the NB. This is supported by a Post-Market Surveillance plan (PMS) to ensure correct collection and evaluation of data once the product becomes available on the market.
Upon completion of the aforementioned steps, the NB can begin the conformity assessment, most commonly through QMS audit and thorough review of the technical documents (dependent on conformity assessment route). Only once the NB concludes its assessment and supplies the manufacturer with their certificate, can the software be CE marked and released to the public. The SaMD will also need to be added to the EUDAMED public European database, with a unique identification number (UDI); guidance on UDI assignment to medical device software as well as additional information on this topic can be found under MDCG guidance grouped under “Unique Device Identifier (UDI).”
Post release, the NB will continue to perform regular audits including unannounced ones. In the case of AI-based software, PMS is ever more critical as it may be difficult to foresee the evolution of the product. Depending on the collected real-world performance data, a series of additional processes may need to be carried including Post-Market Clinical Follow-up (PMCF) or even a new conformity assessment.
Since Brexit, the UK began to take necessary measure to coordinate HealthTech product development independently. In the next blog post of this series, we will take particular look at the UK market, and more specifically how MHRA regulates SaMD, including AI.
Please refer to the links below for other blog posts of this series:
- Digital Health Series – Part 1: Defining Software as a Medical Device
- Digital Health Series – Part 2: Software as a Medical Device Regulated by the US FDA
Published on: October 31, 2023
