Authors:<\/strong><\/p>\n Miriam Schulze, CEO <\/strong>of BAYOOMED<\/p>\n Julia Schliesch, Marketing <\/strong>Generalist at BAYOOMED<\/p>\n Artificial intelligence is increasingly finding its way into medical software. Whether it\u2019s documentation assistants, clinical decision support systems (CDSS), or other intelligent applications\u2014AI 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. <\/p>\n 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. <\/p>\n 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\u2014and that is precisely where misclassifications arise. <\/p>\n<\/div><\/div><\/div><\/div><\/div> L\u00e4kemedelsverket, the Swedish Medical Products Agency, announced a market surveillance measure in March 2026 that specifically targets AI-powered documentation assistants\u2014known 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. <\/p>\n The reason is uncertainty on both sides. Manufacturers have reached differing conclusions regarding the classification of such systems\u2014including 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. <\/p>\n 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\u2014assuming they are classified as medical devices at all. And even then, there is often considerable room for interpretation when evaluating the specific use case. <\/p>\n 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: <\/p>\n<\/div> How Medical Content Is Created and Quality-Assured<\/p>\n<\/div><\/li> how to handle incorrect or incomplete summaries<\/p>\n<\/div><\/li> Transparency and Traceability of AI Models<\/p>\n<\/div><\/li> the application of the relevant legal framework<\/p>\n<\/div><\/li><\/ul> The results will be summarized in a report intended to contribute to regulatory clarity and a common understanding of risks and requirements\u2014both 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\u2014so manufacturers can verify their classification today. <\/p>\n<\/div><\/div><\/div><\/div><\/div> 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\u2019s guidance on the qualification and classification of software. <\/p>\n 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. <\/p>\n 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\u2014as 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\u2019s interpretation\u2014and that is the standard against which your documentation will be evaluated during the conformity assessment. <\/p>\n The guide divides Rule 11 into three subrules:<\/p>\n<\/div> Subrule 11a<\/strong> applies to software that provides information used to make decisions for diagnostic or therapeutic purposes. The guidance explicitly describes this mode of action as characteristic of medical device software as a whole\u2014the subrule is therefore broadly applicable in principle. The classification is Class IIa. <\/p>\n<\/div><\/li> Subrule 11b<\/strong> applies to software used to monitor physiological processes or parameters.<\/p>\n<\/div><\/li> Subrule 11c<\/strong> covers all other applications. Rule 11 concludes in the text of the regulation with the statement that any other software falls under Class I. Subrule 11c is thus a catch-all provision\u2014and the only route into Class I. <\/p>\n<\/div><\/li><\/ul> Anyone who classifies a software medical device as Class I is thereby implicitly claiming that the software\u2019s 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. <\/p>\n Software that generates structured medical documentation from a treatment consultation\u2014which is then added to the patient\u2019s medical record\u2014clearly falls into a different category.<\/p>\n<\/div><\/div><\/div><\/div><\/div> In practice, four guiding questions can be derived from this framework that can be applied to many AI applications.<\/p>\n Will the output be used in the subsequent supply process?<\/strong> 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. <\/p>\n Does the software transcribe\u2014or does it interpret?<\/strong> 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. <\/p>\n What does our risk management plan say?<\/strong> Anyone who includes scenarios in the risk file\u2014such as a delayed diagnosis due to misinterpreted information\u2014has thereby documented that the software\u2019s output can influence clinical decisions. Such an entry is difficult to reconcile with a classification under Subrule 11c. <\/p>\n Does the intended use match the actual use?<\/strong> A stated purpose described as \u201cadministrative support\u201d 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. <\/p>\n<\/div><\/div><\/div><\/div><\/div> 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. <\/p>\n For manufacturers, this means that the question is not just \u201cClass I or IIa,\u201d but what realistic clinical consequences an incorrect classification could have.<\/p>\n<\/div><\/div><\/div><\/div><\/div> 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\u2014including the involvement of a Notified Body, which is not required for Class I devices without a measuring function, sterility, or reusability. <\/p>\n 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. <\/p>\n<\/div><\/div><\/div><\/div><\/div> Even if the Swedish market surveillance authority focuses on a specific product category, the MDR\u2019s 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\u2014including analysis and evaluation software, clinical decision support systems, and monitoring applications. <\/p>\n 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. <\/p>\n<\/div><\/div><\/div><\/div><\/div> The uncertainty surrounding the classification of AI software is not a regulatory shortcoming\u2014the 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\u2019s output does not influence clinical decisions. <\/p>\n 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. <\/p>\n 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\u2014and 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. <\/p>\n<\/div><\/div><\/div><\/div><\/div>Mixed Reactions: Why Sweden Is Testing AI Documentation Assistants<\/h2><\/h2><\/div>
Rule 11: How the MDR AI Software Classifies<\/h2><\/h2><\/div>
What Actually Determines the Classification<\/h2><\/h2><\/div>
Class IIa is the lower limit, not the upper limit<\/h2><\/h2><\/div>
What This Means for the Development of AI Software<\/h2><\/h2><\/div>
Why This Goes Beyond Documentation Assistants<\/h2><\/h2><\/div>
Conclusion<\/h2><\/h2><\/div>
Additional Information<\/h2><\/h2><\/div>
\n
Sources<\/h3><\/h2><\/div>
\n