AI医疗器械注册审查实操手册（工程团队版）
第四章 注册申报：算法研究资料填写指南
4.0 先判断：你需要交多厚的作业？
监管原文要点
- 软件安全性级别为中等、严重：全新类型需提交完整算法研究报告（8个章节）；成熟类型只需明确算法基本信息
- 软件安全性级别为轻微：只需明确算法基本信息，无需算法研究资料
- 算法更新：需提交算法更新研究报告，涵盖自前次注册以来全部更新内容
监管为什么这样分层 NMPA不想把行政资源浪费在低风险产品上，也不想对高风险产品放手不管。“轻微级别只需基本信息"是给非辅助决策类工具开的绿灯——你只是个自动测量尺子，审你的算法细节意义不大。“全新类型/中高风险要8章"是因为审评员没见过你这类产品，需要完整证据链来建立信任。
核心原则 宁可按中等级别准备。级别判定的弹性很大，你觉得自己是轻微，审评员可能认为是中等。材料多了可以删，少了补起来要重走流程。
4.1 算法研究报告8章填写指南
第1章 算法基本信息
监管要求
- 算法名称、类型（学习策略、学习方法、可解释性）、结构（层数、参数规模）、输入输出、流程图
- 算法框架（名称、类型、型号规格、完整版本、制造商；若云计算需明确名称/服务模式/部署模式/配置/云服务商资质）
- 运行环境（硬件配置、外部软件环境、网络条件；若AI芯片需名称/型号/制造商/性能指标）
- 算法选用依据
监管为什么要求这个 这一章的本质是"你是谁，从哪来”。审评员拿到一份陌生的技术报告，首先要建立基本认知：这玩意用的是什么技术路线？跑在什么环境上？是不是用了境外云服务（数据主权问题）？选用依据是为了防止你拍脑袋——“为什么不用更成熟的方案？““为什么用这个黑盒？”
填写要点
- 算法名称要规范，建议格式：“基于深度学习的XX疾病辅助检测算法”
- 算法类型从三个维度描述：有监督学习、基于数据、黑盒算法
- 流程图用Visio或draw.io画，保存为矢量图插入报告
- 框架信息做成表格，附pip freeze或conda list截图
- 选用依据写半页到一页，引用2-3篇关键文献支撑
交差版
- 算法类型只写"深度学习”
- 流程图用PPT画三个框截图
- 选用依据写"该算法在ImageNet分类任务中表现优异，具有较好的特征提取能力”
核心原则 这章是给审评员画地图的。地图不清，后面再好的实验结果他也看不懂。版本号精确到patch级别，因为审评员默认你会在注册后偷偷升级。
第2章 算法风险管理
监管要求
- 明确软件安全性级别并详述判定理由
- 提供算法风险管理资料：过拟合与欠拟合、假阴性与假阳性、数据污染与数据偏倚的控制措施
- 若无单独文档，可提供软件风险管理资料并注明算法风险管理所在位置
监管为什么要求这个 风险管理是医疗器械QMS的灵魂。NMPA不关心你的模型在理想条件下多准，关心的是在最坏情况下会不会伤人。过拟合/欠拟合控制措施是为了确认你做过数据量和模型复杂度的平衡；假阴/假阳控制是为了证明你理解临床后果；数据污染/偏倚控制是为了排除系统性偏差。这三条覆盖了AI医械最常见的三类技术风险。
填写要点
- 软件安全性级别判定：结合预期用途（辅助决策vs非辅助决策）、使用场景（门诊vs急诊）、疾病严重程度（癌症vs皮肤病）综合论证
- 风险控制措施对应到具体章节：
- 过拟合/欠拟合 → 见第5章训练数据量-评估指标曲线、第6章压力测试
- 假阴性/假阳性 → 见第6章ROC曲线、混淆矩阵、亚组分析
- 数据污染 → 见第4章数据质控、封闭网络环境
- 数据偏倚 → 见第4章样本分布、第6章影响因素分析
交差版
- 级别判定写一页定性描述
- 风险控制措施列一张表：风险项-控制措施-对应章节
核心原则 风险管理不是写"我们有QA流程"这种空话，是把每个技术风险映射到具体证据。审评员看的是你"怕不怕”——如果你连自己的模型在什么情况下会失效都不清楚，凭什么让人放心用在病人身上？
第3章 算法需求规范
监管要求
- 提供算法需求规范文档
- 若无单独文档，可提供软件需求规范并注明算法需求所在位置
监管为什么要求这个 需求规范是整个可追溯链的起点。没有清晰的需求，后面所有设计、测试、风险控制都成了无源之水。审评员要通过需求规范判断：你一开始想解决的问题是不是你后来解决的问题？需求有没有被偷偷扩大（scope creep）？验收标准是不是过于宽松？
填写要点 这是最容易被AI团队忽略的部分。需求规范不是"我们要做个肺结节检测模型"，而是：
| 需求ID | 需求描述 | 验收标准 |
|---|---|---|
| REQ-001 | 系统应支持接收DICOM格式的胸部CT图像 | 成功读取符合DICOM 3.0标准的CT文件，层厚≤1.25mm |
| REQ-002 | 系统应自动检测肺结节并标记位置 | 检出直径≥3mm的实性结节，敏感性≥90% |
| REQ-003 | 系统应输出恶性风险概率 | 提供0-100%的恶性概率评分，保留一位小数 |
每个需求对应后面的设计、测试、风险控制，形成可追溯链。
交差版
- 写5-10条需求，覆盖输入、处理、输出、性能、安全
- 每条需求加一句验收标准
核心原则 AI团队最大的毛病是"边做边改需求"。在医疗器械监管里，需求一旦确定就是法律文件，变更要走流程。写需求规范不是为了给审评员看，是为了逼你自己想清楚：这个模型到底要解决什么？边界在哪？做到什么程度算完成？
第4章 数据质控
监管要求
- 数据来源合规性声明（机构名称、地域、收集量、伦理批件编号）
- 数据采集操作规范（设备、过程、脱敏）
- 数据整理情况（清洗、预处理）
- 数据标注操作规范（资源管理、过程质控、质量评估、安全保证）
- 数据扩增情况（对象、方式、方法、倍数）
- 各数据库疾病构成数据分布
- 公开数据库基本信息和使用情况
监管为什么要求这个 这是整份报告里审评员最不信任的部分。AI的黑箱特性决定了"Garbage In, Garbage Out"——数据有问题，模型再漂亮也没用。NMPA要求你证明数据是合法获取的（伦理批件）、质量是受控的（操作规范）、分布是清楚的（统计图表）、扩增是透明的（没偷偷造假样本）。
填写要点
- 数据来源合规性声明单独一页，附伦理批件扫描件
- 数据分布用表格+柱状图展示，按疾病类型、年龄段、性别、设备型号拆分
- 所有操作规范文档作为附件，正文里概述关键要点
交差版
- 合规声明一页
- 数据分布一张表
- 操作规范概述半页
核心原则 数据来源的合法性是红线，没有伦理批件一切免谈。数据分布的透明性是为了让审评员判断你的模型是不是在"偏科"——只在某类数据上训练得好，不代表在其他人群上也行。
第5章 算法训练
监管要求
- 训练集、调优集疾病构成数据分布
- 评估指标、训练方式、训练目标、调优方式
- ROC曲线或混淆矩阵等证据证明训练目标满足医疗要求
- 训练数据量-评估指标曲线证实训练充分性和有效性
监管为什么要求这个 这一章回答"你是怎么把模型练出来的"。审评员要看你的训练过程是不是科学：有没有用测试集作弊？目标设定有没有医学依据？数据量够不够？学习曲线是为了确认你没有"训练不充分"就交卷，ROC和混淆矩阵是为了确认你在训练阶段就锁定了合理的性能目标。
填写要点
- 数据分布同第4章格式
- 评估指标、训练方式、调优方式写成表格
- ROC曲线、混淆矩阵、学习曲线插入图片，图片需清晰可读，坐标轴标签完整
- 训练目标写明医学依据（如参考哪版指南、哪篇专家共识）
交差版
- 训练方式写"留出法7:1:2"
- 学习曲线跑3个点连一条线
- ROC曲线用matplotlib画一条线标个点
核心原则 训练阶段的目标是"确立一个可信的性能基线"。这个基线必须是在未见过测试集的情况下确立的，否则整个验证环节就失去了独立性。
第6章 算法验证与确认
监管要求
- 测试集疾病构成数据分布
- 假阴性/假阳性、重复性/再现性、鲁棒性/健壮性、实时性等评估结果
- 第三方数据库信息和使用情况（若适用）
- 算法性能影响因素分析报告（若适用）
- 压力测试、对抗测试报告（若适用）
- 测评数据库信息（若基于测评数据库确认）
- 临床评价资料（若基于临床评价确认）
- 各类测试场景算法性能比较分析
监管为什么要求这个 这是报告的"主菜"，前面所有章节都是为了支撑这一章。审评员在这里判断：模型在真实世界到底行不行？不同场景下表现一致吗？最差情况下会不会崩？影响因素分析是为了确认你了解自己的模型，不是把它当神供着。性能比较分析是为了横向对标——你的表现跟金标准、跟已上市产品差多少？
填写要点 建议结构：
- 测试集数据分布（同第4章格式）
- 主测试结果（混淆矩阵、敏感性、特异性、AUC）
- 亚组分析结果（不同设备、不同医院、不同病灶大小）
- 压力测试结果（罕见病例、特殊设备）
- 对抗测试结果（噪声、扰动）
- 影响因素分析（热力图或表格）
- 性能比较分析（与金标准、与已上市产品、不同场景对比）
- 使用限制和警示
每张图都要有图号、图题、数据说明。表格同上。
核心原则 验证与确认的本质是"用证据划定边界"。不是证明你的模型无所不能，是证明你知道它能干什么、不能干什么，并在不能干的地方竖起警示牌。
第7章 算法可追溯性分析
监管要求
- 追溯算法需求、算法设计、源代码（明确软件单元名称即可）、算法测试、算法风险管理的关系表
- 若无单独文档，可提供软件可追溯性分析报告并注明算法可追溯性分析所在位置
监管为什么要求这个 这是医疗器械QMS和AI工程之间最大的鸿沟。传统医疗器械的生产是线性的：需求→设计→采购→生产→检验→放行。每个环节都有记录，出了问题能往前倒查。AI项目的开发是迭代的、并行的、经常改需求的——但监管不认这个。可追溯性分析强制你把迭代过程"拉直"成一条线，证明每个需求都被设计实现了、每个设计都被测试覆盖了、每个风险都被控制住了。
正经方案：建立双向追踪矩阵
| 需求ID | 需求描述 | 设计文档章节 | 软件单元 | 测试用例 | 风险管理 |
|---|---|---|---|---|---|
| REQ-001 | 支持DICOM格式CT图像 | 3.1输入模块 | dicom_loader.py | TC-001 | RSK-001数据格式不兼容 |
| REQ-002 | 检出≥3mm肺结节 | 4.2检测算法 | nodule_detector.py | TC-005 | RSK-002漏诊风险 |
| REQ-003 | 输出恶性概率 | 5.1分类头 | classifier_head.py | TC-010 | RSK-003误诊风险 |
工具推荐
- Jira + Xray：需求管理+测试管理一体化，追踪链清晰
- IBM DOORS：医疗器械行业老牌ALM工具，贵但合规
- Polarion：Siemens出品，适合中小型团队
- Jama Connect：现代ALM工具，医疗器械领域应用广泛
- Git + GitHub/GitLab Issues + Milestone：低成本方案，用issue追踪需求，commit message关联需求ID，merge request关联测试报告
低成本落地方案（适合初创团队）
- 需求写在GitHub Issues里，每个需求一个issue，编号REQ-001
- 设计文档写在Wiki或Markdown里，章节号对应需求
- 代码提交时commit message写
feat: implement REQ-001 dicom loader - 测试用例写在pytest里，函数名或装饰器标记
@pytest.mark.req("REQ-001") - 风险管理写一张Excel，风险ID对应需求ID
- 定期导出GitHub Issues + commit log + test report + risk table，拼成可追溯性分析报告
交差版
- 画一张大表格，5列（需求-设计-代码-测试-风险）
- 填10-20条关键需求
- 代码列只写文件名，不用贴代码
核心原则 可追溯性不是 bureaucracy，是信任的基础设施。审评员默认你会犯错，可追溯性分析让他相信：即使你犯了错，也能找到错在哪、影响多大、怎么修。
第8章 结论
监管要求
- 简述算法性能综合评价结果
- 明确对产品适用范围、使用场景、核心功能的必要限制
- 判定算法或算法组合的安全有效性是否满足要求
监管为什么要求这个 前面七章是证据，这一章是论点。审评员看完几十页技术报告后需要一个"摘要"来锚定整体印象。你写的限制越具体，审评员越相信你有自知之明。如果你说"本产品适用于所有胸部CT检查"，审评员反而会觉得你疯了。
填写要点
- 半页到一页，不要重复前面的详细结果
- 用 bullet points 列3-5条核心结论
- 用 bullet points 列2-4条使用限制
- 最后一句话：“综上所述，本算法满足人工智能医疗器械安全有效性要求。”
交差版
- 结论写"经算法训练、验证与确认，本产品性能满足预设目标"
- 限制写"建议在XX条件下使用，不适用于YY情况"
- 最后一句判定
核心原则 结论的价值不在"我们很好"，而在"我们诚实"。敢于写明限制的产品，审评员反而更愿意给过；号称无所不能的，直接打回。
4.2 算法更新研究报告
监管要求
- 仅适用于再次发布
- 在算法研究报告基础上明确更新情况
- 涵盖自前次注册以来全部更新内容（累积效应）
监管为什么要求累积 AI模型是"养"出来的，每次数据增量、每次框架小升级、每次超参数微调都会改变模型行为。审评员怕的是"温水煮青蛙"——单次更新看起来轻微，累积起来模型已经面目全非。所以要求你把从上次注册以来的所有更新打包交代清楚。
填写要点
- 与首次注册的算法研究报告结构相同
- 每章开头加"更新说明"小节，用表格对比前次注册vs本次申报：
- 算法基本信息：有/无变化，变化内容
- 风险管理：有/无变化
- 数据质控：训练集从X例增加到Y例，新增数据来源Z医院
- 算法训练：框架从PyTorch 1.12升级到2.0（效率型更新）
- 验证与确认：新增压力测试/对抗测试
- 若某章无变化，写"本章内容与前次注册一致"
核心原则 更新报告的核心是"diff"——跟上次比，变了什么、为什么变、变完之后还安不安全。没有变化也要明确说"没变化"，留白等于可疑。
4.3 注册申报资料其他要点
产品注册
- 申请表：产品名称体现输入数据+目标疾病+预期用途（如"CT图像肺结节辅助检测软件"）
- 用户培训方案：严重级别、患者使用或基层医疗机构使用的产品需单独提供
- 产品技术要求：若含测评数据库测试指标，附录中明确测评数据库基本信息
- 说明书：必须写使用限制和警示；辅助决策类需写算法性能评估总结、临床评价总结、决策指标定义
监管为什么说明书要管这么细 说明书是上市后监管的重要抓手。审评员默认医生不会去看你的技术报告，但会看说明书。如果说明书里不写限制，出了事谁负责？辅助决策类要求写"决策指标定义"，是为了防止医生误读模型输出——比如把"恶性概率"当成"确诊"。
变更注册
- 按更新情况提交算法更新研究报告或完整算法研究报告
- 提交产品技术要求变更对比表（体现测评数据库变化）
- 提交说明书变化情况说明
延续注册
- 通常无需提交算法相关研究资料
- 除非注册证"备注"有特别要求
核心原则 注册申报不是"一次性"的，是从上市前到退市的全生命周期管理。每次变更、每次延续，都是在续一份技术债务的账单。