医疗软件(SaMD)监管分类体系全景解析

在当今的数字医疗浪潮中，开发“作为医疗器械的软件”（Software as a Medical Device，简称SaMD）无疑是最具潜力的赛道之一。然而，对于无数医疗科技初创公司和转型中的传统械企而言，在产品正式推向市场之前，往往会迎头撞上第一座大山——产品分类（Classification）。

您的软件属于什么风险等级？这不仅仅是一个学术问题，它直接决定了您的监管路径、文档要求，并在很大程度上决定了产品上市的时间表和成本预算。

今天，我们将为您系统性地拆解不同地区的 SaMD 分类标准及核心合规要求，帮您拨开监管迷雾，为产品的全球化战略打下坚实基础。

在美国，由于“作为医疗器械的软件”本质上仍是医疗器械，FDA 对 SaMD 的分类逻辑与传统实体医疗器械保持一致：基于风险程度，将其划分为I 类（Class I）、II 类（Class II）和 III 类（Class III）。

值得注意的是，在 FDA 近期发布的一系列指南文件中，官方开始越来越多地使用“器械软件功能”（Device Software Function, DSF）这一术语，来替代业内熟知的 SaMD。

根据《联邦食品、药品和化妆品法案》（FD&C Act），DSF 被定义为任何符合医疗器械定义的软件功能。这种术语的转变主要是为了统一监管口径，因为很多时候软件既可以独立存在（SaMD），也可以嵌入在硬件中（SiMD）。虽然名称变了，但底层的监管义务并没有实质性改变。

在上市前提交的文档要求上，SaMD（或 DSF）与传统硬件设备有着显著的区别。FDA 在关于《器械软件功能上市前提交内容》的最新指南中，彻底废除了过去“次要、中等、重大”的关注级别（Level of Concern），取而代之的是两个全新的文档等级：增强型（Enhanced）与基础型（Basic）。

在谈论医疗软件时，还有一个绝对绕不开的产品类别：临床决策支持（Clinical Decision Support, CDS）软件。这类产品处于监管的灰色地带——它到底算不算受 FDA 监管的医疗器械，完全取决于它是否满足特定的法定标准。

《21世纪治愈法案》（21st Century Cures Act）对 FD&C Act 进行了修订，增加了第520(o) 条。该条款明确规定，如果某些软件功能同时满足四项特定标准，就可以被排除在医疗器械的定义之外，从而免受 FDA 监管。

根据 FDA 发布的 CDS 最终指南，要成为豁免的“非器械CDS（Non-Device CDS）”，软件功能必须同时满足以下全部四个条件（缺一不可）：

如果软件功能满足上述所有四个标准，它就被视为“非器械 CDS”，不在 FDA 监管范围内。但如果未能满足其中任何一项，它就仍然受监管的医疗器械软件。

对于目前的 SaMD 制造商来说，这既是机遇也是挑战。许多基于深度学习和人工智能（AI/ML）的产品往往折戟于第 4 项标准。因为深度学习模型往往是“黑盒（Black Box）”，医生无法知晓算法是如何得出某个诊断建议的（即无法“独立审查依据”）。因此，大多数现代 AI 诊断辅助软件都被 FDA 归类为受监管的医疗器械。

如果您正在开发旨在支持临床决策的软件，及早根据这四项标准进行严格评估，可以帮助您准确界定产品属性，避免在准备 510(k) 申报时才突然发现自己走错了路线。

延伸推荐

如您持续关注中国医疗器械出海美国，欢迎关注Protheragen 服务号，获取更多 FDA 合规干货和实操指南。

点击  Protheragen

将视线转向欧洲。

在欧盟，SaMD 受欧盟医疗器械法规（EU MDR）或体外诊断医疗器械法规（EU IVDR）的监管。欧盟不使用 SaMD 这个词，而是统称为“医疗器械软件”（Medical Device Software, MDSW）。

其风险分类系统与传统设备相似：分为Class I、Class IIa、Class IIb 和 Class III。

使欧盟软件分类系统独树一帜、也让无数企业头疼的，是欧盟 MDR 附件 VIII 中著名的规则 11（Rule 11）。Rule 11 专门为医疗器械软件提供了具体的分类逻辑：

对于计划进入欧洲市场的制造商而言，欧盟委员会发布的MDCG 2019-11和 MDCG 2021-24行业指南是必读的圣经，其中详细解释了如何应用 Rule 11 的各种边界情况。

国际医疗器械监管机构论坛（IMDRF）也开发了一套独立的软件风险分类框架。虽然 IMDRF 本身不是一个具有执法权的监管机构，但它的成员包括了全球最大的医疗器械市场代表（美国、欧洲、加拿大、澳大利亚、日本、中国、巴西等）。IMDRF 致力于加速国际监管趋同，其工作组对全球法规的走向具有深远的指导意义。

IMDRF 的 SaMD 分类系统采用二维矩阵模型，分为四个类别（Category I 到 IV）：

结合这两个维度，可以矩阵化地将软件分为 Category I（风险最低，如非严重状况的参考信息）到Category IV（风险最高，如危急状况下的治疗/诊断决策）。

通往欧盟合规的桥梁

IMDRF 分类通常不作为单一国家的直接法定分类系统。但它的巨大价值体现在欧盟合规上——前文提到的欧盟官方指南 MDCG 2019-11 中，专门包含了一张将 IMDRF 类别映射到欧盟 MDR 风险等级的对照表。

图源：health.ec.europa.eu

如果您是第一次面对晦涩难懂的 Rule 11，强烈建议您先通过 IMDRF 框架理清您软件的业务逻辑和风险底线，再将结果代入欧盟的特定标准中，这会极大理顺您的分类思路。

跳出纯粹的行政法规监管圈，我们必须谈谈工程师团队最熟悉的标准：IEC 62304《医疗器械软件 - 软件生命周期过程》。这不仅是一项国际标准，更是 FDA 认可的共识标准，遵循该标准被公认为满足软件安全合规的最佳实践。

IEC 62304 根据软件故障可能造成的伤害严重程度，设立了三个“软件安全级别（Software Safety Classification）”：

准确理解 IEC 62304 的定位至关重要。IEC 62304 下的安全分类，并不是用来判断您的软件最终有多“安全”的，而是用来决定您的软件研发生命周期（SDLC）需要有多么严苛的。

分类越高，您需要执行的开发流程、架构设计、单元测试、集成测试、缺陷跟踪和验证活动就越繁杂。实际设备的安全性取决于您扎实的设计和开发过程，而不仅仅是一个分类标签。

千万记住，IEC 62304 的安全级别并不直接对应于 FDA 或欧盟的风险等级。虽然两者具有很强的相关性（例如，一个 Class C 的软件很可能在美国或欧盟都是Class III 高风险设备），但完全有可能出现这样的情况：

您的软件在IEC 62304 下因为某个潜在的严重故障点被定为 Class C，需要极其严谨的开发代码，但在 FDA 监管层面，通过综合风险控制后，它只被认定为Class II 设备。这两种判定是使用不同标准独立进行的。