← 返回首页

FDA人因验证失败后的补救研究:summative test没过,什么时候能桥接、什么时候必须重做

中国医疗器械企业summative人因验证测试失败后的完整补救路径:根因分类、桥接研究vs全面重做决策树、IFU/培训修改策略、残余风险论证和FDA回复证据包。

陈然
陈然最后更新:

人因验证测试(human factors validation testing,也叫summative usability testing)是FDA对高风险器械上市前审查的核心证据之一。测试没过,意味着受试者在关键任务(critical tasks)上出现了可能导致严重伤害的使用错误。但这不等于项目就此搁浅。

从我们接触的中国器械企业来看,summative test失败后最常见的反应是恐慌性地安排全面重做,或者反过来,试图用一份"补充分析报告"糊弄过去。实际上,FDA的框架给了企业相当灵活的补救空间——前提是你理解什么时候可以桥接(bridging)、什么时候必须重来。

summative test"没过"到底是什么意思

FDA在人因指南(Applying Human Factors and Usability Engineering to Medical Devices, 2016)中并没有定义一个硬性的"通过/不通过"标准。审评员看的是:

  • 关键任务上是否出现了导致或可能导致严重伤害的使用错误(use error)
  • 使用困难的模式是否有系统性(多个受试者出现同类问题)
  • 根因分析是否到位
  • 残余风险是否可接受

换句话说,"没过"不是一个二元判断,而是一个从"个别小问题可接受"到"系统性严重问题需要设计变更"的连续光谱。

在我们看来,中国企业最容易犯的错误是把summative test理解为"考试"——及格就过,不及格就完。FDA的审评逻辑完全不是这样。他们看的是"你的器械在预期使用条件下,使用相关风险是否降到了可接受水平"。

根因分类:补救路径的起点

补救研究的第一步是对每一个使用错误做根因分析。根据NAMSA和Emergo by UL的行业实践,根因通常可以归入以下几类:

根因类别典型表现补救难度
标签/IFU问题使用者不理解操作步骤、忽略警告
培训不足受试者操作不规范但经提醒可完成
界面设计缺陷按钮布局、显示信息导致混淆中到高
物理人机工程问题握持力、操作角度、连接方式不合理
使用场景不匹配测试环境/用户群与实际使用条件偏差

做根因分析时,不要把错误归咎于用户。FDA明确要求企业从设计角度分析错误原因,而不是说"这些护士操作不熟练"。complizen.ai整理的FDA审评常见拒签原因中,"blaming users for errors"和"ignoring close calls"排在前列。

桥接研究 vs 全面重做:决策树

这是本文的核心。判断标准可以用一个简化决策树来说明:

第一步:使用错误是否涉及关键任务(critical task)?

如果错误只发生在非关键任务上,且根因明确指向IFU表述不清等可快速修复的问题,通常不需要重做summative test。补充一份formative评估加上修改后的IFU即可。

第二步:关键任务的使用错误是否导致了或可能导致严重伤害?

如果错误可能导致严重伤害(serious harm),FDA会要求看到更实质性的整改。

第三步:整改是否涉及用户界面(user interface)的设计变更?

这里要区分两种情况:

情况A:整改不涉及界面设计变更——比如只修改了IFU的措辞、增加了警告标签、简化了培训材料。这种情况下,通常可以做一个规模较小的桥接研究(bridging study)来验证整改效果。

桥接研究的关键参数:

  • 受试者数量:通常每个用户组10-15人(vs summative的15-25人)
  • 任务范围:只评估修改涉及的关联任务
  • 测试环境:与原始summative test保持一致
  • 测试设备:可以使用设计冻结后的最终版本

情况B:整改涉及界面设计变更——比如改了按钮位置、调整了屏幕布局、更换了连接方式。这种情况下,做小范围桥接研究很难说服FDA,因为设计变更可能引入新的使用风险。此时基本上需要重新执行summative validation。

FDA在2016年指南的"Human Factors Validation Testing of Modified Devices"一节中写得明白:当制造商修改了器械的设计时,需要基于风险分析评估修改是否影响了使用相关风险水平。如果风险不可接受,测试应聚焦于受影响的危害相关使用场景和关键任务。

