简而言之： 当软件具有医疗用途（诊断、预防、监测、预测、预后、治疗）时，它就属于欧盟医疗器械法规（MDR，2017/745）下的医疗器械，并被赋予一个风险等级：I、IIa、IIb 或 III，主要依据是附件 VIII 的规则 11。该等级决定了您是能够自行认证（仅限 II 类）还是需要公告机构的介入，临床评估需要多深入，以及上市后监管如何进行。另外，工程标准IEC 62304 为软件分配一个安全等级：A（不可能造成伤害）、B（可能造成非严重伤害）或 C（可能造成死亡或严重伤害），这决定了生命周期需要多少文档、设计和测试。这两个分类是相关的但独立的，都取决于软件可能造成的伤害，而不是其复杂性。
第一步：它到底是不是一个器械？
如果软件的预期用途是医疗相关的：诊断、预防、监测、预测、预后或治疗（第 2(1) 条)，那么它就属于欧盟 MDR 下的医疗器械。根据 MDCG 2019-11 的规定，仅用于存储、归档、通信、显示或搜索数据的软件不属于器械；而用于创建或修改医疗信息以支持诊断或治疗决策的软件则属于器械。
MDR 的定义（第 2 条第 1 款）围绕预期用途展开。存储、归档、通信、显示或执行简单数据搜索的软件不是器械（MDCG 2019-11 指出了这一点）。创建或修改医疗信息以支持诊断或治疗决策的软件是。显示实验室数值及其参考范围的记录不是；告诉用户该数值表明某种状况或推荐剂量的软件才是。详情请参阅 健康应用程序是医疗器械吗？ 中的资格认定步骤。
第二步：MDR 风险等级，规则 11
MDR 规则 11 根据错误决策可能造成的伤害来对医疗器械软件进行分类。提供用于诊断或治疗决策信息的软件，默认归为 IIa 类；如果此类决策可能导致严重恶化或需要手术，则归为 IIb 类；如果可能导致死亡或不可逆转的恶化，则归为 III 类。监测软件属于 IIa 类，而监测生命体征的软件属于 IIb 类。
| 软件预期用途… | MDR 等级 |
|---|---|
| 提供用于诊断或治疗目的的决策信息（默认） | IIa |
| …此类决策可能导致死亡或健康不可逆恶化 | III |
| …此类决策可能导致健康严重恶化或需要手术干预 | IIb |
| 监测生理过程（默认） | IIa |
| …监测可能导致患者立即危险的生命体征参数 | IIb |
| 其他任何情况（属于器械但以上均不适用） | I |
规则 11 将大多数以前的 II 类软件推升至 IIa 或更高等级，这是 MDR 对数字健康产生重大影响的主要原因。MDCG 2019-11 和 IMDRF 风险框架（信息的重要性 × 医疗状况）有助于对临界情况进行分类。驱动或影响硬件设备的软件将继承该设备的等级（实施规则的规则 3.3）。
按等级的后果： II 类只需自行声明，提供技术文件和注册，无需公告机构（Im、Is、Ir 除外）；IIa 需要公告机构对质量体系和技术文件样本进行评估；IIb 同理，但需要更严格的文档审查；III 类需要进行全面的技术文件审查，并在适用时咨询专家小组。所有等级都需要质量管理体系、与等级相称的临床评估、负责法规遵从的人员、UDI、在 EUDAMED 中注册、上市后监管和警戒。
第三步：IEC 62304 软件安全等级
IEC 62304 软件安全等级根据外部风险控制后，软件可能造成的最大伤害来评定医疗器械软件：A 类表示不可能造成伤害，B 类表示可能造成非严重伤害，C 类表示可能造成死亡或严重伤害。该等级决定了软件生命周期所需的开发、验证和文档工作的严谨程度。
IEC 62304（2006 年，2015 年修订）是医疗器械软件生命周期流程的协调标准。其安全等级源于软件可能导致的最坏危险情况，在考虑了软件外部的风险控制措施之后：
| 等级 | 危险情况可能导致… | 生命周期要求 |
|---|---|---|
| A | 无伤害或健康损害 | 软件开发计划、需求、发布；问题解决；配置管理 |
| B | 非严重伤害 | A：加上架构设计、集成和系统测试验证、记录单元验证 |
| C | 死亡或严重伤害 | B：加上每个单元的详细设计、额外的架构隔离、更严格的验证 |
等级按软件系统分配，也可以按分解后的软件项分配，这样只有风险部分才需要 C 级严格性；该标准解释了所需的隔离论证。ISO 14971（风险管理）为分类提供依据；IEC 82304-1 为在通用平台（手机、云）上运行的健康软件增加了产品级别的要求。
两者如何相互作用
MDR 风险等级和 IEC 62304 安全等级是相互独立的：MDR 等级（I 至 III 类)决定了监管途径和通知机构的参与程度，而 IEC 62304 等级（A 至 C 类)决定了工程流程的严谨性。一个 IIa 类的应用程序，根据错误输出可能造成的伤害，可能属于 62304 的 B 类或 C 类。
MDR 等级关乎监管途径；IEC 62304 等级关乎工程流程。根据规则 11 的 IIa 类应用程序可能属于 IEC 62304 B 类（错误信息可能导致非严重的护理延误）或 C 类（如果错误的剂量建议可能致命）。I 类器械通常是 62304 A 类，但不一定。公告机构期望技术文件能显示 62304 等级及其理由、相应级别的生命周期文档以及与风险管理文件的关联。网络安全（MDCG 2019-16，IEC 81001-5-1）会一并进行评估。
工作示例
一个 SaMD 的工作示例：一个记录、显示和分享症状的症状追踪应用程序不属于医疗器械。如果添加一个功能，根据经过验证的量表对症状进行评分，并告知用户何时就医，那么它就属于医疗器械，默认属于 MDR 规则 11 的 IIa 类，IEC 62304 的 B 类；如果是用于心脏病治疗的场景，则属于 C 类。
一款症状跟踪应用程序，允许用户记录症状、查看趋势并与医生分享：不是器械（存储、显示、通信）。同一款应用程序增加了一项功能，根据验证过的量表对记录的症状进行评分，并告知用户何时评分表明他们应寻求护理：现在是器械，根据规则 11 默认IIa 类（用于诊断决策的信息；错误的“无需就医”可能延误治疗，严重但通常不可逆，因此不是 IIb 或 III 类，除非目标疾病使其成为 IIb 或 III 类）。IEC 62304：错误的安心可能导致护理延误，根据疾病严重程度为非严重到严重，因此为B 类，对于心脏病应用可能为C 类。途径：ISO 13485 QMS、公告机构、量表的临床评估、可用性工程（IEC 62366-1）、上市后监管。
美国，简述
在美国，FDA 根据预期用途对软件作为医疗器械进行监管，分为 I、II 和 III 类，并有 510(k)、De Novo 和 PMA 等审批途径。21 世纪治愈法案将行政软件、一般健康产品、电子健康记录和某些临床决策支持排除在器械类别之外。FDA 认可 IEC 62304 作为一项共识标准。
FDA 根据相同的预期用途逻辑监管软件作为医疗器械，分为 I、II 和 III 类，并有 510(k)、De Novo 和 PMA 等途径。21 世纪治愈法案（第 3060 条）将几类排除在器械状态之外：行政软件、通用健康、电子健康记录以及允许临床医生独立审查建议依据的临床决策支持（FDA 的 2022 年 CDS 指南对此进行了狭义解释）。FDA 承认 IEC 62304 为共识标准，并且自 2023 年起，要求为“网络器械”提供网络安全文档。ISO 13485 已成为美国质量体系法规（QMSR）的基础（2026 年）。
在 Anpheros
Anpheros Daily 存储、显示和共享；它不评分、不解释或不推荐，其预期用途也明确说明了这一点。因此，它不是规则 11 下的医疗器械，也不是治愈法案的排除项，团队应用 ISO 27001 风格的安全和文档化软件实践，而不走器械路线。如果将来添加了具有医疗用途的功能，将在发布前根据规则 11 进行分类，并根据 IEC 62304 进行开发。请参阅 健康透明度。
本页面解释了产品和工程团队的监管规定。它不构成法律建议；“来源”下链接的文本具有权威性，您的数据保护官、公告机构或法律顾问将决定您的具体情况。最后审查：2026 年 10 月。
相关页面
来源
- Regulation (EU) 2017/745 (MDR), Annex VIII, EUR-Lex
- MDCG 2019-11: Qualification and classification of software
- IEC 62304:2006+AMD1:2015, Medical device software lifecycle processes
- IEC 82304-1:2016, Health software product safety
- FDA: Clinical Decision Support Software guidance (2022)
- FDA: Software as a Medical Device
常见问题
软件可以属于 MDR 的 II 类吗？
可以，但很少见：只有具有医疗目的且既不用于诊断或治疗决策，也不用于监测生理过程的软件。大多数符合器械定义的应用程序属于 IIa 类。
IIa 类器械需要临床试验吗？
它需要进行临床评估，可以依赖文献、等效性数据和性能数据；当现有证据不足时，需要进行临床研究。声称具有诊断性能的软件通常需要自己的性能研究。
IEC 62304 是强制性的吗？
它是一个协调标准，因此遵循它就意味着符合 MDR 的软件要求（附件 I，第 17 条）的推定。您可以使用其他方法，但之后必须证明等效性，这在实践中没有人这样做。
AI 功能呢？
同样的规则适用，外加欧盟人工智能法案：经过公告机构评估的器械属于附件 I 下的高风险人工智能系统，其数据、日志记录、透明度和人类监督等要求将与 MDR 一起进行评估。
在沙盒中免费试用
5 分钟完成第一次 FHIR 调用. 一个内置患者授权的 HL7 FHIR R4 API：先在沙盒中试用，然后连接您自己的应用或诊所系统。
免费 · 30 位合成患者 · 无需信用卡
Anpheros 致力于打造一个由患者掌控的医疗记录，并可在欧盟的 HL7 FHIR R4 平台上与任何诊所共享。这些指南旨在帮助您理解和整理您的健康信息，但不能替代您的医生。
关于 Anpheros →