Software like a medical app that has 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 high effort and considerable liability risks. Therefore, the manufacturer should clarify as early as possible whether a software is a medical device in the legal sense and – if so – to which risk class it belongs. This article gives an overview of the path from a software to a medical device with CE-marking.
If manufacturers want to market a (software) medical device in Europe, they must comply with the European Medical Device Regulation (EU) 2017/745 (MDR) or the In Vitro Diagnostic Medical Device Regulation (EU) 2017/746 (IVDR). Currently, the “old” European directives on medical devices are also still in force. However, the transition period ends on May 25, 2021.
Those who are “practitioners” and deal with MDR and IVDR will quickly be disappointed. In contrast to the directives, the regulations control considerably more and significantly increase the requirements, but in total the regulations seem to be little consistent and precise.
There is not even a clear definition of terms. For example, both the phrases “software as such” and “software which constitutes a device in itself” are used. Other relevant regulatory documents are (harmonized) European standards, common specifications of the EU Commission, possible implementation and/or national legislation as well as various guidelines, above all those of the Medical Device Coordination Group (MDCG).
The above-mentioned inaccuracies in the European legal texts as well as the abundance of laws, rules and (binding) recommendations mean that the relevant professional circles are struggling for definitions, definitions and delimitations. This does not make the situation any easier for medical software manufacturers. It would of course be desirable to have rules that are as uniform and binding as possible.
When is software a medical device?
At the beginning of a software development, the basic question should be whether it is a medical software in the regulatory sense at all and whether it requires approval or certification as a medical device.
Software “related to health” is often divided into 4 groups:
- Software is not a medical device. An example is a fitness app.
- The software is a medical device and part of a medical device. An example is the software of a patient monitor.
- The software is a medical device and accessories of a medical device. An example is a service software to maintain the function of the device.
- The software is a stand-alone medical device . An example is a medical smartphone app that can be used to assess skin lesions.
Different wordings have become established for the different groups. The most common ones are “health app” for group 1, “embedded software” for group 2 and “software as medical device (SaMD) or medical app” for group 4.
At the end of 2019, the “MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR” was published to address the issue of classification of medical software. It introduces a new term, namely “Medical Device Software”. The MDCG defines it as follows:
“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.”
This can be greatly simplified, but much easier to read, interpreted as software that serves the prevention, diagnosis or therapy of diseases.
The MDCG definition thus focuses solely on the purpose of the software. If the software matches the corresponding detailed definitions in the MDR or IVDR (see below), it is a medical device. The MDCG 2019-11 excludes certain types of software as medical devices, namely those that collect population data, provide information from medical guidelines, are intended for epidemiological studies, or act as a registry.
In addition, the MDCG 2019-11 defines “control software”, although it names this much more complicated (“software intended to drive or influence the use of a (hardware) medical device”). Control software does not directly support the intended medical purpose but is still a medical device.
The guideline MDCG 2019-11 is primarily aimed at manufacturers of medical software and defines qualification criteria for medical software. The authors expressly point out that the guideline is not legally binding. However, it can be assumed in any case that the recommendations will play an essential role especially for clarifications with the notified bodies. It is therefore advisable to study the guideline in detail.
A critical factor is the intended purpose of a medical software that is defined by the manufacturer. The intended purpose should consider the following aspects:
- medical benefit
- medical indication
- patient population
- place of interaction
- usage environment
- working principle
The manufacturer must compare the intended purpose of a medical software with the regulatory definition in the MDR (and possibly IVDR). The MDR defines medical devices primarily according to their areas of application (Article 2). These are:
- Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of diseases,
- Diagnosing, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
- Investigation, replacement or modification of the anatomy or of a physiological or pathological process or state and
- Providing information by means the in vitro examination of specimens derived from the human body, including organ, blood and tissue donations.
In addition, products for control or support of conception as well as cleaning, disinfection or sterilization are medical products as defined by law.
Medical devices must also be intended for humans. The principle of action is also important. Medical devices work in or on the human body, but not pharmacologically, metabolically or immunologically.
In Article 2, the IVDR supplements the definition of a medical device in the MDR with specific aspects that are characteristic of in vitro diagnostics (IVD). An “IVD software” is therefore used for the in vitro examination of samples from the human body, including donated blood and tissue, and is used to provide certain diagnosis or therapy-relevant information.
Depending on whether a software is medical device software, control software or possibly both, different classification rules apply. The risk class of medical software is determined with the help of the classification rules. The higher the risk class, the greater the effort involved in the CE certification process.
In probably most cases, a manufacturer must classify a medical device software on its own if it does not run exclusively on a specific device. In this case rule 11 of the MDR applies. More on this in the next section. If, on the other hand, a medical device software is device specific or it is a control software, usually, the manufacturer must classify it as part of the device.
Nevertheless, there are exceptions and rule 3.3 in Annex VIII of the MDR is important in this context. Accordingly, software that controls a product or influences its application 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, which is also control software at the same time, must always be classified according to its medical purpose. 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 emphasize the importance of rule 3.5 in Annex VIII of the MDR, which simply states that the strictest rule applies should something be unclear. Rules 3.3 and 3.5 are also equivalent to in-vitro diagnostics in rules 1.4 and 1.9 in Appendix VIII of the IVDR.
It should be clear now of which outstanding importance the definition of the intended purpose is for the later marketing of medical software. At this point, it should be pointed out once again that the manufacturer must define the intended purpose of his (software) product and based on this, determine the risk class. Even if this will take place in most cases in dialogue with a notified body, the manufacturer bears full responsibility here.
Impact of rule 11 of the MDR
There are no explicit classification regulations for medical software in the medical device directives. In order to consider the special properties and risks of medical software, rule 11 became part of the MDR and defines the classification of software.
As already mentioned above, rule 11 applies to medical device software, in other words, to put it simply, to any software with a medical purpose. Literally:
“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.”
From a practical point of view, the question comes up as to which medical device software can still realistically be classified as a class I medical device? After all, this should currently be the most common software risk class. Which medical device software – i.e. those with a medical purpose – is ultimately not used for decision-making for diagnostic or therapeutic purposes?
Another obvious weakness of rule 11 is that there is no risk assessment that seems unrealistic. What is the probability of death or deterioration in health? Even the most “harmless” software can theoretically result in death if (extreme) undesirable events occur.
Unfortunately, the MDCG 2019-11 reinforces the restrictive effect of Rule 11 even more, because medical device software that also controls a device must always be assigned to the higher class in case of doubt.
In view of the lack of risk assessment, MDCG 2019-11 suggests adopting a recommendation from the International Medical Device Regulators Forum (IMDRF) from 2014. The recommendation “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations” defines its own risk categories, which result from the connection of the patient status (“non-serious, serious, critical”) with the importance of software-conveyed information for diagnosis or therapy result (“low, medium, high”). The MDR risk classes are then “matched” with the IMDRF risk classes. According to this, MDR class III software, for example, provides very important information that has an impact on a patient-critical situation.
Duties as a medical device software manufacturer
Before a manufacturer brings his software onto the (European) market as a medical device, he must implement the general obligations from Article 10 of the MDR or IVDR. These are summarized:
- Compliance with the general safety and performance requirements
- Establishment of a quality management system
- Development of a risk management system
- A clinical evaluation or performance evaluation in the case of an IVD
- Provision of instructions for use and labeling including Unique Device Identification (UDI)
- Creation of technical documentation
- Establishment of a system for monitoring the medical device after it has been placed on the market (Post Market Surveillance, PMS)
- Guarantee of financial security in the event of liability
- Designation of a person responsible for regulatory compliance
- EU declaration of conformity, CE marking and registration
General safety and performance requirements
A manufacturer of medical software must confirm by means of a declaration of conformity that its product meets the general safety and performance requirements according to Annex I of the MDR or IVDR. General requirements are, for example:
- Software life cycle
- IT security
- Network suitability
- Suitability for mobile use
- Ergonomics and usability
The specific requirements that must be met depend on the respective design of the software, its intended purpose, the risk analysis and the specific requirements of Annex I of the MDR or IVDR.
European standards help to meet the general safety and performance requirements. Important standards are:
- Risk management (EN ISO 14971:2019, Medical devices – Application of risk management to medical devices)
- Quality management (EN ISO 13485:2016, Medical devices – Quality management systems – Requirements for regulatory purposes)
- Software life cycle (EN 62304:2006/A1:2015, Medical device software – Software life-cycle processes)
- Usability (EN 62366-1:2015/A1:2020, Medical devices – Part 1: Application of usability to medical devices)
- Clinical investigation (EN ISO 14155:2020, Clinical investigation of medical devices for human subjects – Good clinical practice)
- Safety (EN 60601-1:2006/A12:2014, Medical electrical equipment, Part 1: General requirements for basic safety and performance). The standard addresses the electrical safety of active medical devices. For regulatory purposes, software is also considered an active medical device. When it comes to medical software, the standard speaks of “Programmable Electrical Medical Systems”, or “PEMS” for short, and dedicates a separate section to this. The 60601-1 places PEMS in direct relation to the required risk management process and requires the documentation of a software life cycle.
Currently, an overall standard for IT security of medical software does not exist. This is a disadvantage because software and connected medical devices gain increasing importance, so that security has become a critical topic for manufacturers and operators. In addition, the MDR explicitly demands IT security.
The conformity assessment procedure is the basis for affixing the CE mark. The MDR describes several ways here in Article 52. In the simplest case, i.e. for class I software, it is sufficient if the manufacturer has a “basic” quality management system (QMS) that meets the requirements of the MDR. In this case, neither a certification of the QMS nor an audit by a notified body are required.
In the case of software of higher risk classes, the conformity assessment procedure is usually run through with a complete QMS certified in accordance with ISO 13485. This requires a complete QMS of the manufacturer. In addition, the QMS is certified by a notified body. The technical documentation of the software must also be certified by a notified body. With the EU declaration of conformity, the manufacturer takes over product responsibility. It contains specified information and must be updated continuously.
The manufacturer then issues an EU declaration of conformity and affixes the CE mark. If a notified body is involved, the CE mark contains its 4-digit identification number. The CE mark appears on the packaging, the instructions for use and on advertising material. In addition, the medical device is registered in the European medical device database EUDAMED and the UDI codes are assigned.
Overall, the CE certification and thus the European marketing of medical software have not become easier.
The current MDCG guideline 2019-11 basically takes a meaningful path by decoupling the definition of medical software from the question of whether software is connected to one another or to hardware. However, the MDCG guide is difficult to read, contains inconsistencies and does not really simplify things from a practical point of view.
There are also no convincing approaches to how manufacturers should deal with MDR’s rule 11. At least there is a table in the appendix to the MDCG guide with suggestions on how a classification can be made using rule 11. Interestingly, class I software no longer appears in this table. There is also a disclaimer with the wording “for illustrative purposes only”.
It can be assumed that most of the medical software must be classified higher. This increases the requirements with respect to quality management, clinical evaluation or IT security. In addition, in most cases, notified bodies must be involved. Overall, the MDR could prove to be a difficult hurdle to overcome, especially for small or new manufacturers of medical software.