德大医查
(全球医械资源查询平台)
04
人工智能与数字健康
数字健康医疗器械进入注册实战期:
从软件、数据到临床证据,申请人该如何提前布局?

数字健康产品从“概念验证”进入“注册实战”后,申请人首先要回答的不是产品是否足够创新,而是:产品是否属于医疗器械?按几类管理?软件、数据、算法和临床证据能否支撑注册申报?本文适合作为数字健康医疗器械注册系列开篇,帮助项目团队在立项早期建立合规判断框架。

数字健康不是监管空白,关键看是否触及医疗用途

过去几年,远程监测、慢病管理软件、AI辅助诊断、数字疗法、可穿戴设备、院内数据分析平台等数字健康产品持续升温。很多项目在商业计划中被描述为“健康管理工具”或“数据服务平台”,但在注册实务中,监管判断并不取决于产品是否以App、云平台或算法模型呈现,而取决于产品的预期用途和风险影响。

根据《医疗器械分类规则》,医疗器械分类应结合产品结构特征、使用形式、使用状况等因素综合判定;对于数字健康产品而言,如果其功能已经涉及疾病诊断、治疗、监测、辅助决策或康复干预,就需要谨慎评估是否进入医疗器械监管范围。

因此,数字健康产品注册的第一步,不是急于准备申报资料,而是先把产品属性、适用场景、输出结果和临床使用边界讲清楚。

判断是否“入械”,不能只看产品是不是软件

很多申请人在早期容易把“软件产品”和“医疗器械软件”混为一谈。实际上,同样是软件,若仅用于健康科普、生活方式记录、普通信息展示,通常与医疗器械注册的关联较弱;但若软件用于医学图像分析、病灶识别、生命体征监测、疾病风险提示、治疗计划推荐或辅助医生作出诊疗判断,就可能被纳入医疗器械监管。

国家药监局发布的《人工智能医用软件产品分类界定指导原则》提出,基于医疗器械数据、采用人工智能技术实现医疗用途的独立软件,可参考该原则开展分类界定。对于算法成熟度低且用于辅助决策的人工智能医用软件,如提供病灶性质判定、用药指导或治疗计划制定等建议,通常按第三类医疗器械管理;用于非辅助决策、提供临床参考信息的,可能按第二类医疗器械管理。

换句话说,数字健康项目要重点回答三个问题:处理的是否为医疗相关数据,输出结果是否服务于医疗目的,输出结果是否会影响医生或患者的诊疗行为。

数字健康产品是否进入医疗器械监管范围判断路径图

01

明确产品功能

预期用途、用户对象、使用场景

02

判断医疗用途

是否用于诊断、监测、治疗、康复或辅助决策

03

识别数据来源

是否使用医疗数据、医疗器械数据或患者特异性信息

04

评估输出影响

输出是否影响临床判断或患者行为

05

对照监管依据

分类目录、指导原则、同类获批产品、必要时分类界定

输出结论:形成“产品属性判断 + 管理类别初判 + 注册路径 + 临床评价策略 + 软件/数据资料清单”

立项前风险提示

产品宣传口径可以强调创新,但注册申报口径必须克制、清晰、可验证。若预期用途写得过宽,可能抬高管理类别;若算法输出与临床决策关系表达不清,可能增加临床评价和发补压力。

注册实战中,最容易被忽略的是“边界描述”

数字健康产品常见的合规风险,不是没有功能,而是功能边界过宽、使用场景不清、输出结果过度承诺。比如,一个影像软件如果仅用于图像显示、处理、测量,审评关注点主要集中在软件功能、性能验证、数据准确性和风险控制;如果进一步声称能够识别病灶、判断性质或给出诊疗建议,就会进入辅助诊断或辅助决策的监管逻辑。

移动医疗器械也同样需要关注边界。国家药监局器审中心2025年发布的《移动医疗器械注册审查指导原则(2025年修订版)》提出,移动医疗器械是采用移动计算技术实现一项或多项医疗用途的医疗器械,其注册资料需要结合移动终端、网络连接、软件功能、数据传输和使用环境等因素进行系统说明。

因此,申请人应当在研发早期同步准备两套表达:一套面向市场沟通,突出产品价值;另一套面向注册申报,聚焦预期用途、适用人群、输入数据、输出结果、使用限制和风险控制。