Emergo by UL在2025年7月的webinar中也专门讨论了这个问题:设计变更后的HF测试判断逻辑是(1)变更是否影响用户交互;(2)是否引入新的使用场景;(3)残余风险分析是否支持。

IFU和培训修改的补救策略

很多时候,summative test的问题可以通过修改IFU和培训来解决。但这里有几个中国企业常踩的坑。

IFU修改要点

  • 不要只在"注意事项"里加一句话。FDA在complizen.ai的分析中明确指出,"warnings alone are not an adequate control for critical tasks, and must be shown to be effective through validation testing"
  • 修改后的IFU必须在桥接研究中被验证,不能只改不改
  • 知识任务(knowledge tasks)是验证IFU有效性的好工具——让受试者回答关于安全操作的问题,而不仅仅是看他们能不能完成任务

培训修改要点

FDA对培训的态度比较微妙。他们允许在summative test中提供培训,但有严格要求:

  • 培训必须是标准化的、有脚本的(scripted)
  • 每位受试者必须接受完全一致的培训内容
  • 考虑培训衰减(training decay)——测试是否在培训后足够长的时间进行
  • 培训的详细程度不能超过实际使用中用户会获得的培训

Medical Device Academy的分析指出,FDA曾因为"训练由主持人提供但没有标准化脚本"和"训练衰减未纳入研究设计"而判定研究无效。

残余风险论证:什么时候FDA能接受

如果补救研究后仍然存在一些使用困难或非关键错误,可以通过残余风险论证(residual risk justification)来说服FDA。论证的核心是benefit-risk分析:

  1. 残余使用错误的严重程度——是否可能导致严重伤害?如果只是操作不便但不影响安全,论证相对容易
  2. 受益分析——器械带来的临床受益是否明显大于残余使用风险
  3. 实际使用数据——如果有同系列器械的上市后数据(投诉率、不良事件率),是强有力的支持证据
  4. 附加风险控制措施——比如上市后用户培训计划、投诉监控机制、使用说明的持续改进

FDA在combination product指南(Application of Human Factors Engineering Principles for Combination Products)中也明确提到:"FDA may accept residual use-related risk only when justified through a robust benefit-risk analysis."

FDA回复证据包的结构

当你需要向FDA提交补救研究的结果时,证据包的结构很关键。建议按以下格式组织:

1. 原始summative test结果回顾

  • 测试中发现的关键使用错误汇总表
  • 每个错误的根因分析
  • 错误与关键任务的对应关系

2. 整改措施说明

  • 针对每个根因的具体整改措施(IFU修改、设计变更、培训调整等)
  • 整改前后的对比(红线标注修改内容)

3. 桥接/补救研究报告

  • 完整的测试协议(protocol)
  • 受试者人口统计学信息
  • 测试环境描述
  • 任务通过/失败矩阵
  • 使用错误分析和根因判断
  • 与原始summative test结果的对比

4. 残余风险分析

  • 残余使用错误清单
  • 每个残余风险的受益-风险判断
  • 上市后监控计划

5. 更新的使用相关风险分析(URRA)

  • 将整改措施和补救研究结果纳入URRA
  • 证明风险控制措施的有效性

中国企业的典型失败场景

就实际经验而言,中国企业在这个环节有几个高频问题:

场景一:formative做太少就冲summative

很多企业为了省钱和时间,formative evaluation只做了一轮就想直接过summative。Custom Medical的分析明确指出:"In practice, validation studies repeatedly fail due to a poor user interface. Users make mistakes that the development team would not have thought possible." 至少做2-3轮formative是行业最佳实践。

场景二:用户群定义太宽

FDA在审评中会仔细审查你的用户群(user groups)定义是否合理。把"医护人员"作为一个用户群太宽泛——护士、医生、技师的操作习惯和认知水平差异巨大。Medical Device Academy的案例提到,FDA曾因企业把用户群定义得过于宽泛而拒绝接受其summative测试结果。

