欧盟 MDR 技术文档里检测证据怎么组织

结论：技术文档要的是论证，不是资料汇编

准备技术文档时，常见做法是把手头所有检测报告收集起来放进对应章节。这样做出来的是资料汇编，不是论证。

审查方要看的是：你怎么证明产品满足了每一条适用要求。 报告是证据，但证据需要被组织起来指向结论。缺少这层组织，审查方要自己去建立对应关系，效率低且容易产生疑问。

证据的组织结构

建议按「要求—方法—证据—结论」的结构组织：

要求。 列出适用的每一条通用安全与性能要求。不适用的也要列出并说明为什么不适用。

方法。 说明用什么方式证明满足该要求——检测、分析、文献、或者组合。

证据。 指向具体的报告及其中的具体项目，给出报告编号和页码。

结论。 明确说明该条要求已满足，以及依据是什么。

这个结构的价值在于它强制你逐条检查。 走一遍下来，哪些要求没有证据支撑会立刻显出来，而不是等审查方指出。

与要求的对应关系

第二行和第三行是被追问较多的。 偏离标准或者使用非标准方法时，举证责任明显加重，需要说明方法的适当性以及为什么结果可信。

第五行也要认真写。 「不适用」不能只写三个字，要说明产品的哪个特征使该条不适用。写得含糊，审查方会当作遗漏。

缺口怎么处理

逐条对照下来，通常会发现一些缺口：某条要求没有对应证据，或者证据不够充分。处理方式有几种：

补测。 最直接，但需要时间和样品。

用现有数据重新论证。 有时数据是有的，只是原来没有与该条要求建立联系。梳理一遍可能发现某份报告的某个项目正好能支撑。

用分析或文献支撑。 适用于那些不便通过试验验证的要求。

调整设计或用途表述。 如果某条要求确实难以满足，可以考虑通过设计变更或者调整预期用途来规避。

如实说明限制。 极少数情况下，可以说明产品在某方面的限制并通过使用说明控制风险。

建议按这个顺序考虑：先看现有数据能不能用，再考虑补测，最后才考虑调整设计。很多缺口其实是组织问题而不是数据问题。

常见的组织问题

一是报告堆砌无索引。 附了几十份报告，但没有说明哪份对应哪条要求。

二是引用不精确。 只写「见附件某报告」，没有指明具体项目或页码。审查方要自己翻找。

三是结论缺失。 列了证据但没有明确说「因此满足该要求」。

四是版本混乱。 附的报告是旧版本，而文档正文引用的是新数据。

五是重复与矛盾。 同一项性能在不同章节出现不同数值。

这几类问题不影响产品本身的安全性，但会显著增加审查的往返。

文档的维护

技术文档不是一次性的。产品变更、标准换版、上市后数据积累，都需要更新文档。

建议在建立文档时就考虑维护：用索引表管理证据与要求的对应关系，更新时只需调整索引；给每份证据标注版本和日期；记录每次更新的内容与原因。

没有索引表的文档，几次更新之后就会失控——不知道哪份报告还在用、哪条要求的证据被替换过。

上市后数据的回填

技术文档需要随上市后信息更新。与检测相关的是：如果上市后出现了性能相关的问题，对应的分析与验证数据应当补充进文档。

这部分常年不更新的文档，在监督审核中会被注意到。 一份从获证之后就再没动过的技术文档，本身就是一个信号。

与风险管理文件的呼应

技术文档里的检测证据，应当与风险管理文件相互印证。风险管理里识别的每一项需要通过测试验证的控制措施，都应当能在检测证据里找到对应。

这两份文件由不同的人准备时，最容易脱节。 建议在定稿前做一次交叉核对，用一张表把风险控制措施与检测项目对应起来。

文档的可读性

审查是人在做，文档的可读性影响效率。几个实用做法：每章开头给一段概述说明本章证明什么；表格优于长段落；关键结论加粗或单独成段；证据引用给出精确位置。

可读性好的文档，追问会明显少，因为审查方不需要反复查找和推测。

证据的层级

不同类型的证据说服力不同，组织文档时可以有意识地分层：实测数据的分量最重；经过验证的分析或计算次之；公开文献与同类产品数据再次之；单纯的声明最弱。

对关键要求，应当尽量用高层级的证据。 如果某条关键要求只有声明支撑，即使逻辑上说得通，也容易被要求补充。反过来，对次要要求，用较低层级的证据配合充分说明，通常可以接受。

