AI医疗器械注册审查实操手册（工程团队版）
第三章 验证、确认与技术考量
3.1 软件验证
监管要点清单
- 通过提供客观证据认定软件开发/更新某一阶段的输出满足输入要求
- 软件验证测试：单元测试、集成测试、系统测试
- 设计评审等系列活动
- 基于软件需求开展，作为软件确认的基础
审评员视角 你的代码测过吗？怎么测的？是不是只在Jupyter Notebook里跑通就交了？
正经方案
- 单元测试：对数据预处理模块、模型推理模块、结果后处理模块分别写单元测试。预处理模块测试DICOM读取、窗宽窗位调整、重采样；推理模块测试输入输出尺寸一致性、数值范围；后处理模块测试阈值分割、连通域分析。用pytest跑，覆盖率至少写到核心函数，附覆盖率报告。
- 集成测试：测试模块之间的接口。预处理输出 → 模型输入尺寸是否匹配？模型输出 → 后处理输入数据类型对不对？异常输入（空图像、尺寸不匹配、像素值溢出）能不能被优雅处理？
- 系统测试：端到端跑完整流程。准备10-20张覆盖正常、边界、异常三种情况的测试图像，验证从输入到最终输出报告的全链路。记录每张图像的处理时间、内存占用、输出结果。
- 设计评审：保留评审记录，包括评审时间、参与人员、评审结论、待办事项。哪怕是自己团队内部过一遍，也要写个纪要签字。
交差版
- 单元测试写5个核心函数的test case，pytest跑通截图。
- 集成测试写一段文字：“经测试，各模块接口匹配，数据处理流程正常。”
- 系统测试用10张图跑一遍，记录平均推理时间，写"系统运行稳定"。
- 设计评审附一张会议签到表和一页评审结论。
核心原则 软件验证不是做给审评员看的表演，是确保你的代码在换了环境、换了数据、换了操作者之后还能稳住的底线。没有单元测试的AI项目，和手工记账的小作坊没有本质区别。
3.2 软件确认
监管要点清单
- 通过提供客观证据认定软件满足用户需求和预期目的
- 软件确认测试（用户测试）
- 临床评价
- 设计评审
- 可单一使用，亦可组合使用
- 用户测试由预期用户在真实或模拟使用场景下开展
- 亦可基于测评数据库开展
审评员视角 你的软件真的好用吗？医生用起来顺不顺手？在真实医院里跑过没有？
正经方案
- 用户测试：找目标用户（放射科医生、技师）在模拟或真实场景下使用。记录任务完成时间、错误率、用户满意度问卷（可用SUS系统可用性量表）。重点观察用户会不会误读输出结果、会不会忽略警示信息、会不会在紧急情况下操作失误。
- 测评数据库确认：如果没有条件做大规模用户测试，可用符合要求的测评数据库（见3.9）作为确认测试的一部分。但需说明为什么这个数据库能代表真实用户需求。
- 设计评审：从用户角度评审界面设计、交互流程、错误提示、帮助文档。特别关注算法输出结果的呈现方式——医生看到一个"恶性概率87%"，能不能理解这个数字的含义和局限？
交差版
- 用户测试找3-5个医生试用半天，填个简易问卷，写"用户反馈良好，操作便捷"。
- 如果没做用户测试：写"本产品基于测评数据库开展软件确认测试，符合预期用户需求。"
核心原则 确认是证明软件"好用"，验证是证明软件"没错"。两个都不可或缺。AI模型准确率再高，如果医生看不懂输出或者不愿意用，等于零。
3.3 临床评价路径
监管要点清单
- 非辅助决策类功能：基于核心功能开展同品种医疗器械比对
- 辅助决策类功能：基于核心算法开展同品种医疗器械比对，所选同品种临床证据原则上需基于临床试验（含回顾性研究）
- 全新的功能、算法和用途原则上均需开展临床试验
- 开展算法性能比较分析，若各类测试场景性能变异度较大，需详述原因并明确使用限制
审评员视角 你是第一个做这玩意的吗？如果不是，跟已上市的产品比怎么样？如果是，凭什么不做临床试验就想上市？
正经方案
- 同品种比对：找已上市的同品种产品（进口或国产），对比预期用途、适用人群、核心功能、核心算法、性能指标。收集同品种的临床文献、临床试验报告、不良事件数据。证明你的产品在安全有效性上不低于同品种。
- 临床试验：若找不到合适同品种，或你的产品属于"全新"，则需开展临床试验。AI医械的临床试验可以是前瞻性研究，也可以是高质量的回顾性研究（用历史数据但按临床试验方案设计）。关键指标根据产品类型定：辅助决策类通常用敏感性/特异性与金标准对比；非辅助决策类可能用图像质量评分、诊断一致性等。
- 回顾性研究设计：若走回顾性，需预先制定研究方案（纳入排除标准、金标准定义、样本量计算、统计分析方法），然后从医院病历系统或影像系统中按方案提取数据。不能先看了数据再写方案，那是数据挖掘不是临床研究。
- 算法性能比较：若在A医院测试敏感性95%，在B医院只有85%，必须分析原因（设备差异？病种差异？图像质量差异？）并写进报告，不能藏着掖着。
交差版
- 同品种比对：找1-2个已上市产品，做一张功能对比表，结论写"本产品与同品种在安全有效性方面实质等同"。
- 回顾性研究：写个简单方案，从一家医院提100例数据跑一遍，附ROC曲线。
- 临床试验：如果没有做，写"本产品属于全新算法，计划开展临床试验，当前版本仅用于科研用途。"
核心原则 临床评价的核心是证明你的AI在真实临床场景下对患者有好处或者至少没坏处。回顾性研究省钱但方案必须预先定好，不能事后诸葛亮。
3.4 算法性能综合评价
监管要点清单
- 结合算法训练、算法性能评估、临床评价等结果开展综合评价
- 针对训练样本量和测试样本量过少、测试结果明显低于设计目标、算法性能变异度过大等情况，对产品适用范围、使用场景、核心功能进行必要限制
审评员视角 把所有测试结果串在一起看，你的模型到底行不行？不行的话，哪些场景要划掉不能用？
正经方案
- 写一份《算法性能综合评价报告》，汇总训练集/调优集/测试集样本量、测试环境、性能指标、亚组分析结果、压力测试结果、对抗测试结果、临床评价结果。
- 若测试样本量不足（比如某亚组只有20例），明确限制"本产品当前版本不适用于该亚组，后续将补充数据并更新"。
- 若不同测试场景性能差异大（比如三甲医院95%、县级医院80%），分析原因并限制"建议在符合XX标准的设备上使用"或"建议由中级以上职称医师复核"。
- 若训练样本量相对同类产品偏少，可写"训练样本量虽少于文献报道的XXX研究，但通过数据扩增和迁移学习，模型已达到预设性能目标，后续将持续补充真实世界数据"。
交差版
- 汇总页：一张大表格，列训练集/测试集样本量、AUC、敏感性、特异性。
- 限制页：写"本产品建议在XX条件下使用，不适用于YY情况。"
核心原则 综合评价是"兜底"环节。前面每一章的测试结果在这里汇总，有矛盾的地方要解释，有短板的地方要承认并限制。审评员最怕的是你明明有漏洞却不自知。
3.5 注册单元与检测单元
监管要点清单
- 人工智能独立软件、软件组件分别参照独立软件、软件组件要求
- 若核心功能相同但核心算法类型不同，每类核心算法所对应的核心功能均需检测
- 检测对象为核心功能而非核心算法
审评员视角 你要注册的是一个产品还是一堆产品？功能一样但算法不同，是不是每个都要测？
正经方案
- 明确注册单元：如果你的产品只有一套算法、一个预期用途，就是一个注册单元。如果有多个算法对应不同功能（比如肺结节检测和骨折检测），需拆分成不同注册单元，或把次要功能降为"非核心功能"。
- 检测策略：核心功能相同、算法类型不同（比如一个用CNN、一个用Transformer），每类算法对应的输出都需要测，但测试重点是功能输出（能不能检出结节），不是算法内部差异。
- 若产品含多个算法模块，写明每个模块的核心功能、算法类型、所属注册单元。
交差版
- 写"本产品为一个注册单元，核心功能为肺结节辅助检测，采用单一深度学习算法实现"。
- 若有多个算法：写"本产品包含两个核心功能模块，分别采用不同算法实现，已按指导原则要求分别开展检测"。
核心原则 注册单元拆分直接影响检测成本和时间。核心功能越少、算法类型越单一，注册越简单。别为了炫技把七八个算法塞进一个产品。
3.6 网络安全与数据安全
监管要点清单
- 基于保密性、完整性、可得性确定网络安全能力建设要求
- 应对网络攻击和数据窃取，如算法编程框架漏洞攻击、数据污染
- 数据转移：明确转移方法、数据污染防护措施、数据销毁要求
- 内部活动需在封闭或受控网络环境下开展
- 外方活动需明确数据污染防护措施
- 数据库需备份，明确方法、频次、恢复方法
- 上市后使用需考虑医疗机构网络安全与数据安全接口要求
审评员视角 你的模型会不会被黑客篡改？数据在传输过程中会不会泄露？医院的信息科能不能接入你的系统？
正经方案
- 框架漏洞：定期跟踪PyTorch/TensorFlow安全公告，建立漏洞响应流程。注册时提供当前版本已知漏洞扫描报告（可用依赖扫描工具如Snyk、Dependabot）。
- 数据传输：训练数据不出内网。若需跨机构传输，采用端到端加密（TLS 1.3）、分片传输、脱敏处理。写明数据在传输前后的完整性校验方法（如SHA-256哈希比对）。
- 数据销毁：写明模型退役或合同终止后，训练数据、模型权重、日志文件如何彻底删除（物理销毁存储介质或密码学擦除）。
- 网络隔离：训练服务器部署在医院内网或VPN隔离区，防火墙规则限制仅允许必要端口。外包标注的，数据脱敏后通过SFTP/加密邮件发送，接收回传数据时校验文件完整性。
- 备份策略：至少双备份，本地RAID阵列 + 异地备份。每周全量备份，每日增量备份。定期做恢复演练，记录恢复时间目标（RTO）和恢复点目标（RPO）。
交差版
- 写"本产品部署于医院内网，不与互联网直接连接，符合医疗机构网络安全要求"。
- 数据传输写"采用加密通道传输，确保数据保密性和完整性"。
- 备份写"每周全量备份，保留最近4个版本，支持数据恢复"。
核心原则 网络安全不是加把锁的事，是从数据产生到销毁的全流程设计。医院信息科会拿你的方案去跟他们的等保要求对表，对不上就不让进。
3.7 移动计算与云计算
监管要点清单
- 使用移动计算、云计算需遵循相关指导原则
- 移动计算见移动医疗器械指导原则
- 云计算见医疗器械软件指导原则
- 网络安全见医疗器械网络安全指导原则
审评员视角 你的软件跑在手机上？数据是不是存到境外云上了？
正经方案
- 移动计算：若产品需在平板/手机上运行（比如床旁超声AI），需考虑设备性能差异、电池续航、屏幕尺寸对图像显示的影响、离线/在线模式切换。提供在不同型号设备上的性能测试报告。
- 云计算：
- 服务模式：IaaS/PaaS/SaaS分别对应不同责任边界。IaaS你自己管操作系统以上，PaaS云厂商管到容器/运行时，SaaS几乎全托管。写清楚你和云厂商各自的安全责任。
- 部署模式：公有云（阿里云、腾讯云）、私有云（医院自建）、混合云。医疗数据上公有云需确认服务商通过等保三级/四级、具备互联网医院或医疗云资质。
- 地域：服务器必须在中国大陆境内，不能走AWS Tokyo或Azure US East。写明数据中心具体城市和机房。
- 云服务商资质：营业执照、ICP证、IDC/ISP证、等保证书、医疗器械软件相关资质（如有）。
交差版
- 没用移动计算和云计算：写"本产品为本地部署的独立软件，未采用移动计算和云计算技术。"
- 用了云计算：写"本产品采用XX云公有云服务，服务器部署于中国大陆境内（XX地域），云服务商具备等保三级认证。"
核心原则 云计算在医疗AI里越来越普遍，但监管对数据出境和云厂商资质极其敏感。选云服务商的时候，先让他们把资质证书打包发你，别等注册的时候才想起来要。
3.8 人因与可用性
监管要点清单
- 建议加强人因设计以提升可用性
- 将用户错误使用的风险降至可接受水平
- 特别关注软件用户界面
审评员视角 医生用你的产品会不会点错按钮？能不能看懂你画的热力图？晚上值班光线不好会不会误读？
正经方案
- 界面设计：遵循医疗软件UI规范，关键信息突出显示（如恶性高风险用红色警示），次要信息弱化。字体大小在24寸显示器和14寸笔记本上都清晰可读。
- 错误防护：对高风险操作（如确认诊断、导出报告）加二次确认。算法输出结果旁边附置信度说明和适用范围提示，防止医生过度信赖。
- 可用性测试：找5-10名目标用户（不同年资、不同科室）完成典型任务（上传图像、查看结果、生成报告、导出数据），记录操作时间、错误次数、用户主观评价。用SUS量表打分，70分以上算可用。
- 人因分析：按IEC 62366做可用性工程过程，识别潜在使用错误（如将辅助决策结果当作最终诊断、忽略系统提示的图像质量警告），设计风险缓解措施。
交差版
- 写"本产品用户界面经过优化设计，关键信息突出显示，操作简便直观"。
- 附3-5张UI截图，圈出主要功能区域。
- 如果有用户反馈：写"经X名医生试用，反馈界面清晰、操作便捷"。
核心原则 人因设计在AI医械里被严重低估。再准的模型，如果医生不知道怎么用、不敢用、不愿用，就是废品。特别是辅助决策类产品，输出结果的呈现方式直接影响医生的信任度和使用行为。
3.9 第三方数据库与测评数据库
监管要点清单
- 第三方数据库可用于算法性能评估，但未必满足软件确认测试要求
- 用于软件确认测试的第三方数据库即为测评数据库
- 测评数据库专用要求：
- 权威性：由临床专业领域权威机构负责采集和标注
- 科学性：真实数据，不得扩增；样本分布符合流行病学特征；样本总量基于统计学指标
- 规范性：数据管理和质控符合要求
- 多样性：多中心、多设备、多人群
- 封闭性：封闭管理，样本总量远大于单次抽测量，测评活动封闭开展
- 动态性：定期补充完善，算法更新后需重新评估
审评员视角 你说你在XX公开数据集上跑了SOTA，这个数据集能用来证明你的产品安全有效吗？
正经方案
- 第三方数据库用于性能评估：可以用来做横向对比（“我们的模型在NIH ChestX-ray上AUC达到0.94，优于文献报道的0.91”），但不能替代软件确认测试。需说明数据库的来源、样本量、标注质量、伦理审批情况。
- 测评数据库用于确认测试：如果要作为确认测试的一部分，必须满足六条专用要求。国内目前符合要求的测评数据库很少，主要是国家临床医学研究中心牵头建设的专病数据库。如果用了，需获取数据库管理方的授权使用协议，并确认数据库的封闭性（你没提前看过测试集）。
- 自建测评数据库：如果找不到合适的第三方测评数据库，可以自建，但需满足六条要求。自建的成本很高，需要多中心采集、独立标注团队、封闭管理流程。
交差版
- 公开数据集（如NIH ChestX-ray、MIMIC-CXR）：写"本产品在NIH ChestX-ray公开数据集上进行算法性能对比评估，该数据集仅用于横向性能比较，不作为软件确认测试依据。"
- 测评数据库：写"本产品基于XX测评数据库开展软件确认测试，该数据库满足封闭性、科学性等专用要求。"
- 什么都没有：写"本产品当前版本基于自有测试集开展算法性能评估和软件确认测试，后续将接入权威测评数据库进行进一步验证。"
核心原则 公开数据库是"参考分"，测评数据库是"高考分"。审评员认的是后者。在测评数据库生态还没完全成熟的时候，先用自有测试集把其他材料做扎实，别指望靠公开数据集蒙混过关。