Software whose application serves a medical purpose is legally a medical device. The marketing of a medical device is strictly regulated in Europe. For the manufacturer of the software this results in a high effort and considerable liability risks. Therefore, the manufacturer should clarify as early as possible whether a software is a medical device at all and - if so - to which risk class it belongs. This technical article provides an overview of the path of a software to a medical device with CE marking.
Which legal regulations apply to software as a medical device?
If manufacturers want to market software with a medical purpose in Europe, they must comply with the European Medical Devices Regulation (EU) 2017/745 (MDR) from May 26, 2021 (effective date) or the In Vitro Diagnostics Regulation (EU) 2017/746 (IVDR) from May 26, 2022 (effective date). EU Regulation 2023/607 amended the transition periods for the placing on the market and putting into service of legacy devices under the old MDD and AIMDD directives in Art. 120 (3) MDR. Under certain conditions this is possible until 31.12.2028 and 31.12.2027. More detailed explanations can be found in the DOkument MDCG 2020-3 from the Medical Device Coordination Group.
Furthermore, the provisions of the European General Data Protection Regulation 2016/679 (DSGVO) must be observed.
Future legal acts such as the European Artificial Intelligence Act (AIA) may also further increase the existing requirements.
When is software considered a medical device?
At the beginning of a software development, the first question should be whether it is medical software in the regulatory sense at all and whether approval or certification as a medical device is thus required.
Unfortunately, there is no clear definition of software in the two regulations. For example, there is one reference to "software as such" and another to "software which constitutes a device in itself". After all, the MDR and IVDR explicitly designate software as a (possible) medical device in Article 2 if a corresponding medical purpose is intended for the software.
At the end of 2019, MDCG 2019-11 was published on definitional issues related to medical software. This introduces a new term, namely "medical device software". The MDCG understands it to mean the following:
"Medical Device Software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a medical device in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device" (MDCG 2019-11).
The MDCG definition focuses solely on the intended purpose of the software. Certain types of software are excluded, namely software that collects population data, provides information from medical guidelines, is intended for epidemiological studies, or functions as a registry.
In addition, MDCG 2019-11 defines control software ("software intended to drive or influence the use of a (hardware) medical device"). Control software does not directly support the medical intended use but is still considered a medical device. Control software may also qualify as an accessory under MDR and IVDR.
MDCG 2019-11, like the "Manual on borderline and classification for medical devices under Regulation (EU) 2017/745 on medical devices and Regulation (EU) 2017/746 on in vitro diagnostic medical devices," contains examples of software as a medical device.
Purpose
The decisive factor, then, is the intended purpose of medical software formulated by the manufacturer. A purpose statement should take into account the following aspects, among others:
- medical benefit
- medical indication
- patient population
- functional principle
- place of interaction with humans
- environment of use
The manufacturer matches the intended use of its software with the regulatory definition of medical devices in the MDR (and IVDR, if applicable). The MDR defines medical devices primarily by their intended uses (Article 2). These are:
- Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
- Diagnosis, monitoring, treatment, alleviation of or compensation for injury or disability,
- Examination, replacement, or modification of anatomy or of a physiological or pathological process or condition; and
- Obtaining information through the in vitro examination of specimens derived from the human body, including organ, blood, and tissue donations.
In addition, products for contraception or promotion of conception as well as for cleaning, disinfection or sterilization are medical devices in the sense of the law.
Medical devices must also be intended for human use. In addition, the principle of action is important. Medical devices act in or on the human body, but not pharmacologically, metabolically or immunologically.
To what extent medical software acts "on" the body is open to question. This definition is obviously based on a "hardware-heavy" approach to medical devices. The majority of software applications should not have an immediate spatial relationship to the body. For example, in a web app based therapy management program, software code and computational operations are predominantly linked to server hardware that may be located somewhere in the sense of a cloud based service.
The IVDR, in Article 2, adds specific aspects characteristic of in vitro diagnostic devices (IVDs) to the MDR's definition of a medical device. Accordingly, "IVD software" is used for the in vitro examination of samples derived from the human body, including blood and tissue donations, and serves to provide certain information relevant to diagnosis or therapy.
Risk classification
Depending on whether a software is medical device software and/or control software, different classification rules are applied. The classification rules are used to determine the risk class of a medical software. The higher the risk class, the higher the effort required for approval.
In most cases, a manufacturer of device-independent medical device software must classify it "as such". In this case, Rule 11 Annex VIII MDR applies. More on this in the next section. If, on the other hand, it is control software, the manufacturer must classify it as part of the device.
Rule 3.3 Annex VIII MDR is of importance in this context. According to this, software that controls a product or influences its use is assigned to the same class as the product. Rule 3.3 also states that control software must be classified on its own if it is independent of other products. MDCG 2019-11 interprets at this point that medical device software that is also control software must always be classified on its own according to its medical purpose. However, according to MDCG 2019-11, the resulting risk class must not be lower than that of the associated device.
In addition, the authors of MDCG 2019-11 still emphasize the importance of Rule 3.5 Annex VIII MDR, which states in simplified terms that the strictest rule always applies should anything ever be unclear. Incidentally, Rules 3.3 and 3.5 find their equivalent for in vitro diagnostic medical devices in Rules 1.4 and 1.9 in Annex VIII IVDR.
It should be clear by now at the latest what outstanding importance the formulation of the intended purpose has for the subsequent marketing of medical software.
It should be pointed out once again at this point that the manufacturer must define the intended purpose of his (software) product and determine the risk class on this basis. Even if this will in future in most cases take place in discussion with a notified body, the manufacturer bears full responsibility here.
Rule 11 of the MDR
In the (old) medical device guidelines, there are no explicit classification rules for medical software. In order to take into account the special properties and risks of medical software, Rule 11 became part of the MDR. It explicitly defines the classification of device-independent medical software.
Rule 11 applies to device-independent software with a medical purpose. In the wording:
"Software intended to provide information that is used to make decisions for diagnostic or therapeutic purposes is in Class IIa unless those decisions have effects that may cause the following:
- The death or irreversible deterioration of the health of a person, in which case it is in class III, or
- a serious deterioration in a person's health or a surgical procedure, in which case it is classified as Class IIb.
Software intended for the control of physiological processes is in Class IIa, unless it is intended for the control of vital physiological parameters, in which case the nature of the change in these parameters could result in immediate danger to the patient, in which case it is assigned to Class IIb. All other software is assigned to Class I" (Annex VIII, Chapter III, Rule 11, Medical Devices Regulation).
From a practical perspective, the question arises as to what medical device software can still be classified as a Class I medical device. Software-mediated information should in most cases also serve decision-making for diagnostic or therapeutic purposes. Conceivable would be software that serves direct therapy guidance without providing further information on therapy (or diagnosis), software for primary preventive purposes, or software without direct reference to diagnosis or therapy, but which nevertheless falls within the scope of the MDR (contraception, cleaning, disinfection, sterilization, or Annex XVI products).
A critical aspect of Rule 11 is that it only provides for conditional risk stratification. For example, it does not consider the probability of death or deterioration of health. Even the most "innocuous" software could theoretically result in death if rare and adverse events occur. MDCG 2019-11 reinforces the restrictive effect of Rule 11 because medical device software that also controls a device must always be assigned to the higher class when in doubt.
In light of the lack of risk consideration, MDCG 2019-11 proposes to adopt a 2014 recommendation from the International Medical Device Regulators Forum (IMDRF). The recommendation, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations, defines proprietary risk categories based on the association of patient status ("non-serious, serious, critical") with the importance of software-mediated information for diagnosis or therapy ("low, medium, high"). The MDR risk classes are then "matched" with the IMDRF risk classes. Accordingly, for example, MDR Class III software provides very important information that has an impact on a patient-critical situation.
MDCG 2019-11 includes examples of risk classifications. In addition, the products module of the European database EUDAMED and the BfArM directory of digital health applications (DiGA) can be used to search for further examples.
Obligations as a manufacturer of medical devices
Before a manufacturer places its software on the (European) market as a medical device, it implements the general obligations from Article 10 of the MDR or IVDR. These are summarized (the links lead to specific technical papers):
- Fulfillment of the Essential Safety and Performance Requirements.
- Establishment of a quality management system
- Establishment of a risk management system
- Conducting a clinical evaluation or performance evaluation in the case of an IVD
- Provision of instructions for use and labeling
- Establishment of technical documentation
- Establishment of a post-market surveillance (PMS) system for the medical device
- Ensuring financial protection in the event of liability
- Appointment of a responsible person
- Registration (incl. Unique Device Identification, UDI)
- Conformity assessment procedure, EU declaration of conformity and CE marking.
The Essential Safety and Performance Requirements in Annex I MDR correspond to the General Safety and Performance Requirements in Annex I IVDR. Essential requirements for software from Chapter II Annex I MDR are mainly:
- Compatibility
- interoperability
- repeatability
- reliability
- performance
- Application of software lifecycle processes
- Validability
- Verifiability
- IT security
- Network suitability
- Suitability for mobile use
How these requirements must be met in concrete terms depends on the particular design of a piece of software, its intended purpose and the results of the risk analysis.
Standards
Through the (voluntary) application of harmonized standards in Europe on the part of the manufacturer, compliance with part of the general safety and performance requirements is assumed by the European legislator in the sense of a presumption of conformity (Art. 8 (1) MDR). Harmonized European standards (EN) are published in the C series of the official journal of the EU. These are often based on international versions of standards (ISO and IEC). Important standards for medical software are listed below in relation to individual topics (the links lead to specific technical papers):
Risk management (ISO 14971, Medical devices - Application of risk management to medical devices).
Quality management (ISO 13485, Medical devices - Quality management systems - Requirements for regulatory purposes)
Software life cycle (IEC 62304, Medical device software: software life cycle processes)
Product safety (IEC 82304-1, Healthcare software - Part 1: General requirements for product safety)
Usability (IEC 62366-1, Medical devices - Part 1: Application of usability to medical devices)
Clinical investigation (ISO 14155, Clinical investigation of medical devices in humans - Good clinical practice)
Safety (IEC 60601-1, Medical electrical equipment, Part 1: General requirements for safety including essential performance characteristics). The standard deals with the electrical safety of active medical devices and refers to medical software as "Programmable Electrical Medical Systems", or "PEMS" for short, and devotes a separate section to them. IEC 60601-1 relates PEMS directly to the required risk management process and demands the documentation of a software life cycle.
Information security (Security) (IEC TR 60601-4-5, Medical electrical equipment - Part 4-5: Guidance and interpretation - Safety-related technical security specifications). Digital health applications (DiGA) must also meet very high IT security requirements (see BSI TR-03161).
Currently, there are no standards for AI-based software that relate specifically to the medical application area.
Conclusion
The current MDCG document 2019-11 basically takes a sensible approach by tending to decouple the definition of medical software from the question of whether software is connected to each other and/or to hardware. However, the MDCG document is difficult to read, contains inconsistencies, and does little to simplify matters from a practical perspective.
In general, one notes with the MDR that it was developed from a "hardware history." Overall, the approval of medical software in Europe has become more complex. Get in touch with us. We will help you with the practical implementation of your software project, draw up a detailed CE roadmap with you and implement all the necessary processes. We also offer regular information events on regulatory topics.
