When software is a medical device, and in which class
The device rules apply to software through two decisions taken in order: whether the product is a medical device at all, and only then which risk class it falls in. Both decisions turn on the intended purpose the manufacturer defines.
Whether software is a medical device
Classification follows qualification: software has to be established as a medical device before any thought goes to its class. The qualification question is always whether the software has a medical purpose of its own, judged against the device definition in Article 2 of the EU Medical Devices Regulation (MDR). The intended purpose, which the manufacturer defines, is crucial to both qualification and classification.
The device definition and medical device software
Under the MDR, a medical device is an instrument, an implant, a material or software used for a specific medical purpose: the diagnosis, prevention, monitoring or prediction of a disease, injury or disability, the investigation, replacement or modification of a pathological process or state, or the treatment, alleviation or prognosis of disease or injury. Such a device is intended by its manufacturer to be used, alone or in combination, for human beings, and does not achieve its primary intended action by pharmacological, immunological or metabolic means. In vitro diagnostic devices fall under their own regulation. A recital of the MDR adds that software in its own right qualifies as a device when its manufacturer specifically intends it for one or more of the medical purposes in the definition. Software for general purposes, even when used in a healthcare setting, and software for lifestyle and well-being purposes are not devices, so the MDR's requirements do not apply to them. Stand-alone software under the MDR also includes software used with devices for the control or support of conception. A medical purpose makes software a device whatever the type of application.
MDCG 2019-11, a guidance document on medical device software, defines software as a set of instructions that processes input data into output data. Input can be DICOM files such as those of x-rays or CT scans, electronic health records, audio such as speech, or a plain word-processor or PDF file, and output can be a screen display, printed graphics, audio or a text file. Medical device software is software intended to be used, alone or in combination, for one of the purposes in the device definition.
Medical device software is the European term. The European Commission's guidance on the qualification and classification of software introduced it in place of software as a medical device. The term was established in the EU within MDCG 2019-11, and it falls under the device definition in Article 2(1) of the MDR. It covers standalone software and software used together with a hardware device alike, whereas software as a medical device refers only to software that is not part of a hardware device. Software as a medical device is the term of the International Medical Device Regulators Forum (IMDRF) and the one usually used in the United States, and in most cases the two terms are mixed up.
Standalone software, accessories and parts of devices
Software used in the medical field can be medical device software in its own right, an accessory to a device or a part of a device, and some of it is not a device at all. Independent or standalone medical device software has a medical purpose by itself, as a program that helps diagnose stroke by showing structural brain changes does, or a smartwatch app that raises an alarm on an arrhythmia. Medical device software used in combination with a hardware device is intended to drive or influence that device and still has a medical purpose of its own. For example, software that measures and transmits blood glucose levels, calculates the insulin dose and drives an insulin pump has its medical purpose in calculating the dose correctly and driving the pump. An accessory is not a device itself but is intended by its manufacturer to be used together with one or several particular devices, only for their intended purpose, either to specifically enable them to be used in accordance with it or to specifically and directly assist their medical functionality. Software that drives or influences a hardware device without creating information or holding a medical purpose of its own is in most cases qualified as an accessory, and its documentation then has to be provided as for other accessories. In one practitioner's experience, such software was always classified as an accessory when it had no medical purpose of its own, though the same practitioner holds that in some cases whether one wants or has to classify it as one is a specific regulatory decision. An ultrasound machine shows the difference: software whose sole purpose is to put the image on the display is used with the device but has no medical purpose of its own, while software that also highlights structures on that image to help with the diagnosis has a medical purpose of its own and drives the device. The qualification of software as a device or an accessory is independent of the software's location and of the type of interconnection between the software and a device.
The MDR's definition of software as an accessory is broader than that of the Medical Device Directive (MDD): the MDR counts software as an accessory to a device where it enables or can assist the device's medical functionality, whereas the directive counted only software that enabled it. The MDD treated only stand-alone software as a device, and software embedded in a device needed no certification separate from the device, in line with the IMDRF definitions. The MDR is not limited to stand-alone software, and it requires devices that incorporate electronic programmable systems, including software, to address performance, quality and risk management procedures.
The MDCG 2019-11 qualification flowchart
MDCG 2019-11 puts qualification first and gives a flowchart for it. The chart asks first whether the product is software as the guidance defines it; software that is not falls outside the guidance. It then asks whether the product is a device without a medical purpose, an accessory, or software driving or influencing a hardware device; if so, the MDR covers it as a device. Failing that, it asks whether the software performs an action on data beyond storage, archiving, communication or simple search, and whether that action is for the benefit of individual patients; if both hold, the software qualifies as a medical device. One practitioner recommends reading the guidance, while finding some parts of it really helpful and others quite confusing; on the same view, the way the flowchart sets its questions is not that useful, and the flowchart does not necessarily make things easier.
Software on either side of the line
Whether software has a medical purpose depends on its intended use, so two otherwise similar apps can fall on either side of the line. A mobile app that measures heart rate during interval training so that the user gets the most out of the training has a fitness purpose and no medical one, while a similar app that also measures heart rhythm and raises an alarm on an arrhythmia or other abnormal rhythm has a clear medical purpose. An app tracking daily food intake to give an overview of carbohydrate, fat and protein has a nutrition purpose, while an app that also tracks food intake and gives guidance on how to reduce the risk of coronary heart disease has a medical one.
Some software is definitely not medical device software: digital medical textbooks, educational software, medical search engines, population health software, and software used only for resource management in, for example, a hospital. Hospital software for patient admission, appointment scheduling and billing is not medical device software either, because it is used in a medical setting without a medical purpose of its own. Nor is an electronic patient record system that only stores and transfers patient data. A telesurgery system that allows a surgical procedure to be conducted from a remote location, for example with the use of virtual reality, is medical device software: it does not perform the procedure itself, but it is used to treat a disease through the procedure and supplies the surgeon with all the relevant information. Software highlighting certain structures on radiographic images for better visibility is a harder case. One practitioner holds that it is medical device software, because better visibility somehow helps the physician make a better or more accurate diagnosis and so also somehow drives the patient's clinical management, though the answer always depends on the details the manufacturer gives in the intended purpose.
Software whose manufacturer did not intend it for a medical purpose is not medical device software. So a general chatbot such as ChatGPT does not become medical device software when patients with major depression use it for feedback and solutions on their condition and the provider never labelled that use. A manufacturer who realises the product is frequently used that way still has to think about how to deal with it.
Mobile apps in the EU and the United States
In the EU, an app that meets the device definition must comply with the MDR, which holds such software to the same requirements as any other device placed on the EU market. Many apps do not meet the EU definition and are not medical devices. A fitness tracker app needs no CE certification as a medical device because it is not one, while an app used to treat diabetes does.
In the United States, the Food and Drug Administration issued final guidance for mobile medical app developers on 25 September 2013, two years after a July 2011 draft, and updated it in February 2015. The final guidance was a significant overhaul of the draft, based on an unusually extensive period of public comment and deliberation. It clarifies how such apps are defined, states the agency's intended regulatory approach, and gives examples distinguishing apps that will be regulated as medical devices from those for which the agency will exercise enforcement discretion. When it was issued, areas of ambiguity remained and the practicalities of compliance and enforcement were still to be worked out, but it was held to be a welcome tool for the mobile health industry. The guidance is a recommendation that in most cases is not legally binding and states only the agency's current thinking.
The agency's oversight relates to apps that can be considered medical devices, which it calls medical apps: essentially those that can be used as an accessory to a regulated device or that turn a smartphone or computer into one. It focuses only on apps that present a greater risk to patients if they do not work as intended and on apps that make a mobile platform affect the functionality or performance of a traditional device, and device regulations of apps share that focus. Some apps that may meet the device definition will not be regulated because they are deemed to pose lower risk to the public. The agency does not intend to fully regulate even medical apps, and one commentator read the draft guidance as showing that the agency recognised it was not properly positioned to validate the content of mobile medical apps. Only a select group of the thousands of existing health apps are wholly covered by the guidance.
The guidance's examples of general health apps are medical dictionaries, interactive anatomy diagrams or videos, medical flash cards and quizzes, and general patient education materials. Its examples of unregulated low-risk medical apps include apps that help patients with diagnosed psychiatric conditions keep up behavioural coping skills, apps that help people with asthma track inhaler use, asthma episodes, where they were at the time of an attack, or environmental triggers, and apps that keep track of medications and give reminders for better adherence. Its regulated apps include those that measure and display an ECG through a connected sensor, alter the function or settings of an infusion pump, calibrate, control or change the settings of a cochlear implant, or display device data from a nursing central station on a physician's mobile platform.
Classification under the MDR
The MDR carries over from the MDD a risk-based system that sorts stand-alone software into four risk classes by the device's degree of invasiveness and its potential risks.
Software is always an active device, so the classification rules for active devices apply to it. An active device depends on a source of energy other than the body's own or gravity and acts by converting that energy.
Classification follows Annex VIII of the MDR, and besides the rule dedicated to software, some implementing rules should be considered. Classifying software takes into account Rule 11 of Annex VIII of the MDR or, under the In Vitro Diagnostic Medical Devices Regulation (IVDR), all the classification and implementing rules of the IVDR's Annex VIII. Software driving or influencing the use of a hardware medical device falls in the same class as that hardware device; software independent of any other device is classified in its own right; and where several rules or sub-rules could apply to the same device, the strictest rule, and with it the higher classification, should apply. Where software drives or influences another device, the compliance requirements are assessed within the intended purpose of the driven device, not of the software.
Rule 11 is the classification rule the MDR introduced for the risks attached to information supplied by active devices such as software, and it weighs the impact the software has on patient management and on the patient's condition. Software intended to provide information used to take decisions with a diagnostic or therapeutic purpose is class IIa in general. It is class III where such a decision could cause death or an irreversible deterioration of a person's state of health, and class IIb where it could cause a serious deterioration of health or require surgical intervention. Software intended to monitor physiological processes is class IIa, and software intended to monitor vital physiological parameters such as blood pressure or heart rate is class IIb where the nature of variations in those parameters could result in immediate danger to the patient, as in an intensive care setting. All other software is class I. Rule 11 is built like most of the MDR's classification rules, with a general class followed by exceptions, so its exceptions are not peculiar to software.
Under the MDR, software can fall in these classes, each resting on classification rules of Annex VIII:
| Class | Classification criteria | Classification rules (MDR Annex VIII) |
|---|---|---|
| Class I | Considered under the MDR as a medical device but not under the classification rules as IIa to III | Rule 11 |
| Class IIa | Informing on diagnostic or therapeutic decisions, except those considered as class IIb and class III; monitoring physiological processes | Rule 11; Rule 10 |
| Class IIb | Informing on diagnostic or therapeutic decisions with an impact that may cause serious deterioration of the state of health or a surgical intervention | Rule 9; Rule 10 |
| Class IIb | Directly influencing the performance of an active therapeutic class IIb device; monitoring of vital physiological parameters, variation of which can cause immediate danger | Rule 11 |
| Class III | Informing on diagnostic or therapeutic decisions with an impact that may cause death or irreversible deterioration of the state of health | Rule 11; Rule 9 |
| Class III | For controlling, monitoring or directly influencing the performance of active implantable devices; with an integrated or incorporated diagnostic function which significantly determines the patient management by the device | Rule 22 |
| Not a medical device | Not intended to be used alone or in combination for a specific medical purpose; data storage or recording only | Not applicable |
Under the MDR, changes to the classification of software have been a leading cause for concern. Rule 11 in particular was expected to have significant implications, as many products until then not classified as medical devices, or classified as class I, might be considered class IIa, IIb or III devices. The MDR was expected to move many mobile health and software products up into higher risk classes, with more stringent regulatory requirements. The cause is the MDR's approach to risk severity together with the higher classification rule for software combined with medical hardware.
The risk classes of Annex VIII are unrelated to the software safety classes of IEC 62304 and should not be mixed up with them. IEC 62304 defines three software safety classes by the possibility of injury or damage to health, from class A, where no injury or damage to health is possible, to class C, where death or serious injury is. The safety class strongly affects how much documentation and testing the software needs.
With the application of the MDR, the differences in regulations and guidance between the EU, the US and the IMDRF, specifically those on the broader definition of software as a medical device and on risk classification, were to become more relevant. One practitioner holds that software intended for both the EU and the United States can potentially have two different classifications, since there are still some differences between US and European law and a different classification rule could apply under each. On that view, the manufacturer would have to weigh the work of two classifications against going with the higher class and covering all the documentation it requires.
The adapted IMDRF framework
To help manufacturers find the right class, MDCG 2019-11 provides a risk-classification framework adapted from the IMDRF's, which weighs two things: the impact the software has on patient management and the seriousness of the medical condition. The IMDRF's own guidance, released in 2014, categorises software as a medical device into four risk groups, I to IV.
One axis is the significance of the information the software provides. Software used to treat or diagnose a condition carries a very high risk to the patient, software that drives clinical management a medium risk, and software that only informs clinical management, with the decision left to the healthcare professional, a lower risk. The other axis is the healthcare situation or condition: critical, where patients are in a life-threatening state of health or a high-risk population; serious, where the disease progresses moderately, is often curable, or does not usually require a major intervention; and non-serious, as in minor chronic illnesses or slowly and predictably progressing conditions. Crossing the two axes gives the class for the scenario in question.
| State of the healthcare situation or patient condition | Treat or diagnose (high significance; IMDRF 5.1.1) | Drives clinical management (medium significance; IMDRF 5.1.2) | Informs clinical management (low significance; everything else) |
|---|---|---|---|
| Critical (IMDRF 5.2.1) | Class III (category IV.i) | Class IIb (category III.i) | Class IIa (category II.i) |
| Serious (IMDRF 5.2.2) | Class IIb (category III.ii) | Class IIa (category II.ii) | Class IIa (category I.ii) |
| Non-serious (everything else) | Class IIa (category II.iii) | Class IIa (category I.iii) | Class IIa (category I.i) |
One practitioner classifies three cases with the framework. Software that analyses stroke images and makes treatment decisions for patients suspected of stroke is class III: stroke is a critical condition, and the software supplies the diagnosis and the treatment decision, even though a healthcare professional still implements it. Software that provides treatment options for cancer patients to healthcare professionals from patient data is most likely class IIb: cancer patients are usually in a critical condition, and although the professional still selects among the options, providing them probably drives the decision rather than merely informing it. Whether it drives or only informs is what the definition of the intended purpose has to settle. Software monitoring vital parameters in an intensive care unit is class IIb rather than IIa: the difference lies between a serious and a critical condition, and intensive care patients are usually in a critical one. So slight details or changes in the intended purpose can perhaps move software from class IIa to IIb, or even to III.
For most software used in a medical setting there may always be a chance that the patient or user experiences a serious deterioration of health, but the scenarios considered should be realistic. On one practitioner's reading, the framework serves only to find the most relevant or most likely scenario that applies, because a patient's death can always be thought of as somehow related to treatment given with medical device software. Software that calculates a number estimating the risk that an aorta ruptures, from which the doctor decides how to treat the patient or whether to follow them up carefully, is a disputed case. It neither diagnoses nor treats, so its significance can be read as medium, yet the patient can die. The same practitioner holds that such patients are usually in a critical condition and that software giving the physician information to make the decision drives clinical management, so the device would be at least class IIb. That practitioner allows that some notified bodies might argue for class III, and places the software at class III or IIb, but definitely not lower. The opposing reading holds that software returning only a number, from which the physician makes the decision, does not itself kill anyone, unlike software that influences a device, where the device can then kill someone. On that reading, Rule 11 sets the software at class IIa, the IMDRF framework may then raise it to IIb or III, and the highest class is the final one. The practitioner who placed it at class IIb or above holds that such decisions always have to be made together with the manufacturer and the notified body.
Class I software
Class I poses particular challenges for software, because the original IMDRF framework has three cells in which software could be class I and the adapted framework in MDCG 2019-11 has none. The guidance gives several examples for every other class and only one for class I: an app intended to support conception by calculating the user's fertility status from a statistical algorithm.
Outside the guidance, it has been proposed that software to which the adapted framework does not apply, because it neither informs nor drives clinical management and is not used to treat or diagnose a condition, could potentially be class I. One example is a COVID-19 app that notified users who had potentially been in contact with an infected person, so that they would take a test and stay at home for a certain number of days. The app was a medical device because it was intended to prevent a disease, and it benefited the patient by helping to stop others from being infected, yet it neither informed nor drove clinical management and neither treated nor diagnosed the condition. An app that gives smokers advice and helps them stop smoking could be another example: it would benefit the patient, but it neither informs nor drives clinical management and neither diagnoses nor treats a disease.