The outcome of software classification has significant consequences for a manufacturer. For example, the product life cycle reporting is strongly dependent on the risk class. To put it simple: the higher the risk class, the higher the effort. For details see our blog article on clinical evaluation. Moreover, clinical trials are mandatory for high risk products as class III and implantable devices.
The EU Medical Device Regulation (MDR) has raised uncertainties concerning the questions when a software is a medical device and how the new software classification rules shall be applied. Therefore, the community is waiting for guidance from the Medical Device Coordination Group (MDCG) of the EU Commission. In this blog article, we will give you exclusive insights in the respective draft guideline before its release.
- Use of Intended Purpose in Differentiation From Non-Medical Devices and Software Classification
- Is the Term “Stand-Alone Software” Linked to the Type of Hardware on Which It Is Operated?
- Insight 1: The Term “Medical Device Software” is Introduced
- Insight 2: Not all Software Classification Have Changed
- Insight 3: Classification of Independent Medical Device Software Follows a New Rule
- An Example: The Mole Assessment Medical App
- Our Recommendations
Use of Intended Purpose in Differentiation From Non-Medical Devices and Software Classification
The intended purpose does answer the question, whether your software can be qualified as medical device. Only then is the software subject to any requirements from MDR such as the software classification. Therefore, you should match the intended purpose with the definition of a medical device according to Art. 2 (1) MDR. Are there any indicators in the intended purpose that let us exclude software from being a medical device? The EU Commission’s document MEDDEV 2.1/6 provides further guidance in this respect. Herein software performing actions limited to “storage, archival, communication, simple search or lossless compression” is not qualified as medical device. That sounds easy. But what if these functions still support the intended purpose of a medical device? For example, software intended to transfer vital physiological parameters from a near-patient sensor via a wireless network to a monitoring system might fall in this category.
In addition, the intended purpose forms the basis for the application of the classification rules (implementing rule 3.1 Annex VIII MDR). But how can you translate the intended purpose of your software into the requirements of rule 11 to end up finally with the assignment of a risk class?
Is the Term “Stand-Alone Software” Linked to the Type of Hardware on Which It Is Operated?
We find a well-accepted definition of stand-alone software in the guideline “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations” by the International Medical Device Regulators Forum. Herein the categorization as stand-alone is based on its ability to fulfill a medical purpose on its own without being part of a hardware medical device. Does that mean that software needs to be running on general purpose hardware to be claimed stand-alone? This would conflict with the requirement that software should be classified according to its intended purpose. Hence, software can be claimed to be stand-alone, even though it is running on a medical device, assuming that the software is able to fulfill its own intended purpose.
Let us see how the MDCG guideline helps to solve these issues.
Insight 1: The Term “Medical Device Software” is Introduced
The MDCG guideline introduces the term “Medical Device Software” (short: MDSW). It is defined as “all software that is intended to be used, alone or in combination, for a medical purpose specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or is driving or influencing the use of a device.”
Thus, MDSW is consisting of two sub-types:
- Independent MDSW providing information for diagnostic or therapeutic purposes and
- MDSW driving or influencing the use of a hardware medical device.
Noteworthy, software even being integrated and provided exclusively with a hardware device, can be independent and be a medical device on its own. Here is an example: an algorithm that directly diagnoses acute hemorrhagic stroke in CT images.
Insight 2: Not all Software Classification Have Changed
In a nutshell – the basic principles of software classification do not change in the MDR.
For example, the most important implementing rules stay essentially the same:
- “Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right.” (3.3. Annex VIII MDR). Only sentence 2 was newly added.
- “If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device’s intended purpose, the strictest rule and sub-rule resulting in the higher classification shall apply.” (3.5. Annex VIII MDR).
What’s also not new is inheriting the risk class of a controlled or influenced device, which was already part of the MDD classification rules. The MDCG guidelines provides, in this case, additional clarity, that this software should be qualified as a medical device.
Classification Rules for Active Medical Device Apply
Software remains to be deemed as an active medical device (Art. 2 (4) MDR)). Thus, rules 9, 10, 11, 12 and 22 of Annex VIII MDR apply in principle. However, since MDSW cannot physically administer and/or remove substances, rule 12 does not apply, but rule 3.3 does. In addition, rule 15 should be considered for MDSW used for contraception. For most of these rules exist counterparts in the MDD.
In summary, only rules 22 and 11 are completely new. However, most independent MDSW will fall under rule 11, which we will discuss in the next sections.
Insight 3: Classification of Independent Medical Device Software Follows a New Rule
According to the MDCG Guideline rule 11 for independent MDSW can be divided into three parts:
- rule 11 a) Software providing information for diagnostic or therapeutic purposes (classes IIa – III),
- rule 11 b) Software monitoring physiological processes (classes IIa – IIb) and
- rule 11 c) all other Software (class I).
In contrast to rule 10, however, sub-rule 11 b) is not restricted to vital physiological processes such as breathing, heart rate, brain functions, blood gases, blood pressure or body temperature.
Furthermore, the MDCG guideline clarifies that rule 11 a) is applicable to “software providing information on diagnostic or therapeutic processes”. It emphasizes that rule 11 a) was intended to provide a risk-based approach considering the consequences of a wrong decision performed on data provided by the software in question. Do you see the problem? Rule 11 a) uses the expression “can cause” while not considering the likelihood of the event.
IMDRF Classification Helps to Apply Rule 11
To solve this problem, the MDCG guideline now advises to make use of the already mentioned IMDRF risk categorization framework. It supports the risk classification of new or unknown software by introducing two essential aspects:
- the significance of the information provided and
- the criticality of the situation or condition.
The following figure shows you how to apply the IMDRF risk classification to the rule 11:
Note that the numbering of IMDRF risk classes slightly differs from the MDR risk classes. In total 9 risk categories with 4 different classes can be derived.
How Manufacturers May Influence the Outcome of the Software Classification
The significance of the information will probably be the most important factor which can be directly influenced by manufacturers:
- What is the product claim? For example, is the software used for direct diagnosis?
Related to the product claim, the second dimension is not controllable by a manufacturer, but depends on what the software is intended to be analyzed:
- How critical is the health situation or the disease? Does it need a time-critical treatment? Is the patient population fragile compared to other populations?
What becomes obvious is, that software being assigned to class IIa under the MDD is likely to become class IIb under the MDR. The remaining question is, whether there still will be class I software. The answer is yes, namely:
- through the application of implementing rule 3.3 (software as part of hardware medical device) or
- in cases when the software is not providing information for diagnostic or therapeutic purposes (rule 11 c).
Uncertainties in Application of IMDRF Risk Categorization
The IMDRF risk categorization brings with it a few uncertainties:
- If the term “prediction” is used in the intended purpose, the determination of the correct category according to IMDRF is not clear.
- The distinction between “diagnosis” and “support of diagnosis”, “screening” and “triage” is not clear.
- The consideration of “fragile populations” is not clear enough as an additional recital depending on the criticality in question.
MDSW Cannot be Accessory
Do you remember the MDR definition for “accessory”? According to Art. 2 (2) an “accessory for a medical device means an article which, whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several particular medical device(s) to specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the medical device(s) in terms of its/their intended purpose(s)”.
The MDCG guideline speaks a clear language: MDSW fulfilling a medical purpose cannot be an accessory.
In other words, software in general (e.g. the operating system) can be an accessory, although the term ‘article’ is hard to grasp for software. It only emphasizes, software with a medical intended purpose, cannot be an accessory.
An Example: The Mole Assessment Medical App
In our blog article “Risk Classification of a Medical App” we applied rule 11 to a medical app for mole assessment. The app allows users to take pictures of moles on the skin and subsequently store and analyze them. Based on image processing algorithms, the app provides detailed assessment of the scanned moles. Additionally, the app assesses the probability that the scanned mole is a melanoma in order to support early diagnosis of skin cancer. One thing is clear, this app is an independent MDSW according to the MDCG guideline!
Minor Differences in The Intended Purpose Have Significant Consequences
Imagine the above described app existing in two versions:
- the first is used by patients for an initial self-assessment and
- the second is used by healthcare professionals for medical diagnosis.
Although at least version 2 of the app is used for direct diagnosis, rule 10 is not applicable. It refers to “direct diagnosis or monitoring of vital physiological processes” (recital 3 of 6.2. Annex VIII). Instead, we apply rule 11 according to the table in this blog article.
Version 1 “informs of options for diagnosis” (significance of information) and even with the most serious disease type option we end up with class IIa (field 3 in table). Version 2 “aids in diagnosis” while the final diagnosis is in the physician’s responsibility. Even here the most serious disease type option would lead us to class IIb (field 2 in table).
Finally, it must be mentioned that if the medical purpose of the app is the direct diagnosis it may even be assigned to class III (field 1 in table).
- The MDCG is currently working on guidance for the qualification of software as medical device. We advise you to monitor constantly new releases of guidance documents.
- With “driving or influencing the use” a new aspect is introduced in the qualification of software as medical device. It shall be understood as “fulfilling a medical purpose in combination” and by this being part of the intended purpose.
- Note that you must read the mentioned IMDRF document since the MDCG guideline itself does not provide further explanations on the risk categorization.
- Note that manufacturers are advised to use the wording of the IMDRF risk categorization terminology for the intended purpose in order to clearly justify the classification. Moreover, you should create a crisp wording in the intended purpose, in order to distinct medical from other functions.