【洞见提升】软件如何被界定为医疗器械,以及其如何获得MDR认证?

软件的特殊性

软件与传统医疗器械的一个关键区别在于：软件的变化速度极快。版本发布、补丁更新、云环境、用户界面、人工智能功能以及网络安全风险，都是其生命周期中的自然组成部分。MDR 已将这一点纳入考量。对于软件而言，附录 I（Annex I）要求包括但不限于：在开发生命周期、风险管理、验证与确认等方面采用“当前技术水平”（state-of-the-art），并对硬件、信息技术网络以及防止未授权访问提出最低要求。因此，网络安全不再是次要的IT问题，而是产品安全性与性能的重要组成部分。

在软件领域，真正决定其属性的关键并非代码本身，而是其医疗目的。一款健康类应用程序并不会仅因为其技术复杂就被认定为医疗软件；相反，如果某个看似简单的应用程序，其信息被用于诊断或治疗决策，那么它很可能会被纳入 MDR 的监管范围。现行MDCG 2019-11指南（MDCG Guidance）中关于软件资格认定与分类明确阐释了这一差异。

MDR中的各项要求——应从何处查阅？

任何希望在 MDR框架下将软件投放市场的主体，都应仔细研读MDR法规的相关条款。其中最为重要的部分包括：

附录 I（Annex I），规定了通用安全与性能要求。对于软件而言，关于开发流程、风险管理、信息安全、验证以及 IT 环境的相关要求尤为关键。

附录 II 和附录 III（Annexes II and III）对技术文件以及上市后监督的相关要求做出了规定。对于软件而言，这还包括作为产品技术文件组成部分对软件验证与确认的证据。

附录 VIII（Annex VIII），尤其是规则11（Rule 11），是医疗软件分类的核心依据。2025年修订的 2019-11 号 MDCG Guidance 对规则11的三项基本原则进行了说明：用于提供诊断或治疗决策信息的软件、用于监测生理过程的软件，以及“所有其他软件”。根据临床相关性的不同，其分类等级可涵盖I类、IIa、IIb和III类。

第 52 条（Article 52）以及附录 IX 至 XI（Annexes IX–XI）对符合性审核程序作出了规定。对于 I 类医疗器械，符合性声明通常由制造商自我声明；而对于 IIa 类及以上医疗器械，则必须由公告机构参与审核。

最后，附录 XIV（Annex XIV）是临床评价（clinical evaluation）和上市后临床随访（Post-Market Clinical Follow-Up）的核心依据。尤其对于软件而言，这一体系往往可能未及时建立系统化机制。

医疗软件领域最重要的标准

MDR 规定了相关法规要求。然而，在实际实施过程中，一些标准尤为重要，因为它们界定了“当前技术水平”（state of the art）。

IEC 62304 是医疗软件生命周期管理的核心标准。该标准规定了当软件本身属于医疗器械，或作为医疗器械组成部分时，其开发与维护过程中应遵循的相关流程。

ISO 14971是医疗器械风险管理的核心参考标准，其适用范围明确涵盖作为医疗器械的软件。

ISO 13485 是贯穿医疗器械整个产品生命周期的核心质量管理标准。对于希望建立稳健且符合MDR要求的组织体系的制造商而言，该标准构成了实际运营层面的基础。

IEC 62366-1 涵盖了可用性工程相关要求。这对于软件尤为重要，因为错误操作、误导性的用户引导或不清晰的警报信息，都可能立即引发安全风险。

IEC 82304-1 尤其适用于运行于通用 IT 平台上的健康软件，即不依赖专用硬件的产品。该标准从产品层面对安全性与信息安全提出了要求，因此对于许多独立软件产品或作为医疗器械软件（SaMD）具有重要意义。尤其值得注意的是，IEC 82304-1 对作为医疗器械的软件（SaMD）的确认提出了明确要求，同时该标准也被已在 MDR 下协调采用的 IEC 62304 所引用。

医疗器械分类：关键第一步

