Authors:

Miriam Schulze, CEO of BAYOOMED

Julia Schliesch, Marketing Generalist at BAYOOMED

Artificial intelligence is increasingly finding its way into medical software. Whether it’s documentation assistants, clinical decision support systems (CDSS), or other intelligent applications—AI can support healthcare professionals, streamline processes, and improve patient care. AI software intended for medical use is subject to the same regulatory framework as any other software medical device: the MDR.

As these systems become more widespread, one issue is coming to the forefront that many manufacturers underestimate: the risk class. Especially with AI software that appears to be purely administrative at first glance, the risk classification under the MDR is often set too low. The decisive factor here is not whether AI is involved, but rather what information the software provides and how that information is used in the care process.

Yet the problem rarely lies with the rule itself. How software should be classified has been clear for years. The difficulty lies in applying the rule to individual cases—and that is precisely where misclassifications arise.

Läkemedelsverket, the Swedish Medical Products Agency, announced a market surveillance measure in March 2026 that specifically targets AI-powered documentation assistants—known internationally as AI or Ambient Scribes. Systems of this type record treatment consultations, convert speech to text, and use that text to generate structured medical documentation.

The reason is uncertainty on both sides. Manufacturers have reached differing conclusions regarding the classification of such systems—including the question of whether they are medical devices at all. The regulatory agency also points out the need for clarification: the line between administrative support and medical technology functions is not always clear when developing AI-based systems.

As described above, the challenge does not lie in the rule itself: Rule 11 of the MDR has provided well-established guidelines for the classification of software for years. The need for discussion arises only when these guidelines must be applied to specific applications such as AI Scribes—assuming they are classified as medical devices at all. And even then, there is often considerable room for interpretation when evaluating the specific use case.

What the agency is specifically examining: The inspections are intended to build knowledge about how such systems are designed, how the AI models are trained and validated, how they function in a clinical setting, and how manufacturers handle risk and quality management. Particular attention is being paid to four points:

The results will be summarized in a report intended to contribute to regulatory clarity and a common understanding of risks and requirements—both nationally and in the European context. The report will primarily clarify borderline cases. It will not change the rule itself, as it is already in effect—so manufacturers can verify their classification today.

The classification of software as a medical device is governed by Rule 11 of Annex VIII of the Medical Device Regulation (MDR). This is further specified in MDCG 2019-11, the Medical Device Coordination Group’s guidance on the qualification and classification of software.

Revision 1, dated June 2025, is the authoritative version. It explicitly includes AI-based medical device software within its scope and provides clarification regarding Subrule 11a.

First, a clarification: MDCG guidelines are not legally binding. The text of the regulation is binding, and the interpretation of Union law rests with the Court of Justice of the European Union—as is also stated on the cover page of the guideline. In practice, however, Notified Bodies and competent authorities use it as a benchmark for interpretation. Anyone who deviates from it must be able to justify their decision. For classification purposes, this means that Rule 11 itself is binding; the division into three sub-rules is the MDCG’s interpretation—and that is the standard against which your documentation will be evaluated during the conformity assessment.

The guide divides Rule 11 into three subrules:

Anyone who classifies a software medical device as Class I is thereby implicitly claiming that the software’s output does not influence clinical decisions. The two Class I examples provided in the guidance document in Annex IV illustrate just how far removed the output must be from clinically used data: an app that calculates fertility status based on menstrual cycle data, and an app that converts symbols into spoken language to assist people with communication disorders in speaking.

Software that generates structured medical documentation from a treatment consultation—which is then added to the patient’s medical record—clearly falls into a different category.

In practice, four guiding questions can be derived from this framework that can be applied to many AI applications.

Will the output be used in the subsequent supply process? It does not matter whether a decision is made during the treatment consultation itself. What matters is whether the completed documentation later serves as the basis for decisions regarding the course of further treatment. If that is the case, the software provides information within the meaning of Subrule 11a.