场景三:测试环境不真实

在家用器械的summative test中,如果受试者是在安静、明亮的实验室环境下操作,而实际使用场景可能是嘈杂的家庭环境,FDA会质疑结果的可推广性。

场景四:忽略close calls和difficulties

summative test不仅要记录使用错误(use error),还要记录near miss(close calls)和使用困难(difficulties)。这些看似"没出错"的观察其实包含了重要的风险信号。complizen.ai指出,"reporting task success rates without root cause analysis"和"ignoring close calls and repeated difficulties"是FDA常见的拒签原因。

申报时间线规划

补救研究会显著影响510(k)/PMA的时间线,企业需要提前规划:

阶段时间关键活动
根因分析1-2周逐一分析summative test中的使用错误
整改方案制定2-4周确定设计变更/IFU修改/培训调整方案
桥接研究准备3-4周编写协议、招募受试者、准备测试环境
桥接研究执行1-2周执行测试、收集数据
数据分析和报告2-3周统计分析、根因判断、报告撰写
FDA回复包整合1-2周整合所有证据、更新URRA

整个补救流程大约需要10-15周。如果需要全面重做summative test,时间线可能拉长到16-20周。

什么时候应该在summative之前做Q-Submission

如果你的器械属于以下类别,强烈建议在summative test之前通过Q-Submission(Pre-Submission)与FDA讨论人因测试方案:

  • 组合产品(注射笔、吸入器、预灌封注射器等)
  • 含有软件决策支持的器械(AI-enabled device)
  • 家用器械(患者自行操作)
  • 手术器械(高压力使用环境)

FDA在Q-Submission中会给出关于用户群定义、样本量、关键任务列表的具体反馈。这一步虽然会增加2-3个月的前置时间,但能大幅降低summative test失败的风险。

FAQ

Q1:summative test中有多少使用错误算是"可接受"?

FDA没有设定硬性阈值。审评看的是错误的严重程度(是否可能导致严重伤害)、系统性(多个受试者出现同类问题)和根因的可修复性。一个导致潜在严重伤害的系统性错误,比多个孤立的小问题更难被接受。

Q2:修改了IFU之后,桥接研究需要用多少受试者?

取决于整改涉及的复杂度和原始summative test的规模。行业实践通常用每个用户组10-15人(原始summative一般是15-25人)。如果只是验证IFU措辞修改的效果,规模可以更小。

Q3:如果补救研究后FDA仍然不满意,还有救吗?

有。FDA通常会发Additional Information请求,给出具体的不足和需要补充的信息。这给了企业第二次整改的机会。但反复来回会显著延长审评周期(每次回复通常增加30-90天)。

Q4:欧盟MDR下的summative evaluation失败怎么办?

MDR下的summative evaluation遵循IEC 62366-1,基本逻辑类似。但MDR的要求是"证明在正常使用条件下,可用性相关的风险已降至可接受水平",不像FDA那样关注critical tasks。公告机构对summative evaluation失败的容忍度各不相同,需要与NB具体沟通补救方案。

Q5:有没有办法在summative之前预测失败风险?

有。做充分的formative testing(至少2-3轮),配合启发式评估(heuristic evaluation)和认知走查(cognitive walkthrough),可以在summative之前发现大部分使用风险。NAMSA的分析指出:"iterative formative testing significantly increases the likelihood of successful summative validation and smoother regulatory review."

Q6:如果我们自己判断不需要重做summative,FDA不同意怎么办?

这种分歧最好的解决方式是在做补救研究之前通过Q-Submission与FDA沟通。把你的整改方案和桥接研究计划提交给FDA,获得他们的书面反馈后再执行,可以避免做无用功。

参考资源


本文提供的信息仅供参考,不构成法律或法规建议。具体申报策略请结合产品实际情况咨询法规顾问。

AI 助手

你好!我看到你正在阅读「FDA人因验证失败后的补救研究:summative test没过,什么时候能桥接、什么时候必须重做」。有任何关于这篇文章的问题,都可以问我!

由 Gemini 驱动 · 回答仅供参考