夜雨聆风
MDR CE认证:NB发布的MDR技术文档提交最佳实践指南剖析
IVDR CE认证：NB发布的IVDR技术文档提交最佳实践指南剖析
如果说MDR CE认证是一场硬仗，
那么技术文档（Technical Documentation, TD）
就是决定战局走向的主战场。
2025年4月，Team-NB（欧洲公告机构协会）正式更新《Best Practice Guidance for the Submission of Technical Documentation under MDR (EU) 2017/745》V3。
这份文件，
本质上是：
NB们把
“为什么老是卡你”
“到底想看什么”
“哪些坑你反复踩”一次性摊开讲清楚。
本文将帮你站在“NB视角”，
重新理解MDR技术文档
到底该怎么交，
才不被反复打回。
一、这份指南是谁写的？为什么一定要看？
这不是某一家NB的“内部偏好”。
这是Team-NB汇总20+家公告机构的审评经验后，
形成的统一共识版本：
-
对标MDR Annex II & III
-
覆盖绝大多数NB的真实审评关注点
-
明确指出“最常见的延误原因”
一句话：
它不是法规原文，
但它决定了你怎么被“按法规”审。
二、NB最常见的“红牌理由”
不是你不会写，
是你没按他们的逻辑写
Team-NB在正文一开头就点名了两大“致命问题”：
1.技术文档不完整（Incomplete Submission）
典型表现包括：
-
产品描述与申请范围不一致
-
Variant / Accessory没讲清楚
-
Basic UDI-DI覆盖关系混乱
NB看不懂你到底“想认证哪一个产品”。
2.技术文档结构混乱（Lack of Cohesive Structure）
不是没有资料，而是：
-
信息散落各处
-
找不到对应关系
-
Annex II的逻辑被打碎重组
NB不是来“找彩蛋”的，
他们要的是：
清晰、可搜索、一次就能定位的结构。
三、正式递交前
先和NB聊清楚这几件事（非常重要）
Team-NB明确建议：
在提交申请前，
务必与NB进行结构化沟通（Structured Dialogue）。
重点包括：
-
技术文档接受的语言（MDR Article 52(12)）
-
文件命名与文件夹结构偏好
-
提交方式（平台 / PDF / eTMF逻辑）
官方点名可参考：MDCG 2019-6。
一句话：
很多返工，
其实是“没提前对齐格式”。
四、技术文档提交的“底层通关逻辑”
1. Annex II的结构，不是建议，是“导航地图”
NB 明确要求：
-
按Annex II的逻辑组织文件
-
提供完整Index / TOC + 超链接
-
文件夹数量越少越好，但逻辑要清楚
不是你觉得好找，而是NB觉得好找。
2. 报告一定要“完整版”，不要“节选版”
NB明确表态：
-
不接受摘要版测试报告
-
不接受多次修订拼接的报告
-
只接受最新、完整、最终版本
3. GSPR不是“贴报告”，而是“讲逻辑”
常见误区：
“这个GSPR，我放了3个测试报告。”
NB真正想看的是：
-
风险 → 控制措施 → 验证/验证证据
-
每一条GSPR如何被系统性满足
GSPR Checklist
是一条逻辑链，
不是附件仓库。
五、Annex II核心模块：NB到底在看什么？
下面直接按NB的审评节奏，快速拆解重点模块。
1. 设备描述（Device Description）：
所有问题的源头
NB反复强调的一句话：
所有文件中，
产品名称、
预期用途、用
户人群必须100%一致。
重点关注：
-
Intended Purpose ≠ Marketing Language
-
患者人群 / 使用环境 / 使用频率
-
Basic UDI-DI与变体覆盖关系
-
是否存在Novel Feature（说清楚！）
常见雷区：
-
IFU和CER用词不一致
-
Contraindication写得“太干净”
2. 标签&IFU：
NB眼中的“对外承诺书”
NB不是只看你有没有标签，
而是看：
-
是否满足 Annex I GSPR 23
-
是否覆盖所有销售国家语言要求
-
是否与风险管理、临床评价完全一致
一句话：
SSCP、IFU、标签，三者不允许各说各话。
3. 设计与生产：
NB不想看SOP，
想看“你这个产品怎么被造出来”。
Team-NB明确写道：
通用SOP没用，NB要的是“这个产品”的设计与制造逻辑。
重点包括：
-
设计阶段划分与评审证据
-
关键工艺的验证 / 确认（OQ / PQ）
-
关键外包方与质量协议
-
多场地生产的责任划分
4. 风险管理：不接受“形式合规”
NB重点盯三点：
-
风险是否覆盖全生命周期
-
风险控制是否真实落地
-
风险是否与V&V、临床评价联动
常见问题：
-
残余风险缺乏可接受性论证
-
网络安全、软件风险被低估
5. 临床评价（CER / PMCF / SSCP）：
MDR的终极战场
NB的态度非常明确：
-
临床评价是“活文件”
-
Similar Device逻辑必须自洽
-
PMCF不是“写了就行”
一句话送给所有MDR项目：
临床不够，其他写得再好也没用。
六、Annex III：PMS不再是“售后文件”
在MDR下：
-
PMS是合规的一部分
-
PSUR是风险管理的延伸
-
PMCF是临床评价的续集
NB会系统性检查：
-
PMS Plan是否可执行
-
PSUR是否真实使用数据
-
与CER / 风险管理是否形成闭环
七、一个“能加速”的隐藏技巧：合理利用既往评审证据
Team-NB给了一个现实但克制的善意：
-
如果同一NB之前评审过
-
要求本身没变
-
证据也没变
部分模块可以“被引用”，
而不是重审。
但前提是：
-
你仍需提交完整 TD
-
清楚标注：哪里没变、哪里已评审
八、总结
这份MDR技术文档最佳实践指南，
释放了一个非常清晰的信号：
NB
不怕你复杂，怕你混乱；
不怕你写多，怕你写不清楚。
MDR时代，技术文档
早已不是“法规作业”，
而是：
-
一个系统工程
-
一场跨部门协同
-
一次对产品本质的彻底梳理
如果你正在：
-
准备MDR首次认证
-
从MDD迁移到MDR
-
被NB问题反复拉扯
亲爱的读者，感谢您的关注和点赞，请拨动您的小手指多多转发。
成长需要您的陪伴，您的每一次转发都是我深夜耕耘的动力！