Does the software transcribe—or does it interpret? A verbatim transcript is different from structuring and synthesizing clinical content. As soon as a system derives, weights, and organizes information from the course of a conversation, it generates medical information rather than merely reproducing it.

What does our risk management plan say? Anyone who includes scenarios in the risk file—such as a delayed diagnosis due to misinterpreted information—has thereby documented that the software’s output can influence clinical decisions. Such an entry is difficult to reconcile with a classification under Subrule 11c.

Does the intended use match the actual use? A stated purpose described as “administrative support” does not provide protection if the product influences medical decision-making in day-to-day clinical practice. Statements in marketing materials and instructions for use are also taken into account in market surveillance.

For software with clinically used output, Class IIa is the starting point, not the maximum classification. A higher classification in Class IIb or III may be considered if an erroneous output could, with a reasonable degree of probability, lead to death, an irreversible or serious deterioration in health, or a surgical procedure.

For manufacturers, this means that the question is not just “Class I or IIa,” but what realistic clinical consequences an incorrect classification could have.

A retroactive reclassification does not merely result in additional documentation requirements. It also affects development processes, risk management, the validation of AI models, and conformity assessment—including the involvement of a Notified Body, which is not required for Class I devices without a measuring function, sterility, or reusability.

In practice, this means: precisely defining the intended use and regularly verifying it against actual use. Aligning risk management, quality management, and clinical evaluation with the intended function at an early stage. And structuring the technical documentation in such a way that it provides a clear and traceable rationale for why one subrule applies and the others do not.

Even if the Swedish market surveillance authority focuses on a specific product category, the MDR’s assessment framework applies to all AI software intended for medical use. Rule 11 and MDCG 2019-11 apply in all Member States and to all medical device software—including analysis and evaluation software, clinical decision support systems, and monitoring applications.

It is not the technology that determines the risk class, but rather the intended use, function, and the impact of the information provided on patient care. The fact that artificial intelligence is in use only makes the issue more pressing, because AI systems generate information whose origin is more difficult to trace.

The uncertainty surrounding the classification of AI software is not a regulatory shortcoming—the framework is established by Rule 11 of Annex VIII of the MDR, as specified in MDCG 2019-11, as revised in June 2025. Anyone classifying a device as Class I must be able to justify why the software’s output does not influence clinical decisions.

In Sweden, the regulatory authority is already actively reviewing these justifications, and the assessment framework is the same across all member states. For manufacturers, the implication is less regulatory than organizational: The classification issue should be addressed at the beginning of the development process, not at the end.

The MDR is not the only regulatory framework for AI software. If a software medical device contains an AI system, the EU AI Act introduces a second set of regulations that classifies such systems independently and imposes its own requirements. These two classifications overlap: Whether the high-risk obligations of the AI Act apply at all depends, among other things, on whether a Notified Body is involved in the conformity assessment—and that is determined by the risk class under Rule 11. We will discuss how both frameworks can be integrated in practice in a separate article.

• AI in Medical Software Development – How We Integrate AI Features into Medical Devices, from Model Selection to Validation
• Risk Management for Medical Devices – Risk Dossier, Risk Analysis, and the Connection to Classification
• Technical Documentation for Medical Devices – How to Document the Basis for the Risk Class in a Clear and Comprehensible Manner

• Swedish Medical Products Agency: Swedish Medical Products Agency Reviews AI Assistants in Healthcare, Press Release dated March 4, 2026 – lakemedelsverket.se (Swedish)
• Regulation (EU) 2017/745 on Medical Devices (MDR), Consolidated Version, Annex VIII, Rule 11 – eur-lex.europa.eu
• MDCG 2019-11 Rev. 1: Guidance on the Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR, June 2025 – health.ec.europa.eu (English, PDF)
• Regulation (EU) 2024/1689 on Artificial Intelligence (AI Regulation) – eur-lex.europa.eu