最常见且最关键的首要问题是：我的软件应归属于哪一类别？许多项目恰恰在这一环节失败——问题并不在于技术本身，而在于预期用途界定不清。根据 MDCG 2019-11 Rev.1，规则 11（Rule 11）的适用主要取决于软件是否用于提供诊断或治疗决策相关信息、监测生理过程，或是否属于剩余类别（residual category）。指南中的示例表明，用于诊断或治疗支持的软件很容易被划分为 IIa、IIb 甚至 III 类，而“所有其他软件”则归为 I 类。

从公告机构的角度来看，有一点非常明确：分类并不是产品上市流程末端的行政性步骤，而是整个市场准入策略的起点和基础。它不仅影响临床证据的范围、技术文件的深度以及 PMS/PMCF 的要求，还直接关系到是否需要公告机构参与，以及其参与的程度。

临床数据：临床证据是实现合规不可或缺的基础

对于医疗软件而言，临床证据并非“可有可无”的附加项。MDCG 2020-1 明确指出，具有独立预期用途并宣称具备临床受益的医疗软件，在其符合性审核过程中必须提供临床证据。其目的在于证明：该软件具有安全性、能够实现其预期性能，并可提供其所宣称的临床受益。

在实践中，这对于软件而言意味着：仅仅证明算法在技术层面能够运行是远远不够的。还必须评估该软件在临床环境中是否能够提供正确的信息，这些信息将如何被使用，以及其是否真正能够带来可验证的临床受益。临床评价并非一次性的文件，而是一个持续进行的过程。

上市后临床随访 (PMCF)

在软件领域，上市后临床随访（Post-Market Clinical Follow-Up）往往容易被低估。MDR将 PMCF 定义为一个持续性的过程，其目的在于不断更新临床评价，并且必须纳入制造商的上市后监督（PMS）计划之中。MDCG 2020-7 PMCF Template 正是对此作出了明确说明。

PMCF对软件尤为重要，因为其使用场景、操作系统、用户界面、网络安全威胁以及临床使用模式都在不断变化。因此，制造商不仅需要建立完善的市场准入策略，还需要构建健全的体系，以便在产品上市后持续收集和评估真实世界中的性能与安全性数据，并将这些数据反馈至产品改进过程中。

从公告机构的角度来看，认证流程是如何开展的？

首先，必须对预期用途进行准确界定。只有在此基础上，才能明确判断该软件是否属于 MDR 的监管范围。

必须对软件进行正确分类，通常依据附录 VIII（Annex VIII）和规则 11（Rule 11）进行判定。

企业需要建立适当的质量管理体系，并采用可验证且符合当前技术水平（state-of-the-art）的开发流程。该体系通常基于 ISO 13485、IEC 62304、ISO 14971 等标准，并可根据具体产品适用其他相关标准。

技术文件必须完整、结构清晰且具有可追溯性，其中还应包括软件验证（verification）与确认（validation）的相关内容。

临床评价、上市后监督（PMS）以及上市后临床随访（PMCF）必须依据产品特点建立适当的体系结构。

若产品分类要求公告机构参与，则应依据 MDR 所规定的程序开展正式符合性审核。

总结

任何希望成功将软件作为医疗器械投放市场的企业，所需要的不仅仅是优秀的开发人员和创新理念。真正关键的是：清晰的预期用途、正确的产品分类、健全的开发与风险管理流程、充分的临床证据，以及能够支持PMCF的上市后体系。而这也正是普通“数字健康产品”与真正具备医疗合规性的软件之间的本质区别所在。

从 DQS MED 等公告机构的角度来看，制造商越早建立清晰的法规合规策略，整个认证流程就越高效。Dr. Andrei Ninu 现就职于 DQS MED，专注于有源医疗器械、软件安全以及医疗人工智能领域，并负责领导软件运营团队（Software Operations Group）。

您是否正在开发医疗软件，或计划为您的应用程序取得 MDR 认证？

建议尽早与 DQS MED 的专业团队沟通产品分类、临床证据以及法规要求等关键问题，以便更高效地推进符合审核定并顺利实现认证目标。

关于DQS