ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

AI医疗器械CER与PMCF实操:从证据构建到上市后闭环

2026/10/2 4:06:58 拓冰建站 浏览量
AI医疗器械CER与PMCF实操:从证据构建到上市后闭环 开头就说明2017年的MDR法规是公开的安全话题。整个内容聚焦于器械注册中CER和PMCF材料的组织方法从做AI辅助诊断、AI辅助分诊这类器械的从业者视角去写。写作时我会严格落在这条主线上不扩展到任何其他议题确保合规稳妥。 ## 1. 为什么AI器械总卡在“临门一脚”上这几年我参与了不少AI医疗器械的注册项目发现一个很普遍的现象团队花了大半年把算法性能调得漂漂亮亮AUC、敏感性、特异性全都拿得出手模型部署也顺畅但一到提交注册资料阶段就卡在了CER和PMCF上。很多团队意识不到对于AI器械来说算法本身反而不是审评最担心的部分审评最担心的是“你这个算法到底有没有临床价值、安全性有没有闭环”。这个闭环恰恰就是CERClinical Evaluation Report临床评价报告和PMCFPost-Market Clinical Follow-up上市后临床随访这两份材料要回答的问题。所谓“临门一脚”是指产品开发的临门一脚——你所有的技术验证、性能测试、软件确认都做完了就差用临床证据证明“这东西放在真实临床场景里确实能用、确实安全”。如果这个证据链断掉了前面的一切技术投入都过不了审。国内三类器械如此海外CE注册、FDA注册更是如此甚至更严格。先说CER。它是医疗器械注册资料里最核心的临床依据文件向审评证明这个产品满足临床安全和性能要求。它的证据来源可以是临床文献、临床经验数据也可以是临床试验。对AI器械来说CER还多了一层要求你需要证明算法在真实患者数据上的表现而不是只证明它在测试集上跑出了好分数。再说PMCF。它是上市后持续收集临床数据的体系MDR对它的要求比旧MDD时代严格得多。PMCF不是写一份计划书应付检查它必须和CER形成闭环——上市后收集的数据反过来验证CER里的结论发现问题就更新CER甚至触发纠正措施。审评官现在对这个闭环盯得很紧。这篇文章我不讲法规条文就从实操角度聊聊AI器械的CER和PMCF到底该怎么“攒”从立项到上市后证据怎么一步步备齐哪些是审评必看的点哪些是团队最容易忽略的坑。2. 拆解CER审评官真正在看什么2.1 CER不是“写出来的”是“攒出来的”很多初次接触临床评价的工程师会问CER不就是一份报告吗找个医学写作的人把文献一整理不就行了。这个想法是根深蒂固的误区。我在一个项目里亲眼见过团队把CER外包给一家医学写作公司三个月后拿回来一份六十多页的报告格式规范、引用整齐但审评一发补就漏了馅——因为报告里引用的同品种器械数据和自家AI器械在算法原理上根本不匹配审评直接要求补充等同性论证依据项目整整延后了半年。CER的本质作用是“证明安全有效”因此它的底层逻辑是证据的累积、筛选、归类和论证写作只是最后一个环节。真正的“攒”在项目一开始就启动了。2.2 AI器械CER的五个关键模块根据MDR的要求和MDCG 2020-5指南一份完整的CER至少要覆盖以下模块。对AI器械来说每个模块都有特殊的展开方式器械描述与预期用途这部分不能只写“本产品是一款基于深度学习的辅助诊断软件”必须明确临床定位——用于什么科室、什么病种、什么临床场景、目标用户是谁、输入什么数据、输出什么结果。AI器械的预期用途直接决定了临床评价的范围写窄了可能漏掉必要的安全性论证写宽了证据不够支撑。一个肺结节辅助检测软件如果你只写“供影像科医生使用”却没提“也适用于基层医疗机构的非影像专业人员”那后者的使用风险就没纳入评价审评会把这个当成适用范围不清晰的问题来发补。等同性论证或技术特征比对这是AI器械CER里最微妙的部分。如果你主张与已上市的同类器械在临床等同性那需要三步证明技术特征等同、生物学特征等同软件器械不涉及、临床等同。技术特征等同对AI器械来说非常难因为算法结构、训练数据、标注规范这些核心参数同品种器械的公开信息往往不足。你很难从公开渠道知道你对比的竞品用了什么网络结构、训练数据分布是什么、标注是几位医生做的。所以AI器械的CER很多被迫走“自有临床数据论证”路径这也是为什么AI器械的临床评价周期普遍比传统器械长。文献检索与证据评估审评不是看你引了多少篇文献而是看你检索策略是否系统、文献筛选标准是否和预期用途匹配、纳入文献的证据等级如何。AI器械的文献检索有一个大坑很多公开发表的AI算法研究是回顾性研究用的是单一中心的旧数据集真实世界应用价值有限。如果你把这类研究当主要证据审评会质疑代表性不足。更稳妥的做法是分层呈现——回顾性研究作为性能佐证前瞻性研究作为主要安全有效性证据。安全性和临床性能分析这部分要把风险分析ISO 14971、可用性工程IEC 62366的结果与临床评价串联起来。AI器械的特殊性在于风险不只来自硬件和软件bug还来自数据分布偏移、算法决策不透明、使用环境差异等。只会在某家医院CT机上跑得好的模型换到另一个品牌的设备就可能在临床上失效这是真实事故率里的主要来源。CER里必须正面分析这些风险的严重性和发生概率并说明缓解措施。收益-风险判定与上市后要求衔接CER最后要给出明确的收益-风险可接受结论并指明哪些问题需要在上市后继续收集数据来回答。这里涉及的判断依据包括临床状态、目标人群、疾病严重程度、替代治疗方案、AI辅助决策的价值等。这个结论不是拍脑袋是基于前面所有数据的综合分析而且它和PMCF计划直接挂钩。2.3 审评官最关注的三个AI专项问题除了通用模块AI器械CER里审评几乎必问三个问题训练数据的临床代表性。数据集有哪些中心、什么时间段、哪些设备型号、患者年龄性别分布、病例严重程度分布。审评要判断的是你用这些数据训练的模型在目标真实人群里还能不能保持性能。如果你训练的肺结节AI只用了低剂量CT的数据而预期用途写的是“适用于所有CT类型”这个矛盾就会被抓出来。算法的临床可解释性。输出的结果是如何被临床用户解读的。深度学习模型是黑箱但审评要求你说明模型在临床使用中如何起到支持作用。比如你输出的是一个病灶热图加风险评分那就要说清楚医生如何结合影像原始图像、临床病史等信息做出最终判断。实际写法上普遍的做法是使用Saliency Map、Grad-CAM等可视化方法提供算法注意力区域的证据并说明这种可视化方法对整个临床决策链路的作用。使用环境差异化的影响。不同医院、不同技师操作、不同扫描参数都会影响AI输入数据的质量进而影响模型表现。CER里需要用敏感性分析或亚组分析来检验这种影响。最简单的做法是按设备品牌或扫描参数分层做性能验证在CER里给出分层结果。3. 攒CER证据的实操路径从性能验证到临床数据3.1 别把性能验证报告和CER割裂开这是我在项目里反复纠正团队的一个习惯性能验证组做完测试报告归档到技术文档跟CER团队各干各的到了要提交的时候才把两份材料放一起然后发现信息对不上。正确做法是在项目启动时就建立一个证据映射矩阵简单说就是一张大表列清楚每个性能验证项目的测试对象、数据集、指标对应的IEC 62304软件确认项或ISO 14971风险控制项对应的临床评价章节和证据等级对应的GSPRGeneral Safety and Performance Requirements通用安全与性能要求条款这样一来审评问“你性能测试的临床意义是什么”的时候你能直接指到临床评价报告里对应的安全性和有效性分析段落。审评问“你临床评价的证据来源是什么”的时候你能直接指到性能测试报告里的原始数据。这种交叉引用做扎实了CER的说服力会强很多而不是让审评官自己去翻三份不同文档才能拼出完整证据链。3.2 从GSPR出发反推证据需求MDR的GSPR有几十条通用要求AI器械不是每条都适用但你得有选择的标准和理由。我的习惯是做一个逐条筛查表对每条GSPR判定适用、不适用、部分适用。每一条适用项都要对应到具体的证据来源。举个例子GSPR第17.1条对软件和IT安全的要求是针对AI医疗器械的重要组成部分。你要证明算法在临床环境中运行的安全性和稳定性这靠的不仅是软件确认报告还包括网络安全分析、数据接口的兼容性验证、系统故障时的降级方案等。CER里要引用这些证据并讨论它们如何影响临床安全。这里有个AI器械特有的问题——模型更新。如果你在上市后调整了算法参数这算不算变更新产品很多AI公司对这个其实是模糊的。在MDR框架下算法更新可能触发完整的再评价流程也可能被认定为同型号的软件版本迭代具体取决于更新的内容和对临床的影响。CER里要写清楚版本变更管理机制并在上市后系统中做相应安排。我建议产品团队提前明确“算法变更需要触发哪些验证活动”的判定逻辑这比事后补救省事得多。3.3 三类常见证据的攒法回顾性数据。这是AI器械最常用的起步证据成本低、速度快。但质量差异很大。我见过不少团队用公开数据集如LUNA16、CheXpert跑性能这作为算法开发的基准没问题作为临床评价证据就太薄弱了。审评很清楚公开数据集的局限性——数据是历史明确的回顾性样本可能与真实患者的分布差异明显设备参数不尽一致且数据经过清洗筛选与真实临床流程脱节。最好用的回顾性数据是你在合作医院拿到的连续病例、带原始DICOM数据的回顾性队列最好是多种CT或MR机型这样才能说明算法在实际临床环境的适应能力。前瞻性数据。包括前瞻性收集的真实临床数据或前瞻性临床试验数据。这是审评最认可的证据但成本也最高。对AI辅助诊断软件来说一个中等规模的前瞻性研究比如几百例患者、多个中心从启动到拿到数据锁库一年是至少的。而且前瞻性研究的方案设计非常关键——纳入排除标准、金标准判定方法、读片独立性与AI交集的处理方式这些设计不合规的话后面审评会一条条问到你补证为止。同品种器械的临床数据。这是传统器械CER的主要证据路径AI器械里不好走。原因前面说过同品种AI器械的核心技术参数很难查到。但如果能找到那也行只是证据论证难度大我不建议AI器械团队把等同性作为主要策略除非你是竞品同一家公司的迭代型号或者通过合作找到了可用的二次数据。3.4 文献检索能少走弯路的操作方式文献检索不是去PubMed随便搜几个关键词需要系统策略和方法论支撑。CER既然按MedDev 2.7/1 rev4的方法来做在MDR时代MDCG 2020-5要求临床评价遵循科学严谨的方法学那么文献检索方案最好包含PICOT框架人群、干预、对照、结局、时间维度多数据库检索PubMed、Embase、Cochrane、中国知网等检索式和Mesh词表纳入和排除标准的明确定义文献筛选流程从标题筛查到全文评估证据质量评估工具QUADAS-2等AI器械文献检索绕不开的一个问题是AI临床研究文献爆炸式增长但质量参差不齐。很多论文没有按临床试验报告标准如STARD-AI来写关键信息缺失——算法版本不明、数据集不完整、重复训练过程不清楚。我的筛选原则是优先纳入有明确算法版本、有外部验证、有清晰统计分析方法的文献只做内部验证且数据量小的降级为支持性证据。3.5 统计分析审阅要点和容易走偏的地方AI器械临床评价报告里统计方法如果不规范直接影响整体可信度。我归纳出几个容易出问题的地方样本量计算很多AI研究不做先验样本量估计或者只是拍脑袋定的。优秀的做法是预设目标敏感性/特异性的置信区间宽度反推样本量。独立验证集调参集和最终评估集必须严格分离。放在论文里后者称为独立的测试集注册资料里这一点更要绝对清晰否则审评会质疑你的性能指标是否有选择偏倚。数据泄露训练集里包含了测试集的相关患者数据这在回顾性数据里时常发生。同一个患者的多条影像数据被分到了不同集合当中。CER里要有防止数据泄露的证明。报告透明度森林图、亚组分析按年龄、性别、病灶大小、疾病严重度分层是审评爱看的内容能直观证明算法性能在不同人群中的稳定性。4. PMCF计划和报告别等上市后才补课4.1 PMCF的核心逻辑闭环PMCF经常被看成一种从属性质的工作——产品上市了还未能及时组织临床随访于是把精力补在注册资料里做一份计划书就万事大吉。这其实是误解而且是在项目后期才发现的大坑。MDR的核心在监视和主题预防机制它对PMCF的期望基于一套完整体系企业不能把产品卖出就完事要通过系统性的上市后数据采集活动持续确认产品的安全性和性能。AI器械因为数据分布会漂移、算法会更新、使用人群会变化这套闭环更关键。一份好的PMCF不只是满足法规它对你产品的后续迭代、市场竞争力也是有实际贡献的。闭环是什么样的CER里标识出尚不确定的临床问题比如长期使用效应、罕见并发症、特定亚组人群的表现PMCF计划针对这些不确定性问题设计数据收集方案PMCF研究完成后数据汇入上市后监督PMS系统评价结果反馈更新CER若发现新的风险/性能下降触发PRRC合规负责人、纠正预防措施或技术文档更新4.2 PMCF计划怎么设计一份能过审的PMCF计划至少要回答需要关注哪些遗留的临床问题为什么这些问题不能靠上市前证据解决用什么方法收集数据文献检索、PMCF研究、PMCF调查还是三者结合每种方法的方案要点样本量、时间跨度、纳入标准、统计方法数据收集后如何分析、如何判定是否需要CAPA与PMS系统的衔接方式对AI器械我特别提醒两个点。第一个是版本更新和陈旧数据问题。AI产品更新快上市后算法小版本迭代频繁。PMCF计划要明确收集的数据关联哪个算法版本如果算法版本更新既往收集的数据还能不能用我建议的实操做法是PMCF数据库里为每条数据打上产品版本号标签后续按版本分组统计分析这样不同版本的性能差异一目了然也为你能稳定地更新CER里关于“各版本性能稳定性”的结论提供了依据。第二个是使用环境RWD真实世界数据的价值。AI器械的PMCF研究不一定都要做成临床试验真实世界数据配合电子病例报告表eCRF、影像归档和通信系统PACS数据采集也很有价值。关键是数据采集的质量控制什么人负责提取数据、怎么确认金标准、怎么核对AI输出与最终诊断的一致性。4.3 PMCF报告里容易被追问的点PMCF报告是定期做的通常一年一次总结过去一段时间的方法、成果、数据分析、结论。写报告时有几个点我见过审评反复追问入选率和样本量计划里写了准备收500例实际上只收到了80例怎么办要么延长收集期要么在报告里说明80例的统计功效是否足够并补充其他证据来源。不能只是写“未达到目标量”就完事。数据清洗和丢失数据真实世界研究里失访、数据不完整是常态报告里要写明采用的处理方法比如采用意向性分析ITT和符合方案集PP分别呈现。结论不明确报告最后不能只写“未观察到新的安全问题”要分析PMCF数据和CER预期结论是否一致。如果出现不一致比如某特定型号设备的AI性能下降必须解释原因并给出行动计划。4.4 PMCF的三种方法怎么选PMCF Plan下可以挂多种方法我按实际项目经验对比一下文献检索的PMCF应用成本最低、适合补充长期使用证据但很难针对性回答你产品的特定问题更像是背景性证据。AI类文献其他团队在类似产品上发表的真实世界应用数据可以为你的产品安全性提供间接参考。PMCF研究注册登记或前瞻数据收集成本中等产出最有价值特别适合AI器械。在多中心连续入组真实患者记录AI输出与最终临床诊断的一致性这能很好地验证CER里关于“真实世界性能”的预期。我带的项目里最理想的方案是随访队列中包含阳性病例的病理/专家会诊金标准验证灵敏度。这需要前期和临床中心充分沟通把流程理顺。PMCF调查问卷方式适合收集用户反馈、可用性信息。对AI器械能收集到医生对AI辅助判断的信任度、工作流程整合程度。但调查问卷的质量控制要求高——问题设计不能诱导、受访者要有代表性、回收率不能太低否则数据说服力不足。4.5 PMCF与PMS的分工经常有人搞混PMCF和PMS。PMS上市后监督是更宽泛的体系包括不良事件报告、趋势报告、警戒系统、文献监测、市场反馈等。在结构化程度较高的PMCF框架里更强调的是以临床数据为基础的主动专项研究侧重于通用的安全性监控两者在数据上可以互用但定位不同不良事件数据库里的累计数据可以用于PMCF分析的风险评估部分用户投诉中的误报率、假阴性案例是PMCF必须深挖的临床信号主动发起PMCF研究的中心同时也是PMS里的重点巡视对象但PMCF必须主动收集和分析临床数据不能坐等被动的事件报告。我见过的典型错误是把PMCF报告写成“本年度共收到X起不良事件报告无非预期事件结论为安全”这跟PMS报告没差别。审评看到这种PMCF体会直接打回要求补充PMCF专有的数据来源分析比如指定研究中心的随访率、遗漏病例的回顾、AI输出在真实病例中的假阴性与假阳性分析等。5. 常见发补问题与“攒材料”节奏建议5.1 审评发补中AI器械的共性问题根据项目中的经验审评对AI器械CER/PMCF的发补集中在这么几类问题一预期用途与临床证据错位。CER写的预期用途很广适用于各级医疗机构、全年龄段证据却只覆盖了三甲医院、特定年龄段。这类问题最容易导致发补。解决办法是在预期用途章节前做一张“适用范围-证据覆盖矩阵”的表逐项核验。问题二等同性论证不成立。聚焦于用公开文献里的算法模型对比自家产品但核心技术参数训练集规模、标注规则、算法结构对不上。这一类带着严重的论证缺损。被发补之后通常只能转成自有数据路径补试验项目周期大幅拉长。问题三数据集描述不充分。只写了“来自三家医院共5000例”但没写设备型号分布、病例严重程度分布、金标准确立方式。AI器械审评对数据集描述的要求接近科研论文的程度建议直接按“数据集卡片”Dataset Card的格式来做数据规范描述它充分反映了数据来源、采集伦理、标注细则、质量控制划分边界等信息基本覆盖审评要关注的核心部分。问题四PMCF计划与CER脱节。CER说“长期安全性需在上市后监测”但PMCF计划里没有针对AI产品性能衰减风险的监测方案。比如持续追踪敏感性和特异性的变化趋势设定“性能警戒线”及触发机制。这是对“长期安全”负责的实质安排不是一句空话。5.2 时间线怎么排才合理AI器械临床评价的节奏我给一个可参考的时间分配阶段内容建议时间立项阶段建立证据映射矩阵、GSPR筛查、确定临床评价路径1-2个月数据准备阶段多中心回顾性数据收集、清洗、标注审核3-6个月性能验证阶段按临床场景做独立测试、分层分析2-3个月前瞻性研究阶段前瞻性队列或临床试验若有需要6-12个月CER撰写阶段文献检索、证据整合、报告撰写、内部评审2-3个月PMCF方案设计阶段PMCF计划撰写、方法选定、与CER衔接可与CER并行提交与发补阶段审评沟通、发补答复3-6个月视项目而定叠在一起就会发现一个走“自有数据前瞻性验证”路径的AI辅助诊断软件临床评价部分从启动到提交资料预留12到18个月是比较稳妥的预估。如果团队打算走等同性路线前期调研竞品数据可得性用一个月的考察来判断可行性是最重要的一步涉及公开数据可得性的核实、临床试验文献的检索评估这个判断做早了能帮你避开6个月后的大方向性返工。5.3 团队配置和内部协作CER/PMCF的“攒”不是一个人的事。最理想配置是注册专员负责流程和文档框架临床研究员负责证据分析和研究设计统计师负责统计分析部分医学工程师或懂算法的产品经理负责保障技术细节和临床用语翻译到位。AI团队通常是工程师为主对医学语言不熟这里我建议一定要有一个能“双向翻译”的人——把算法性能指标如AUC、Dice系数翻译成临床可理解的话语如“在检测灵敏度为90%时每100例患者中约10例早期病变可能被漏检”把临床问题翻译成算法验证指标。这个人选最好在项目早期就定下来。5.4 文件版本管理与评审留痕CER和PMCF在项目周期内一定会多次修改算法版本更新、临床数据补充、审评反馈调整。我强烈建议从一开始就用正规的文件管理系统来管理版本。不要出现“最终版v3_reallyFinal_2.docx”这种文件命名。每个版本的CER要有版本历史表记录修改人、修改日期、修改内容和修改依据。这看起来是小事真实项目里审评要求你对比新旧版本差异时如果拿不出清晰的版本说明会显得整个质量体系混乱。而质量体系的严谨性审评看不见也能通过这种细节判断出来。内部评审流程也别省。CER完成初稿后