ARTICLE · 1149029
QMSR下,FDA再发警告信:AI软件,你以为只是“版本升级”,实际上已是“无证销售”
医疗软件更新，本来是一件很常见的事情。
增加一个AI算法、换一个技术架构、从桌面软件迁移到Web平台、升级第三方软件库等，从研发人员的角度看，可能只是一次“版本升级”。
但在FDA眼里，软件版本升级并不等于普通的软件更新。
2026年9月1日，FDA向某影像软件企业发出Warning Letter。
FDA在2026年3月12日至17日的现场检查中发现，该公司用于椎体骨折评估的某影像软件存在上市前申报、QMS以及MDR等多方面问题。
其中最值得关注的是：
一次软件升级，同时改变了AI算法、软件架构和技术平台，FDA认为这些变化可能显著影响安全性或有效性，因此应提交新的510(k)。
这封警告信，实际上给所有AI医疗软件企业提了一个醒：软件变更管理，已经不能只看“功能有没有变”，而要看“风险有没有变”。
不符合项1 | AI算法发生重大变化，却没有重新提交510(k)
FDA发现：
企业某影像软件此前通过510(k)获FDA批准，其功能是利用脊柱CT图像识别和评估椎体畸形、椎体骨折，并帮助识别未来骨质疏松性骨折高风险患者。
但在该软件更新版本中，公司增加了新的机器学习算法，用于椎体标志点定位。
FDA认为，新算法使用了不同的数据、算法架构或优化目标，可能导致其在不同患者群体、不同影像设备和不同临床环境下表现不同。
因此，这已经不仅仅是“代码优化”，而可能改变：
输入 → AI分析 → 输出 → 临床判断
整个链条。
FDA认为，该新功能可能显著影响器械的安全性和有效性，因此需要新的510(k)申报。
解读：
FDA关注的并不是“版本号从2.0变成3.0”，而是：
这个变化是否改变了器械的风险和临床表现？
尤其对于AI/ML医疗器械，如果重新训练模型、改变训练数据、改变模型架构或改变算法目标，都可能导致算法性能发生变化。
如果验证不足，可能出现：
漏诊或误诊； 结果缺失或延迟； 医生对AI结果产生错误理解； 过度依赖软件输出，导致错误的患者管理。
所以，AI模型变更本身就可能成为重新申报的触发因素。
启示：
企业不能简单采用：
“没有增加新的intended use，所以不用提交510(k)。”
而应该建立更加系统的Software Change Assessment：
变更内容 → 是否影响算法 → 是否影响性能 → 是否影响风险 → 是否影响临床解释 → 是否需要新的510(k)。
不符合项2 | 从桌面软件迁移到Web平台，也可能需要重新申报
FDA发现：
该软件新版本不仅改变了AI算法，还将软件从Desktop Application迁移到了Web-based Architecture。
FDA特别指出，Web架构会增加：
网络攻击面； 身份认证风险； 网络环境相关风险； Cybersecurity风险。
公司自己也承认，这一变化扩大了软件的“cyberattack surface area”。
FDA因此认为，该变化本身就可能显著影响安全性或有效性，需要新的510(k)。
解读：
这释放出一个非常重要的监管信号：
软件架构变化，也可能属于“Regulatory Significant Change”。
例如：
Desktop↓Web↓Cloud↓SaaS
表面上只是技术架构升级，但实际上可能改变：
数据流、网络连接、身份认证、访问控制、攻击面、数据完整性以及系统失效模式。
因此，软件企业不能只做“功能回归测试”，还需要重新评估：
Cybersecurity Risk + Software Risk + Clinical Risk。
不符合项3 | 技术平台变化，却没有充分进行重新验证&确认
FDA发现：
该版本还进行了技术平台迁移。
FDA认为，这种变化涉及整个软件代码库的重新验证&确认，包括：
软件代码； 第三方软件库； 软件依赖项； 第三方组件。
同时，FDA指出，在检查时没有审查到相关的Software Bill of Materials（SBOM）以及受影响第三方组件的相关文件。
解读：
对于医疗软件而言：
“代码能运行”≠“医疗器械已经完成验证&确认”。
底层平台、开发环境、第三方组件发生变化，都可能产生新的风险。
尤其当软件涉及AI、云平台和第三方软件包时，企业需要能够回答：
用了哪些组件？哪些组件发生变化？变化会影响什么？有没有重新验证？风险有没有重新评估？
这也是为什么SBOM越来越重要。
不符合项4 | CAPA整改拖了一年半，FDA认为“纠正措施不能慢”
FDA发现：
FDA发现，公司CAPA管理存在明显问题。
例如，CAPA-0080中，有4项已经确定需要采取的程序更新，竟然超过一年半没有完成。
另外，公司已经连续三年发现某软件需要更新，但直到FDA检查开始前一天，才建立CAPA-0088，而且当时：
没有签字，也没有确定或启动纠正措施。
解读：
FDA关注的不是“有没有CAPA编号”，而是：
CAPA有没有真正解决问题，而且是否及时解决？
另外，公司将CAPA触发条件进行了收窄，把部分“individual and sporadic instances”允许通过普通ticket处理。
FDA认为，这可能导致企业没有根据风险及时启动CAPA。
启示：
CAPA不是“问题登记系统”。
一个有效的CAPA体系至少应该回答：
为什么发生？是不是系统性问题？为什么以前没有发现？需要采取什么纠正措施？什么时候完成？如何验证有效性？
尤其是：
Correction ≠ Corrective Action ≠ Effectiveness Check
FDA还发现，公司CAPA记录虽然有“实施验证”，但没有真正的有效性验证（Effectiveness Verification）。
也就是说：
做完了，不等于有效；关闭了，不等于问题不会再次发生。
不符合项5 | 供应商管理程序太“原则化”，缺少具体触发标准
FDA发现：
公司的Purchasing Controls程序虽然写了供应商需要定期重新评价、监控和趋势分析，但没有明确：
什么情况下必须重新评价； 什么情况下需要增加监控； 什么情况下需要采取措施； 供应商绩效达到什么程度需要升级处理。
FDA认为，供应商监控的程度应当与器械风险以及对器械/QMS的影响相匹配。
启示：
FDA不喜欢只有原则、没有标准的程序。
例如：
“定期评价供应商”不够。
更好的程序应该明确：
什么指标 → 什么阈值 → 什么风险等级 → 谁批准 → 采取什么措施。
这也是风险管理从“文件化”走向“可执行化”的关键。
不符合项6 | MDR程序写了很多，但关键内容没有写清楚
FDA发现：
公司的SOP-014号Complaint Management Procedure声称覆盖21 CFR Part 803 MDR要求，但FDA发现存在多个缺陷。
例如：
没有充分定义：
“become aware”； “caused or contributed”； “reasonably suggests”。
同时，公司对“serious injury”的定义也不符合21 CFR 803.3，因为法规定义同时涉及injury和illness，而公司程序仅强调injury。
此外，MDR程序没有充分规定：
FDA Form 3500A相关信息如何收集； 初始报告和后续获得信息如何提交； 如何进行电子提交； 如何完整记录MDR可报告性判断过程。
FDA还发现，公司某一MDR事件记录中，没有充分证明其实际执行了程序要求的可报告性判断。
解读：
FDA此次对MDR的关注非常典型：
有SOP ≠ MDR体系有效。
真正重要的是：
Complaint → Event Assessment → Reportability Decision → MDR Submission → Follow-up → Record Retention
每一步都必须有清晰的责任、时限、判断标准和记录。
另外，FDA指出，公司SOP中仍然保留了已经不再要求的Baseline Report内容，并建议删除。
同时，截至2026年4月24日，公司尚未建立有效的ESG NextGen production account用于MDR电子提交。
结语
这封警告信的启示，不是“软件升级要不要重新提交510(k)”。
更深层的问题是：
医疗软件已经不是传统意义上的“一次申报、长期使用”的产品，而是持续变化、持续迭代、持续产生风险的产品。
对于AI医疗器械企业来说，真正需要建立的不是一个简单的“软件变更流程”，而是：
“变更—风险—验证—监管路径”四位一体的生命周期管理体系。
尤其要警惕三类变化：
AI算法变化、软件架构变化、技术平台变化。
因为这些变化看似属于研发问题，最终可能变成FDA眼中的上市前合规问题、QMS问题，甚至患者安全问题。
FDA这封Warning Letter释放出的信号非常明确：
软件可以持续迭代，但监管责任不会因为“只是升级软件”而消失。
——专注全球医械合规，助推中国器械出海。
亲爱的读者，感谢您的关注和点赞，请拨动您的小手指多多转发。
成长需要您的陪伴，您的每一次转发都是我耕耘的动力！
咨询交流，加微信：MedTechRAQA2026。