文档与实物的一致

最后一点：技术文档描述的产品，要与实际生产的产品一致。听起来理所当然，但在产品经历多次小改之后，文档与实物出现偏差是常见现象。

建议定期做一次文档与实物的核对，尤其是在有现场检查预期时。检查方会拿文档对着产品看，对不上就是问题。

我们的做法

我们出具报告时会按项目清晰分段，并给出项目编号，目的之一就是方便委托方在技术文档里精确引用。一份所有项目混在一起、没有编号的报告，引用时只能整份指过去，这会降低文档的可读性。

对于准备技术文档的委托方，如果需要报告在结构上配合文档的组织方式（比如按要求条款分组），可以在委托时提出，我们在报告编排上做相应安排。

如果你在组织技术文档的检测证据部分，或者逐条对照时发现缺口不确定怎么补，可以把对照表和现有报告发过来一起看，或者直接联系：132 4819 8029。能力范围见服务介绍，送检要求见送检要求，更多内容见知识库。

English version

Conclusion. A common approach to technical documentation is to gather every available test report and file it under the relevant heading. That produces a compilation, not an argument. What the reviewer needs to see is how you demonstrate that the product satisfies each applicable requirement. Reports are evidence, but evidence has to be organised so that it points at a conclusion. Without that organisation the reviewer has to construct the correspondence, which is slow and generates questions.

A structure for the evidence. Organise as requirement, method, evidence, conclusion. State each applicable general safety and performance requirement, including those you consider inapplicable, with reasons. State how satisfaction is demonstrated, whether by testing, analysis, literature or a combination. Point to the specific report and the specific item within it, with report number and page. And state explicitly that the requirement is met and on what basis. The value of the structure is that it forces a clause-by-clause check: working through it reveals which requirements lack supporting evidence before a reviewer has to point them out.

Mapping to requirements. Where a harmonised standard applies and is fully followed, cite the standard and provide the report. Where a standard applies but has been partly departed from, explain the departure and its justification and provide supplementary evidence. Where no standard applies, explain the method chosen, why it is appropriate, and provide the data. Where the risk has been eliminated by design, describe the design and provide verification data. And where a requirement does not apply, explain why.

The second and third cases attract the most questions, because departing from a standard or using a non-standard method shifts the burden of demonstration considerably. The last also deserves proper treatment: stating simply that a requirement is not applicable is insufficient, and the product characteristic making it inapplicable should be identified, or a reviewer will read it as an omission.

Handling gaps. A clause-by-clause review usually reveals gaps where evidence is missing or insufficient. Options include additional testing, which is direct but needs time and samples; re-arguing from existing data, since evidence sometimes exists but was never linked to the requirement, and a review may find that an item in an existing report supports it; supporting through analysis or literature, suitable for requirements not readily tested; adjusting the design or the intended use statement where a requirement is genuinely difficult to meet; and, rarely, stating a limitation openly and controlling the risk through the instructions. Consider them in that order: examine existing data first, then testing, and only then design change, because many gaps turn out to be organisational rather than evidential.

Common organisational faults. Reports accumulated without an index, so nothing indicates which supports which requirement. Imprecise citation, referring to an attached report without identifying the item or page, leaving the reviewer to search. Missing conclusions, presenting evidence without stating that the requirement is therefore met. Version confusion, attaching an older report while the text cites newer data. And duplication and contradiction, where the same property appears with different values in different sections. None of these affects the safety of the product, and all of them lengthen review.

Maintaining the file. Technical documentation is not a one-off. Product changes, standard revisions and accumulating post-market data all require updates. Plan for maintenance when building it: manage the requirement-to-evidence correspondence in an index table so updates need only adjust the index; mark every item of evidence with a version and date; and record what changed and why at each revision. Without an index, a file becomes unmanageable after a few revisions, with no clear picture of which reports remain in use or which evidence has been superseded.

How we handle it. We structure reports by item with item numbers, partly so clients can cite precisely in technical documentation. A report in which everything is merged without numbering can only be cited as a whole, which reduces the readability of the file. Where a client needs reports structured to match the organisation of their documentation, for instance grouped by requirement clause, we can arrange that if it is raised when commissioning.

Send us your requirements table and existing reports and we will review the evidence section. Phone or WeChat: +86 132 4819 8029.