— A Guide to classification of —

MDR CLASS I SOFTWARE

START

MDR Class I Software

About this article

In 2023, regenold took the initiative to bring together regulatory experts from organizations including Johner Institut and b-on-Quality. The objective was to collaboratively develop guidance for manufacturers, specifically to clarify the requirements and implications of MDR Class I for software.

You can find the German version here, followed by the English version below:

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.

2. Legal Framework for Class I Software

a) MDR

The legal basis for software classification is exclusively Annex VIII of the MDR, specifically Rule 11.

b) MDCG Guidelines

The MDCG has published guidelines on product classification:

  • MDCG 2019-11 on software classification
  • MDCG 2021-24 on medical device classification

These guidelines are not legally binding. Economic operators have the flexibility to follow or disregard them:

"Having regard to the status of guidance documents, economic operators and notified bodies should be allowed flexibility as to how to demonstrate compliance with legal requirements."

— MDCG 2022-14, Section 11

However, legal significance may arise if a guideline is cited in a court ruling—as was the case with the European Court of Justice referencing MEDDEV 2.1/6.

c) IMDRF

MDCG 2019-11 references an IMDRF document on software qualification and classification, making the IMDRF classification scheme indirectly relevant to decisions on Class I software.

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:

"Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa (or higher)"

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.

4. Conclusion and Summary

a) Evaluation of the Rules

Debates around software classification stem from the regulatory framework. Rule 11 has several flaws:

  • Incomplete: Assumes all critical software aids diagnostics, therapy, or physiological monitoring, which is not always true.
  • This allows potentially high-risk software to be under-classified as Class I.
  • Conversely, over-classification occurs when all software supporting diagnostic or therapeutic decisions is automatically put in Class IIa or higher - even if some should qualify as Class I under the IMDRF framework.
  • Inconsistent: Rule 11 conflates diagnosis and therapy, whereas other product rules treat them separately - disadvantaging software.

Also, Rule 11 relies solely on severity, not risk. The MDCG 2019-11 tries to address this but falls short—especially in its failure to elaborate on Class I examples.

Classification guidance should be based on intended use, not software functionality (e.g., data storage or transfer).

b) Consequences of These Rules

  • Regulatory inconsistencies, as seen in authority and Notified Body decisions (e.g., DiGA directory)
  • Over-classification hinders competitiveness and innovation
  • Some products never reach the market, depriving patients of access
  • MDCG quirks become entrenched through court rulings
  • EU rules diverge from those in the US and Australia, which aim for both safety and innovation

c) Recommendations

Ideally, Rule 11 should be fundamentally revised to eliminate inconsistencies and embrace a risk-based approach - harmonized with global frameworks.

If legal amendments are not feasible, the MDCG should revise 2019-11 via a transparent, peer-reviewed process.

Authorities and manufacturers should interpret MDR in line with its risk-based principles - rather than act as if Class I software no longer exists.

Still, software with a non-negligible risk of serious harm should not remain in Class I.

The authors hope this article contributes to that end.

Disclaimer
This article reflects the current state of knowledge and may change as new guidelines and rulings emerge.

Updates
2022-12-23: Replaced solid line after the "likely not MDSW" box with a dashed line, as the path should end if it's not an MDSW.

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.

Reg Byte: EU Borderline and Classification Manual - Impact on Medical Device Software

The latest update to the EU Borderline and Classification Manual does not introduce new software specific positions, however still it contains examples worth to revisit since they are relevant for software qualification and classification under MDR and MDCG 2019 11.

Smartphone application for STI prevention strategies
The smartphone application addressing STI prevention is not MDSW because its function is to facilitate information exchange and behavior based risk awareness at a population or network level, not to achieve an individual medical purpose based on user specific physiological or clinical characteristics. The absence of patient specific medical intent prevents qualification as a medical device.

Medical calculators
Software implementing calculators or score-based formulae intended to inform diagnosis or therapeutic decisions qualifies as MDSW. Even where the underlying arithmetic is simple, the intended purpose to inform patient management triggers Rule 11 and typically leads to class IIa or higher.

Non-binding status
As with MDCG guidance, the manual states that its views are not legally binding. It is an interpretative aid reflecting Member State consensus and European Commission services' views and should be applied alongside MDR, MDCG 2019 11, and competent authority positions.

Practical guidance

  • Define the intended purpose with precision, explicitly stating whether outputs are used to inform diagnosis, therapy, or patient management.
  • For calculators and score tools that inform clinical decisions the algorithm and argumentation is key since the Borderline Manual and the MDCG contradict in certain sections (e.g. definition of simple search). Thus a precise evaluation of your software algorithm is key to make a final decision with regard to the qualification of a medical device
  • For behavior oriented, population level tools without individual physiological inputs or medical intent, avoid medical claims and ensure alignment with non-device regulatory frameworks.

If you have further questions feel free to reach out.

Have a question or need more specific guidance?

Have a question or need more specific guidance?
We're more than happy to answer any of your inquiries:

If you have further questions feel free to reach out.

Page Contents

Have a question or need more specific guidance?
We're more than happy to answer any of your inquiries:

Whether you’re planning your first EU submission or preparing to scale your presence, regenold gives you the insight and operational support to succeed.

CONTACT US TODAY

Tel. +49 7632 82 26-0 Email: info@regenold.com