软件、数据、算法,都是注册证据链的一部分

数字健康医疗器械的注册资料,通常不只是常规产品综述、产品技术要求、检验报告和风险管理资料。对于软件类医疗器械,申请人还需要围绕软件安全性级别、软件架构、功能模块、版本命名、开发过程、验证确认、缺陷管理、发布控制等内容形成可追溯资料。

如果产品涉及网络连接、远程维护、数据交换、云端部署或用户访问控制,还需要同步考虑网络安全研究资料。若产品含有人工智能算法,则证据链还会进一步延伸到训练数据、测试数据、标注规则、算法性能、泛化能力、偏倚控制、适用人群覆盖以及算法更新管理。

数字健康医疗器械注册资料前置准备清单

注册关注点申请人应提前准备常见风险

产品属性

产品功能、预期用途、适用人群、用户对象、使用场景

把普通健康管理功能写成疾病诊断或治疗功能

分类管理

对照分类目录、分类界定指导原则、同类获批产品

仅凭竞品宣传判断类别,忽略具体适用范围差异

软件研究

软件架构、模块说明、版本规则、验证确认、缺陷管理

软件版本、测试报告和注册资料无法追溯对应

数据治理

数据来源、数据质量、标注规则、代表性、隐私合规

训练/测试数据来源不清,标注一致性不足

算法研究

性能指标、泛化能力、偏倚分析、适用边界、更新策略

只展示算法准确率,缺少临床适用边界说明

网络安全

访问控制、数据传输、远程维护、漏洞响应、用户权限

忽略云端部署、接口调用和远程更新带来的风险

临床评价

免临床评价、同品种评价、临床试验路径初判

申报前才发现缺少可用临床证据或同品种数据


临床评价不是申报前才考虑的“最后一步”

数字健康医疗器械是否需要临床评价,不能等注册申报前才判断。国家药监局2021年第73号通告发布了医疗器械临床评价技术指导原则、决策是否开展医疗器械临床试验技术指导原则、等同性论证指导原则和临床评价报告指导原则等文件,为第二类、第三类医疗器械临床评价路径提供了基础框架。

对部分功能明确、风险相对可控、已有充分同类产品和临床数据支持的产品,申请人可能通过免于临床评价目录、同品种临床评价、文献数据和非临床验证构建临床证据。但对于辅助诊断、辅助决策、治疗干预、算法模型创新明显或适用人群差异较大的产品,临床评价压力会显著增加,甚至可能需要开展注册临床试验。

这也是数字健康产品注册和传统硬件类产品最大的差异之一:证据链不仅来自产品性能测试,也来自数据、算法和临床场景之间的匹配关系。申请人需要证明产品在明确适用范围内安全、有效、可控,而不是笼统证明“模型表现较好”。

从“产品能做什么”转向“证据能证明什么”

数字健康医疗器械进入注册实战期后,项目团队需要完成一个重要转变:不再只围绕产品功能做研发叙事,而是围绕注册证据链组织研发、临床和质量管理工作。

研发端应把软件版本、算法迭代、数据来源、风险控制纳入设计开发过程;注册端应尽早完成属性判断、分类路径和申报资料清单设计;临床端应提前判断临床评价可行性;质量体系端则需要覆盖软件生命周期、数据管理、网络安全、上市后变更和不良事件监测。

对德大医学而言,数字健康医疗器械项目的支持重点,并不是简单代写注册资料,而是协助申请人在项目早期完成关键判断:产品是否属于医疗器械、可能按几类管理、注册路径如何设计、软件研究资料如何梳理、临床评价证据是否充分,以及是否需要进一步开展临床试验或监管沟通。

数字健康的产业机会仍在扩大,但注册合规的窗口期已经前移。越早把软件、数据、算法和临床证据纳入同一条注册证据链,项目后续的审评不确定性越低,产品上市路径也越清晰。

德大医学可提供的项目支持

围绕数字健康医疗器械、软件类医疗器械、AI医疗器械等项目,德大医学可协助完成产品属性判断、分类界定咨询、注册路径设计、临床评价策略、软件研究资料梳理、网络安全资料准备、同品种评价与注册申报资料整合,帮助申请人在研发早期识别合规风险。

免费咨询