MDR 附件八第 11 条规则是对数字健康领域震动最大的分类规则。在 93/42/CEE 指令下，大多数医疗软件属于 I 类，采用自我认证，无需公告机构。在 MDR 之下，大多数辅助决策软件至少属于 IIa 类。类别的改变并非一次文档层面的微调：它让公告机构进入了软件开发商的日常。
第 11 条规则究竟如何规定
条文确立了一套三步逻辑，必须按顺序阅读。
第一步：默认为 IIa 类。 旨在提供信息、用于作出治疗或诊断决策的软件属于 IIa 类。这是起点，而非例外。任何临床辅助决策软件都从这道门进入监管范围。
第二步：两种向上的例外。 若软件所支撑的决策，其影响可能导致死亡或健康状态不可逆转的恶化，则该软件属于 III 类。若这些影响可能导致健康状态严重恶化或外科手术介入，则属于 IIb 类。外科手术介入本身就是一项独立标准：一款软件若其错误可能导致实施手术、或导致手术失误，即便没有直接的生命威胁，也属于 IIb 类。这些使类别升高的严重后果，也正是软件上市之后触发警戒义务与报告时限的后果。
第三步：监测。 旨在监测生理过程的软件属于 IIa 类。只有当它们监测关键生理参数、且这些参数的变化可能对患者生命构成即时危险时，才升入 IIb 类。两个条件是累加的：关键参数，以及变化时的即时危险。一款在重症监护中追踪心率的软件同时满足两项条件。一款在健康随访中追踪同样心率的应用则一项都不满足，甚至很可能根本不是医疗器械。
所有其他软件属于 I 类。实际上，这一类别已变得非常狭窄：2025 年修订版指南给出了一个例子，且附有严格条件。
一条适用规则补全了整个机制：控制某器械或作用于其使用的软件，与该器械属于同一类别（附件八，规则 3.3）。第 11 条规则适用于作为独立器械分类的软件。
为何重新分类范围如此之广
在指令之下，核心标准是软件在某个物理器械中的位置。MDR 将标准转向软件自身错误的临床影响。一款提示鉴别诊断的软件从 IIa 类起步，根据错误提示的后果升至 IIb 或 III 类。一款放射治疗计划软件落入 IIb 或 III 类：一次剂量学错误可能导致不可逆转的恶化。一款自动判读心电图的软件，只要其输出会引导一项后果严重的决策，即升入 IIb 类。
从 I 类升至 IIa 或 IIb 类改变了整个工作的性质：完整的技术文档、实质性的临床评价、依据 IEC 62304 的软件生命周期、PMS 与 PMCF 计划，以及公告机构的评审。升类的开发商同时接触到 ISO 13485，并且必须审核您的 ISO 13485 质量管理体系。其软件如今被归为医疗器械，还须遵守唯一器械标识与 EUDAMED 注册要求，包括在无形分发的情况下。开发商填写的表格并没有变多。他改变的是自己的监管身份。
MDCG 2019-11 Rev.1：2025 年 6 月的修订重新洗牌
关于软件资格判定与分类的参考指南 MDCG 2019-11 于 2025 年 6 月 17 日修订。这并非一次简单的润色。有四项更新直接关系到开发商。
“独立软件”概念的终结。 修订版放弃了独立软件的概念，转而采用按功能划分的方法：重要的是每项功能的预期用途，而非承载它的载体。欧洲的术语是 MDSW（Medical Device Software，医疗器械软件）。SaMD 仍是大西洋彼岸使用的 IMDRF 术语，但一份以 MDSW 为思路的欧洲文档，说的正是其评审者的语言。
模块化方法。 一款软件可以拆分为多个模块，其中一些具有医疗用途，另一些则没有。每个医疗模块必须有明确且成文的预期用途，开发商必须证明非医疗模块不会损害医疗模块的安全性或性能。这条边界须以书面形式、在技术文档中划定。
MDAI 术语的出现。 修订版首次为搭载人工智能的医疗软件（Medical Device AI）命名，作为 MDSW 的一个子集，同时受人工智能法规约束。开发学习型算法的开发商如今需要交叉比对两部法规，而非一部。
预期用途作为基石。 修订版反复强调对精确、无歧义预期用途的要求，且须与验证数据以及开发商的公开声明保持一致，包括网站与应用商店页面。分类建立在这一书面预期用途之上。模糊的预期用途只会产生站不住脚的分类。
此外，该指南区分了创建或修改医学信息的软件与仅显示或存储医学信息的软件。一款处理数据以推导出临床结果的算法属于前一类。一个仅显示实验室结果、不作任何处理的门户系统则属于后一类，对它首先要提出的是资格判定问题，其次才是类别问题。
这对 2026 年的开发商意味着什么
一家在 2025 年 6 月之前完成软件分类的开发商，其推理建立在 2019 版指南之上。该版本已被取代。模块的资格判定假设、边界情形、预防类软件：这些都是 Rev.1 作出不同或更细致裁决的地方。一项在 2022 年作出的 I 类分类，值得摆上 2025 年的条文重新审视，尤其当软件在历次版本中不断加入辅助决策功能时。
代价高昂的场景始终如一：一款在发布时被归为 I 类的软件，逐项功能不断丰富，其真实预期用途已滑向辅助决策，而分类却未随之调整。当某个公告机构或主管当局提出这一问题的那天，答案只能在紧迫之下仓促构建，而版本历史正与自己作对。
用 Rev.1 重新审视自己的分类只需半天的结构化工作。在审核中发现它已过时，则意味着在约束之下彻底重来。重新核验您软件的分类的最佳时机，是您自己选择的时机，而不是审核员强加给您的时机。
法规来源：