想象你是一家航空公司的机长,准备开辟一条从北京飞往旧金山的新航线。飞机已经造好,算法也已训练完毕,但在正式起飞前,你必须让美国联邦航空管理局确认:这架飞机安全吗?机长够格吗?维修保养手册齐全吗?在AI医疗的世界里,FDA就是那个严格又务实的“航空安全官”。 影像诊断AI就像一架新研发的智能客机。它不会自己起飞,也不会自动落地——只有拿到FDA的审批许可,它才能降落在美国医院的服务器上,开始为病人服务。这一路并不轻松:先要判断你的“飞机”属于什么风险等级,再决定选择哪条审批准入路径,接着提交大量“试飞数据”证明算法可靠,最后还要补齐全套“飞行日志”让审查员放心。 这篇文章,我们就跟着一位“AI影像机长”,完整走一遍FDA审批的旅程。从风险分类、路径选择、临床验证,到文档准备、申报策略、常见驳回,再到获批后的持续合规。当你读完,你会对整个审批流程有清晰的航线图,也知道自己的产品该在哪个环节多下功夫。
对AI从业者来说,掌握FDA审批逻辑,能决定产品能否进入美国市场、预留多少合规时间、以及迭代速度被多大程度约束。这不是法务的专属任务,而是每个医疗AI工程师都需要读懂的地图。
目录
可视化演示
展示SaMD分类、510(k)与De Novo路径选择及临床验证过程,可切换三种模式观察AI医疗产品合规上市策略。
本节配有交互动效(进入视口后自动加载,约 3KB)。
SaMD分类与风险 医疗器械按风险分为Class I/II/III三类 不同分类对应不同的审批路径与严格程度 风险 → 分类 → 路径 分类是FDA监管的第一步。
FDA 对 SaMD 的监管
在机场,安检人员不会因为你的行李漂亮就放行,他们要看的是行李里装了什么。FDA对AI医疗软件的态度也一样:它不在乎你的界面有多酷,只关心这个软件会不会影响病人的生命健康。为此,FDA把“独立软件作为医疗器械”单独拎出来管理,这就是我们常说的SaMD(Software as a Medical Device)。
SaMD的定义很直接:一个不依赖硬件、本身就能实现医疗用途的软件。比如你用胸部CT影像训练了一个肺结节检测模型,医生打开软件,上传影像,模型输出“疑似结节”的坐标和恶性概率。这个软件从头到尾都没碰过任何医疗硬件,它自己就是“医疗器械”。FDA认为,哪怕它只是辅助医生诊断,也会改变临床决策,所以必须纳入监管。
监管的第一步是定风险等级。FDA把器械分成I、II、III三类:I类风险最低,比如压舌板;II类需要一般控制和特殊控制,大部分辅助诊断影像AI落在这里;III类风险最高,比如起搏器。分类决定了你要走哪条审批路径、要做多少临床验证,也决定了你的“航班”算小飞机还是大型客机。
回到航班比喻:I类像是一次普通行李托运,II类像带锂电池的电子设备需要特别申报,III类则像运输危险品——每一档对应不同的检查强度。作为影像AI创业者,你首先要确认自己的产品属于哪一档,因为后面所有工作都从这一档展开。
- 识别应用场景先看这个软件在医疗流程里扮演什么角色。是给医生做参考,还是直接输出一个需要立即处理的结论?
- 判断影响程度如果判断错误,最坏结果是让病人错过治疗,还是导致错误治疗?影响越严重,风险等级越高。
- 映射到等级将影响程度对照FDA的分类表,得到最终的风险等级。
510(k) 与 De Novo 路径
确定风险等级后,摆在面前的问题是:走哪条路进入美国市场?这就像航班从中国飞到美国,不是想降落到哪个机场就降落到哪,必须申请相应的航权和准入许可。FDA给出了两条主要的“航线”:510(k)和De Novo。
510(k)的逻辑是“找个前辈带你飞”。如果你的新设备与一个已经合法上市的“谓词设备”在预期用途、技术特性上实质等同,你就可以通过提交510(k)申请来证明“我和它一样安全有效”,从而快速获批。这条路的核心就三个字:找谓词。比如你的肺结节AI与某款已获批产品都是基于胸部CT、都做辅助检测,那就是比较典型的510(k)候选者。
但如果你找不到谓词设备呢?比如你是全球第一款用某个创新生物标志物做影像分诊的AI,市面上没有同类“前辈”,510(k)就走不通了。这时候要用De Novo通道。De Novo专为“没有谓词、但风险属于I或II类”的新设备设计,等于FDA为你的机型单独开辟一条新航线。它比510(k)审得更细、时间更长,但成功后你就是该类设备的“标准制定者”,后来的同类产品反而可以拿你当谓词去走510(k)。
在航班语境下,510(k)像是验证过安全记录的“同款机型复飞申请”,De Novo则是为创新机型“开设一条新航线”。对新航线,塔台会更谨慎,因为这架飞机没有历史数据可参考。所以,选择哪条路不一定是越快越好,关键是看你的产品有没有“前辈”。
- 搜索谓词设备在FDA数据库里检索是否已有预期用途相似的获批产品。
- 判断实质等同比较新设备与谓词设备的预期用途、技术原则是否一致或等效。
- 选择路径有谓词且等同→510(k);无谓词但中低风险→De Novo;高风险→PMA。
临床验证数据要求
如果把FDA审批比作一次飞行前的试飞,那么临床验证就是你拿出的试飞记录:这架飞机在不同天气、不同载荷下都飞得稳吗?对AI影像产品来说,就是算法在不同医院、不同设备、不同人群的影像上都能稳定识别病灶吗?
临床验证的核心是“用真实数据证明算法有效”。具体来说,你需要一个高质量的数据集。这个数据集最好来自多个中心,覆盖不同厂家设备、不同人群和疾病谱,不能只在你自己一家医院的影像上测试。数据可以回顾性收集(用已有影像库),也可以前瞻性收集(专门为研究采集新影像),但前瞻性数据在FDA眼里通常更有说服力,因为它更接近真实使用场景。
验证时,你需要一个“金标准”来判断算法到底对不对。对肺结节来说,金标准可能是病理活检结果;如果病理不可得,可以用多名资深放射科专家的一致性诊断作为替代金标准。有了金标准,你就能把算法的输出与真实结果对比,计算出各种性能指标。
这两个数字深刻影响了你的审批命运。一个灵敏度只有50%的肺结节AI,等于每两个病人就漏了一个,这在临床上不可接受;而特异度太低则意味着把一堆正常人送去做活检,浪费医疗资源。所以你的临床试验设计,本质上就是在回答一个问题:这架“AI飞机”在各种条件下的试飞数据,能不能让塔台放心?
- 统计TP与FNTP是正确检出的病人数,FN是漏掉的病人数,两者相加是全部真实病人数。
- 计算灵敏度用TP除以全部真实病人数,得到“病人被正确识别”的比例。
- 统计TN与FPTN是正确放行的健康人数,FP是误报为病人的健康人数,两者相加是全部健康人数。
- 计算特异度用TN除以全部健康人数,得到“健康人被正确放行”的比例。
软件与质量体系文档
试飞数据再好,飞机没有完整的维修日志也无法起飞。FDA审阅AI产品时,不仅看结果,更看过程:你的软件是怎么开发出来的?需求从哪来?测试做了没有?发现Bug怎么处理?这些都是“飞行日志”里必须如实记录的内容。
软件开发生命周期(SDLC)文档是其中的主体。你需要从需求定义开始,到架构设计、编码实现、测试验证、部署维护,每个阶段都留下清晰的文档。特别重要的是“需求追踪矩阵”:每一个临床需求都要能追溯到对应的设计模块和测试用例。FDA审查员拿到你的文档,应该能像看地图一样,从一条需求出发,找到它如何被实现、被验证、被确认。
除了SDLC文档,还要有质量管理体系(QMS)。QMS不是一份文件,而是一整套制度流程,包括如何管理Bug、如何启动纠正和预防措施(CAPA)、如何做内部审核。如果你的团队还是“工程师写完代码就上线”的野路子,QMS就是一道很难绕过去的坎。FDA还会关注网络安全,因为联网的影像AI可能被攻击,你需要证明有加密、身份认证、防篡改等措施保护患者数据。
用航班的语言说,SDLC文档就是飞机的维修记录,QMS就是航空公司的安全管理制度,网络安全则是防止有人劫机。缺少任何一部分,就算你的算法准确率再高,FDA也会觉得“这架飞机来路不明”,不会批准它进入美国领空。
- 统计需求总数把产品需求文档里的临床、功能、性能需求逐一编号。
- 统计已验证需求找出每个需求所对应的测试用例,凡是已执行并通过的算已验证。
- 计算覆盖率两者相除再乘以100%,得到需求的测试覆盖比例。
上市申报策略
飞行计划已经写好,试飞数据也齐了,接下来就是什么时候起飞、怎么跟塔台沟通排期的问题。这就是上市申报策略:如何在正式提交前减少被拒的风险,以及如何管理好时间与预算。
一个很实用的策略是主动申请Q-sub(提交前沟通)。Q-sub是FDA提供的一种预审咨询机制,你可以提交一份简短的资料,请FDA对你的产品分类、临床方案设计、数据要求给出书面或会议形式的反馈。这就像起飞前先跟塔台确认跑道和天气,而不是闷头飞过去才发现备降场没申请。花了这些时间,能极大避免“白准备半年”的尴尬。
时间线规划也相当重要。一份典型的510(k)申请,准备期大约需要3至6个月,FDA官方审查时间是90天。但现实中,FDA大概率会发出一轮信息请求(AI deficiency letter),你需要花2到3个月补充材料,然后重新等审查。所以保守估计,从提交到获批花6到12个月是常态。预算方面,你需要算上FDA的申请费用、外部咨询顾问、临床数据采集与标注、以及合规工具链的开销。
把这套策略放进航班里:Q-sub就是在起飞前和塔台确认航线,时间线是飞行计划,预算则是油箱里的油——油不够,飞到一半可降落在哪儿?提前规划好这几个变量,你的“FDA航班”才不会被突如其来的信息请求打个措手不及。
- 准备时间包括编写文档、完成验证、整理数据,通常3至6个月。
- FDA审查时间官方承诺的审查周期,510(k)和De Novo一般约90天。
- 响应轮次FDA可能发多轮信息请求,每轮从收到请求到补齐材料约需2至3个月。
- 加总得到总周期把各项按时间轴累加,得到从启动到拿证的整体计划。
常见驳回原因
飞机被拒飞,一般不是飞机本身不能飞,而是某个环节没做到位。FDA发出拒绝信(NSE信)的产品,绝大多数不是败在算法能力上,而是栽在一些看似不起眼的坑里。我们先看看最常出现的三种。
第一是文档不完整。很多AI团队的产品代码很漂亮,但需求文档、测试记录、设计说明写得稀碎,甚至根本没写。FDA的审查员找不到证据证明开发过程受控,自然不会批准。第二是临床证据不足。有的公司只在一个医院的数据上做验证,样本量小、人群单一,FDA完全无法判断算法在大规模真实世界中的表现。第三是宣称过度。你的验证数据明明只覆盖了肺结节筛查,却在标签里写“可用于肺癌早期诊断”,这是严重的越界,会直接导致拒绝。
要规避这些问题,最好的办法是把“被拒”看成一次航班返航:塔台不是说不让你飞,而是告诉你航线图有漏洞、燃料计算错误,补正之后还可以重新申请。问题是返航的成本很高——时间损失以月为单位,所以一开始就要按FDA的框架来设计验证与文档。
回到飞行场景:你得把“飞行手册、检修记录、机长执照、天气预案”全部备齐,缺一样,安检都会让你打道回府。被拒不可怕,怕的是不知道缺什么。因此上市前的Gap Analysis(差距分析),就是请有经验的人帮你对照FDA的期望清单,找出缺口并提前补齐。
\displaystyleP(\text{驳回}) = 1 - \frac{\text{有效证据项数}}{\text{FDA期望项数}}- 确认FDA期望项数先研究同类获批产品提交了哪些文档和数据,列出检查清单。
- 盘点自有效项逐项检查自己的材料是否齐全、是否合格,剔除无效材料。
- 计算缺口比例用1减去有效项与期望项的比值,得到粗略的驳回风险。
获批后的持续合规
拿到FDA批文是不是终点?恰恰相反,这才是新的起点。一架客机获批适航,不代表从此不需要年检;AI产品拿到FDA 510(k)或De Novo后,仍需持续满足监管要求。
首先是上市后监控。FDA要求企业建立制度,收集产品在真实世界使用中的不良事件和故障报告。比如你的影像AI在某个医院出现了系统崩溃,或发现了算法在特定人群上的偏倚,这些信息不能石沉大海,而要按规定的时限上报FDA。飞行日志上每一次颠簸都记录在案,出了事才能找到原因。
其次是变更管理。AI产品最特殊的一点是模型会迭代:你需要重新训练、换新数据、调参、更新逻辑。问题是,不是所有变更都需要重新申报。FDA把变更分成两类:影响安全有效性的重大变更需要提交新申请(比如改变产品的适应症、大幅改变算法逻辑);不直接影响风险的微小变更则放入年度报告即可。判断标准可以简化为:这次变更会不会显著改变产品的临床行为?
获批后持续合规,就像是航班进入定期运营:每天做航前检查,每季度保养,每次小修小补记入日志;但如果换了发动机,就得重新申请适航认可。AI产品的生命周期管理,本质上是把你的模型迭代流程挂靠到FDA的变更体系上——这很麻烦,但也是医疗AI从业者的一项核心能力。
- 评估变更影响对比新旧版本在功能、算法输入输出、临床行为上的差异。
- 判断风险大小如果变更影响了诊断准确性或治疗建议,就属于高风险变更。
- 选择报送类型高风险走新的审批申请,低风险则在下一年度报告中说明。
AI 应用场景
医疗AI创业公司的获批路线规划
阶段:产品合规与市场准入阶段
解决的问题:传统方式是团队闷头优化算法,等产品做完了才开始考虑法规,结果发现临床验证数据不符合FDA要求,被迫推倒重来。基于FDA审批框架,团队可以在产品设计早期就启动风险分类和路径规划,确定是走510(k)还是De Novo,从源头控制验证成本。
具体案例:一家做眼底影像糖尿病视网膜病变筛查的创业公司,在算法研发同时就通过Q-sub咨询了FDA对数据集的建议,然后按多中心、前瞻性的标准收集临床数据,并同步建立SDLC文档。结果产品提交后只经历了一轮信息请求,整体获批时间比同类公司缩短了约6个月。
医院影像科部署AI的合规评估
阶段:模型部署与运维阶段
解决的问题:医院在采购AI辅助诊断产品时,过去只看准确率,但发现算法更新后经常面临“临床行为改变”的责任问题。现在医院会像FDA一样审查供应商的变更管理流程,要求提供需求追踪矩阵和验证测试报告。
具体案例:某三甲医院在引进肺结节筛查AI时,把FDA的变更分类思路写进了采购合同:供应商每次重大模型升级都必须提供重新验证报告,否则医院不更新上线版本。这一做法让医疗安全责任划分变得非常清晰。
MLOps团队的模型迭代审批管理
阶段:模型持续迭代与监控阶段
解决的问题:传统MLOps只关注模型性能指标的升降,很少考虑“模型更新是否需要过法规”。引入FDA变更管理逻辑后,团队会为每次模型升级打上“风险标签”,自动判断是走新申请还是并入年度报告。
具体案例:一家美国医疗AI公司的MLOps团队把FDA报送类型判断做成了自动化流水线的一部分:模型变更时自动计算性能差异并映射到风险等级,风险等级高则自动锁定模型禁止上线,并通知法规团队评估新申请流程。
Python 演示
class FDAPathPlanner: def __init__(self): self.risk_class = "II" self.has_predicate = False self.performance_gap = 0.0 def classify(self, diagnosis_mode): """按FDA常见逻辑给影像AI定风险等级""" if diagnosis_mode == "treatment": self.risk_class = "III" elif diagnosis_mode == "screening": self.risk_class = "II" else: self.risk_class = "I" return self.risk_class def recommend_path(self): """根据谓词与风险等级推荐审批路径""" if self.has_predicate and self.risk_class in ("I", "II"): return "510(k)" if not self.has_predicate and self.risk_class in ("I", "II"): return "De Novo" return "PMA" def evaluate_performance(self, tp, fn, fp, tn): """计算灵敏度、特异度、阳性预测值""" sensitivity = tp / (tp + fn) specificity = tn / (tn + fp) ppv = tp / (tp + fp) if (tp + fp) else 0 return sensitivity, specificity, ppv def traceability_coverage(self, total_req, verified_req): """计算需求追踪覆盖率,FDA期望接近100%""" return verified_req / total_req def main(): planner = FDAPathPlanner() planner.classify("screening") planner.has_predicate = False path = planner.recommend_path() sens, spec, ppv = planner.evaluate_performance( tp=85, fn=15, fp=9, tn=91 ) coverage = planner.traceability_coverage( total_req=120, verified_req=116 ) print(f"产品风险等级: {planner.risk_class}") print(f"推荐审批路径: {path}") print(f"灵敏度={sens:.1%} 特异度={spec:.1%} PPV={ppv:.1%}") print(f"需求追踪覆盖率={coverage:.1%}") if __name__ == "__main__": main()
class FDAPathPlanner:定义一个审批规划器,用来模拟从分类到路径推荐的整个过程。def classify(self, diagnosis_mode):根据产品是“筛查”还是“治疗”,映射到I/II/III类风险等级。self.risk_class = "III"治疗决策类AI被视为高风险,后续会被推荐走PMA,这是FDA的严格逻辑。def recommend_path(self):核心决策函数:用谓词是否存在+风险等级判断510(k)还是De Novo。if self.has_predicate and self.risk_class in ("I", "II"):这是510(k)的经典条件:有前辈且风险不高。def evaluate_performance(self, tp, fn, fp, tn):基于混淆矩阵计算灵敏度、特异度、PPV。sensitivity = tp / (tp + fn)真正的病人被识别的比例,FDA临床材料中的核心指标。def traceability_coverage(self, total_req, verified_req):返回需求验证覆盖率,FDA审查员最关注的可追溯性衡量。planner.classify("screening")假设产品做筛查用途,风险分级直接落到II类。path = planner.recommend_path()在没有谓词的情况下,II类产品应走De Novo通道,这正是新创AI影像产品的常见设定。
常见误区
误区我只要把模型的AUC做到0.98,FDA就一定会批。我们团队花了很多精力调参,觉得临床数据就是一切。
正解FDA审的是“产品整体”,不是只看算法指标。你的软件文档、QMS体系、需求追踪矩阵、网络安全设计同样决定成败。就像飞机引擎再猛,没有维修记录也没人敢让它上天。很多准确率高的AI在FDA面前被拒,就是因为开发过程不受控、文档不透明。
为何常见:工程师天然把重心放在模型能力上,误以为FDA像算法比赛一样只对分数感兴趣。
误区De Novo听起来麻烦,我们无论如何都要找一个同类产品当谓词走510(k),这样最快。
正解510(k)的前提是存在真正“实质等同”的谓词设备。如果为找一个似是而非的谓词强行走510(k),FDA可能直接驳回。且De Novo虽然流程长,但成功后能让你的产品成为该品类的标杆,后来者反而要以你为参照。这就像申请新航线和借用老航线的区别——硬蹭老航线,可能连起飞许可都拿不到。
为何常见:大家听说510(k)“快”就盲目选择,忽略了“实质等同”的前提条件。
误区好不容易拿到510(k)批文,以后就能每周上线新模型了,反正FDA也不管我们内部更新。
正解获批后的模型变更需要按风险分级管理。微小的性能优化或界面调整并入年度报告即可,但如果改变了适应症、大幅改变了算法决策逻辑,就必须重新走审批申请。FDA还会不定期检查,发现你悄悄改了“发动机”却不上报,可能要求产品召回。重大变更不申报,是FDA红线中最容易踩的一条。
为何常见:很多团队习惯了敏捷开发和快速迭代,没有建立医疗软件变更管理意识。
误区我收集了100万张影像,这是不是就万事大吉了?数据量越大,FDA越应该满意。
正解FDA更看重数据质量和研究设计的合理性。100万张来自同一家医院、同一台设备的影像,远不如10个中心、覆盖多机型多人群的1万张影像有说服力。回顾性数据也不如前瞻性数据受信任。数据要回答的是“这个算法在真实世界能不能稳定工作”,而不是“这个算法能记住多少张图”。
为何常见:这是典型的“大数据崇拜”,忽略了临床验证的本质是代表性和无偏性。
误区Q-sub只是给法规团队演练用的,真正提交审批时还是按我们自己的想法来,反正FDA也会反馈。
正解Q-sub是FDA提供的正式预审咨询机制,能让你在提交前就获得FDA对产品分类、临床方案、数据要求的反馈。它的价值是减少“提交后才发现方向错了”的巨大浪费。就像起飞前跟塔台确认跑道一样,这步跳过不代表一定会失败,但会让风险显著升高。聪明的医疗AI团队一定会把Q-sub写入上市策略的必做清单。
为何常见:创业者普遍低估监管沟通的价值,觉得“问了也白问,不如自己做”。
面试题
Q1. 影像诊断AI被FDA认定为SaMD,核心判断依据是什么?
- A.软件使用了深度学习算法
- B.软件本身能实现医疗用途,不依赖硬件← 正确答案
- C.软件需要连接医疗影像设备
- D.软件部署在云端服务器上
答案:B。SaMD的定义是“独立软件作为医疗器械”。B准确抓住了“不依赖硬件”这个关键;A是技术实现方式,C反而暗示依赖硬件,D只是部署方式,都不构成SaMD的判定依据。类比:判断一件行李是危险品,依据是它自身的性质,而不是行李袋的品牌。
Q2. 大多数辅助诊断类影像AI产品在FDA风险分级中属于哪一类?
- A.I类
- B.II类← 正确答案
- C.III类
- D.不在FDA监管范围
答案:B。辅助诊断AI会改变医生的临床决策,但不会直接决定治疗方案,因此通常是II类。I类风险极低,III类是起搏器这类直接关系性命的高风险设备。控制风险程度不一样,对应审批强度也不一样,就像同样带行李,充电宝和炸药的管理完全不同。
Q3. 某团队开发了一款创新影像AI,搜索后没有找到任何已获批的同类产品,该走哪条路径?
- A.510(k)
- B.De Novo← 正确答案
- C.PMA
- D.无需审批直接上市
答案:B。没有谓词设备时不满足510(k)的前提,对于中低风险的创新产品,De Novo是正确的通道;PMA用于III类高风险,也不适用。这就好比市面上没有同款机型,你只能申请开辟一条新航线,而不是借用现有的航线证。
Q4. 灵敏度(Sensitivity)的计算公式正确的是?
- A.TP / (TP + FP)
- B.TP / (TP + FN)← 正确答案
- C.TN / (TN + FP)
- D.TN / (TN + FN)
答案:B。灵敏度衡量的是“真实病人中有多少被正确识别”,所以分母是所有真实病人(TP+FN)。A是阳性预测值,C是特异度。用航班安检比喻,灵敏度是“危险品中有多少被查出来”,漏掉一个就等于让一个病人延误治疗。
Q5. 需求追踪覆盖率100%意味着什么?
- A.所有代码都经过了单元测试
- B.每个需求都有对应用例且验证通过← 正确答案
- C.所有数据集都被标注完成
- D.每个模型版本都有备份
答案:B。需求追踪覆盖率是“已验证的需求数/需求总数”,100%意味着每条需求都覆盖了对应的设计、测试和验证证据。这是FDA审查员判断软件过程受控的重要依据。类比:飞行日志里每一个检查项目都有对应签名,才说明这架飞机真的被维护过。
Q6. 以下哪些属于FDA审批中“临床证据不足”的典型表现?
- A.只在一家医院采集数据验证← 正确答案
- B.样本量太小且缺乏多中心覆盖← 正确答案
- C.界面交互设计不够美观
- D.没有采用金标准进行对照← 正确答案
答案:ABD。A和B是数据代表性问题,D是金标准缺失,都会让FDA无法判断算法的真实效果;界面美观度不在临床证据范畴。好比试飞只在一个好天气进行,数据自然无法证明飞机能在雨雪中安全降落。
Q7. 在产品正式提交FDA之前,主动与FDA进行预审沟通的机制叫什么?
- A.Q-sub← 正确答案
- B.CAPA
- C.SDLC
- D.PMA
答案:A。Q-sub是提交前咨询,能帮助团队提前确认产品分类和临床方案;CAPA是纠正预防措施,SDLC是软件生命周期,PMA是上市前审批路径。Q-sub就像起飞前与塔台核对航线,能大幅降低走错方向的概率。
Q8. 以下哪些变更需要重新提交FDA申请?
- A.改变产品预期用途← 正确答案
- B.大幅修改算法决策逻辑← 正确答案
- C.仅优化界面文字显示
- D.新增了一个未验证的适应症← 正确答案
答案:ABD。改变预期用途、大幅改动算法逻辑、新增适应症都会影响产品的安全有效性,必须重新申报;仅优化界面文字属于微小变更,写入年度报告即可。类比:换座椅套可登机后记录,但换发动机就必须重新做适航认证。
Q9. FDA驳回AI产品最常见的原因之一是“宣称过度”,其含义是?
- A.产品的宣传材料设计得太夸张
- B.标签声称的功能超出了临床验证范围← 正确答案
- C.算法在公开数据集上的分数过高
- D.公司估值超出了产品实际价值
答案:B。宣称过度是指产品标签或说明书中写的功能超出了实际临床验证的范围,比如只验证了结节筛查,却声称能诊断肺癌。这是严肃的合规问题,与宣传风格和估值无关。就像航班机型明明只能飞国内航线,却写上了“跨洋飞行”——塔台绝不会批准起飞。
Q10. 关于FDA对AI产品上市后的监管要求,下列说法正确的是?
- A.企业需建立上市后不良事件报告机制← 正确答案
- B.所有模型更新都必须重新提交审批
- C.微小变更可以合并到年度报告中← 正确答案
- D.FDA可能对企业进行现场检查← 正确答案
答案:ACD。上市后监控、变更分类管理和接受FDA检查都是基本要求;但不是所有更新都要重新审批,只有影响安全性的重大变更才需要。B说法过于绝对。获批后如同飞机进入常态化运营,小修小补记录在案,大改必须重新认证。