MDR Class I Software

Guidance based on the experiences of the Johner Institute as well as Oliver Hilgers and Stefan Bolleininger

The discussion around Class I software is ongoing. This article provides guidance on the classification of medical software according to the rules of the MDR.

1. Background

a) Relevance of the Issue

Whether medical software qualifies as MDR Class I is significant for manufacturers, authorities, and Notified Bodies:

Authorities are responsible for Class I software, while Notified Bodies handle software of higher risk classes. Despite recently extended transitional periods, Notified Bodies remain overloaded. As a result, it has become increasingly difficult for manufacturers to bring innovative medical software to market in a timely manner, leaving gaps in patient care.

When software is unnecessarily classified into higher risk classes, it adds to the bottleneck at Notified Bodies with non-critical products. This negatively impacts the competitiveness of manufacturers.

The authors have observed an increasing trend toward such overregulation. On the other hand, software that is wrongly classified too low escapes the oversight of Notified Bodies, contrary to the legislator's intent.

b) Purpose and Scope of This Article

This article aims to provide greater clarity to avoid unnecessary, time-consuming debates and incorrect classifications. It does not intend to soften existing rules but rather to compensate for the errors, gaps, and inconsistencies in the legal framework, as outlined in section 4.a), in the spirit of the legislator.

3. Classification of Class I Software

a) Overview

The following diagram summarizes the legal requirements of Rule 11 from Annex VIII of the MDR in a decision tree. It confirms that some software does fall into Class I.

Each step of the diagram is explained below.

Figure 1: Decision diagram for software classification. The grey box distinguishes software that does not provide information for diagnostic or therapeutic decision-making.

b) Case Distinction (1)

This distinction is taken verbatim from the MDR, stating:

Typically, it is the physician's role to diagnose and decide on therapies. As per the German Duden:

A good rule of thumb:
Software used only by patients and not for monitoring physiological processes generally falls into Class I.

Caution:
The reverse is not always true - just because physicians are the users does not automatically mean higher classification.

However, if software assigns physician-like responsibilities to patients (e.g., prescribing medication with dosage based on symptoms), it would not qualify as Class I.

The condition “decisions for diagnostic or therapeutic purposes” is not met if:

• The information supports other decisions (e.g., prevention or prognosis)
• The information does not support any decisions
• The software provides no information

These cases are addressed below.

c) Case Distinction (2)

This step determines whether the software is used for decision-making at all, apart from diagnostic or therapeutic purposes.

Software may support decisions related to prevention, prediction, prognosis, or fertility enhancement.

The MDR explicitly adds “prediction” and “prognosis” to the definition of medical devices, indicating they are not the same as diagnosis.

Prevention vs. therapy:
Therapy involves treating a diagnosed condition, while prevention aims to avert disease before it occurs.

Examples of non-diagnostic, non-therapeutic software:

• Software calculating scores to predict disease probability or progression
• Software suggesting lifestyle changes to reduce future disease risk (e.g., exercise, diet, contact with medical professionals, early detection measures)

The MDR likely refers to primary prevention only (eliminating risks before disease onset), and not to secondary (early detection) or tertiary (managing consequences) prevention.

d) Case Distinction (3)

This applies if the software doesn’t support decision-making at all. Either it provides no information or only information unrelated to decisions.

Examples:
Software assisting patients in performing therapy exercises:

• Vision training software
• Pelvic floor training for erectile dysfunction
• Behavioural therapy apps for addiction
• Guided strength or mobility exercises

Here, the patient is the primary user.

MDCG 2019-11 explicitly names fertility prediction software as an example of Class I.

If standalone software delivers no information, its qualification as a medical device is questionable. If it’s part of another device, other rules besides Rule 11 may apply.

e) Case Distinction (4)

This determines whether the software monitors physiological processes. If yes, it falls into Class IIa or IIb.

If not (and it doesn’t provide diagnostic or therapeutic decision support either), it qualifies as Class I.

f) Case Distinction (5)

According to MDR Recital 60, Class I products should pose low risk of harm.

Both severity of harm and probability of occurrence must be considered. Even severe harm can be acceptable if probability is extremely low.

At this stage, design or protective features should not be considered (black-box approach; see MDCG 2021-24, Note 1 to Rule 9).

IEC 62304 Amendment 1’s initial safety classification flowchart offers some guidance.

Reg Bytes

Reg Byte: Qualification and Classification of AI /LLM under MDR:

Here are some quick thoughts for your consideration:

• MDCG 2019-11 does not yet provide comprehensive guidance on the evaluation of large language models (LLMs).
• Please note that the mode of action, whether involving LLMs or traditional algorithms, is not itself a criterion for qualification. Therefore, any qualification examples provided in MDCG 2019-11 would equally apply if LLMs were included.
• Similarly, the mode of action does not influence classification. In both qualification and classification, the intended purpose remains the primary consideration for evaluation.

If you have further questions feel free to reach out.

Reg Byte: Qualification and Classification of AI scribes under MDR

NHS Definition of AI Scribes
According to the NHS England’s guidance on AI scribes (published in 2024):

AI scribes are digital tools that use artificial intelligence to automatically generate clinical documentation by listening to and transcribing patient-clinician conversations.

These systems are designed to reduce administrative burden on healthcare professionals by creating structured clinical notes, summaries, or records, which can then be reviewed and edited by the clinician before being entered into the patient’s health record.

Key features from the NHS guidance:

• AI scribes use speech recognition and natural language processing to capture and document clinical encounters.
• The primary purpose is to support clinicians by automating note-taking, not to provide diagnostic or clinical decision support.
• The clinician remains responsible for reviewing and confirming the accuracy of the documentation generated by the AI scribe.

There are ongoing questions about whether AI scribes qualify as medical device under MDRs. Here are some key considerations:

• The guidance issued by the NHS applies only within the UK and is not legally binding; only the MHRA provides authoritative information on qualification and classification.
• Under the MDR, NHS guidance is not directly applicable, though it may offer some regulatory insight.
• MDCG Guidance 2019-11 does not currently address AI scribes.
• The intended purpose of the software is crucial:
  • If the software is designed solely to reduce administrative burden, it is generally not considered a medical device.
  • If the software is intended to support clinical decision-making, it is likely to be classified as a medical device.
• If your goal is to position the software as a non-medical device, ensure that your claims are consistent and prepare a contingency plan in case reclassification becomes necessary. It is advisable to thoroughly document your software and take into account the requirements of the AI Act, particularly for aspects that are difficult to modify later, such as the entire training process and data governance.

If you have further questions feel free to reach out.