Medical apps, treatment planning software, and even firmware for ultrasound devices: software is legally classified as a medical device if it is used for medical purposes. This includes diagnosing, examining, or predicting the course of a disease and influencing a therapy. The EU Medical Device Regulation (MDR) even defines software as an active medical device, so that its classification might depend on other rules besides Rule 11.

In many cases, manufacturers may not even be aware that they are developing a medical device, because even health and wellness apps for smart phones might fall into this category. Since early 2020 medical apps can even be prescribed by physicians.¹ The ongoing COVID-19 pandemic has emphasized and expanded the importance of digital health technologies, ranging from a rapid transition to telehealth services, which are considered to be a breakthrough in incentivizing and advancing patients’ diagnosis, management, and treatment with digital health tools.

However, a digital health application needs to qualify as a medical device to fulfil this purpose. To reduce costs and efforts, manufacturers must first clarify whether their product is a medical device and ascertain which of the four risk classes (I, IIa, IIb, or III) defined in the MDR or the transition regulations applies to the product.² This leads to different requirements. For medical devices of Class IIa and higher, the MDR requires that notified bodies must be involved, and a quality management system according to the requirements in Annex IX of the regulation has to be established.

Helpful Guidance

The Medical Device Coordination Group (MDCG), an international expert committee, provides detailed guidance on software qualification and classification in its publication MDCG 2019-11 of November 2019. The requirements and criteria are specified in the EU regulations on medical devices (MDR 2017/745 – Annex VIII) and in-vitro diagnostics (IVDR 2017/746 – Annex VIII). According to the definition of the MDCG guidance, the term “medical device software” covers programs used in combination with a medical device, but also stand-alone software with an intended purpose as defined in the respective regulations.

With the help of a flowchart, manufacturers then determine step-by-step whether their software qualifies as a medical device software. Key aspects include intended use, individual patient benefits, and the applicability of the definition of software. A coronavirus contact tracing app, for example, is not considered a medical device as it is not influencing an individual patient’s diagnosis or therapy. By contrast, a smartwatch app that monitors the heart rate and thus impacts on therapy or diagnosis based on data analysis in line with its intended use is considered a medical device. The same applies to software controlling insulin pumps based on the sugar level inputs, as they calculate the correct dosage in addition to controlling the medical device.

Determine Product Classes for Software as a Medical Device

Depending on their level of risk, potential medical devices are divided into various product classes. Classes I to III represent risk potential in relation to the intended purpose, location, and duration of use. The characteristics are defined in the MDR, Annex VIII. A notified body then verifies that all regulatory product requirements have been fulfilled. After demonstrating conformity with the MDR regulation, the manufacturer affixes the CE marking to the product.

Classification Rule 11 is of particular significance for software developers. If software is used to take decisions with diagnosis, monitoring, or therapeutic purposes, it falls into class IIa. If the medical device software may incur the risk of severe deterioration to patients’ health based on the information it provides, the software product falls into class IIb; if the information may result in irreversible deterioration of a patient’s condition or death, it falls into class III—the highest risk class. All other software is assigned to class I. For more assistance, see “Software as a Medical Device: Possible framework for risk categorization and corresponding considerations” of the IMDRF (International Medical Device Regulators Forum).

Risk Evaluation

In the risk management procedure in accordance with ISO 14971, manufacturers first define a risk matrix including criteria of acceptance. Risk analysis then provides information as to which hazards can be derived from the intended use and which severities and probabilities are possible. If risks are unacceptable, risk minimization measures will be defined and implemented. Subsequently, manufacturers will have to continue this risk analysis into the future and re-evaluate their acceptance.

Another risk is poor usability: FDA analyses of recalls have shown that one-third of all incidents involving medical devices (including software) are caused by use errors. The international IEC 62366-1 standard establishes usability requirements. It is concerned with identifying potential risks related to usability and incorporating these into the risk management process. These risks also include physical properties and ergonomic characteristics as well as software ergonomics—i.e., whether the software is easily comprehensible, intuitive, and quickly usable.

In the European Union, the minimum requirements for the key lifecycle processes of software for specific medical uses are harmonized with the IEC 62304 standard. This concerns development and maintenance, configuration, and risk management as well as problem solving. Originally intended for both stand-alone and embedded solutions, in practice the standard is directed more at embedded solutions. Further requirements for stand-alone software and the validation of health software are defined by the IEC 82304-1 standard.

IT Security

In addition, artificial intelligence (AI) is increasingly found in medical devices, for example to predict the progress of diseases or for image analysis. However, decisions must be traceable and verifiable to ensure their use is safe for patients. According to the general safety and performance requirements of the MDR, software must be designed to ensure repeatability, reliability, and performance in line with its intended use. Manufacturers can prove compliance with this requirement by means of software verification and validation.

Software must furthermore be designed in accordance with the state of the art and comply with the principles of the software life cycle, risk management, and information security. Hacker attacks on clinic networks or compromised medical devices directly jeopardize human lives. The COVID-19 pandemic and the attendant provision of health services online has caused the overall threat level to rise. As a notified body, TÜV SÜD Product Service offers testing and certification of software for medical devices in accordance with the relevant software standards.

Sources