做医疗器械软件，文档的本质，就是向审评机构证明你的软件在整个生命周期中都处于受控状态，并且真的安全有效。要把这件事讲清楚，最核心的遵循标准是IEC 62304《医疗器械软件 软件生存周期过程》，并且要和ISO 14971风险管理牢牢绑定，再根据不同国家的要求做适配。

第一步：搞清楚自己要符合哪些法规

动笔之前，先明确产品的“出生证”要求，不同市场对应不同的尺度。

IEC 62304：按软件对患者/使用者的危害程度，把软件分成 A、B、C 三个安全级别，级别越高，文档要求越严格。

ISO 14971：风险管理的总纲，软件的风险控制措施最终都要落地到需求、设计和测试里。

NMPA（中国）：遵循《医疗器械软件注册审查指导原则》等，注册时要交软件研究资料。

FDA（美国）：参考《Content of Premarket Submissions for Software Contained in Medical Devices》，中等和高关注度都需要递交软件文档。

CE（欧盟）：在MDR框架下要符合IEC 62304，技术文档里必须包含完整的软件验证与确认证据。

必须产出的文档全景图

按生命周期阶段把该写的文档全部列出来。安全级别C要求最完整，A可以适当裁剪，但框架不变。每一份文档的目的要心里有数。

策软件开发计划 (SDP)

定义整个开发流程、采用的标准、工具链、人员职责和里程碑，相当于项目的“宪法”。

配软件配置管理计划 (SCMP)

版本如何控制、分支怎么拉、基线何时打、变更怎么走，所有代码和文档的“户口本”。

需软件需求规格说明书 (SRS)

功能、性能、接口、安全、报警……所有要求必须写在这里，且每一条都要可测试。

构软件架构设计文档 (SAD)

顶层结构、模块切分、内外部接口，安全级别隔离策略全在这里交代。

详软件详细设计文档 (SDD)

深入到每个单元的内部逻辑、算法、数据流，C级产品必须写到位。

测单元/集成/系统测试方案与报告

分别验证最小单元、模块间接口、完整系统，必须覆盖正常、异常、边界和压力场景。

发软件发布报告

确认发布版本、已关闭的问题、残留风险评估，准予放行的签字背书。

维软件维护计划

上市后的缺陷修复、版本升级流程，以及对第三方组件（SOUP）的持续监控。

溯可追溯矩阵 (RTM)

把需求—设计—实现—测试—风险控制全链条串起来，让审评一眼看到闭环。

异软件问题解决报告/异常处理记录

开发中任何缺陷、偏离、变更，都要记录现象、影响分析和解决方案。

特别提醒：NMPA注册时还需要一份《软件描述文档》，内容涵盖基本信息、实现过程和核心功能。不用单独从零写，把上面这些文档中的关键信息提炼汇总就能形成。

每份文档怎么写才不掉坑

1. 软件开发计划 (SDP)

说明采用哪种开发模型（瀑布、迭代或V模型），并映射到IEC 62304的过程要求。明确软件的安全级别和分类依据。必须列出所有要产出的文档清单及模板引用，同时写清楚配置管理、问题解决和质量保证的支持流程。

2. 软件需求规格说明书 (SRS)

一定要把风险控制措施直接写成需求（比如报警阈值、故障安全状态）。每条需求给一个唯一ID，用“系统应在500ms内响应”这种可验证的表述，别用“系统应快速响应”。覆盖功能、性能、接口、信息安全、可用性等全部维度。

3. 软件架构设计文档 (SAD)

划分软件单元/模块，给出接口和控制流。若系统里混着不同安全级别的软件，必须画出隔离边界，防止低级别干扰高级别——这是C级产品的审查重点。结构图、状态图能放就放，并标注所有第三方现成软件（SOUP）的版本。

4. 软件详细设计文档 (SDD)

深入到伪代码、算法逻辑和数据结构。C级产品这一块不可或缺，目的是保证每个单元都能独立进行测试和验证。

5. 测试方案与报告

方案里要讲清楚测试环境、策略和用例选择逻辑，正常、异常、边界、压力场景缺一不可。报告里每条用例的实际结果、通过与否、失败后关联的问题报告号都要如实记录。系统测试必须能追溯到SRS的所有需求，尤其不能漏掉风险控制需求的测试。

6. 可追溯矩阵 (RTM)

一张大表，纵向需求ID，横向串联设计模块、实现代码、测试用例。还要往前追溯到风险项（该需求控制的是哪条危险），往后关联问题报告。最终要做到每条需求都有测试覆盖，代码里没有任何多余的无源功能。

7. 配置管理与问题解决

配置管理要能展现完整的版本变更历史，确保任何发布版本可以一键还原。问题报告要记录现象、影响分析、修复方案，以及回归测试通过的证据。

贯穿始终的四条心法

风险管理一体化

软件风险分析不是孤立的活动。要把危险情况直接转化成需求，落实到设计和测试里。文档中要频繁出现“因为风险X，故增加需求Y，并由测试Z验证”这样的闭环描述。

可追溯性就是生命线

审评老师一定会检查系统测试能否追溯回需求，需求能否追溯到风险。这是最常见的发补点，从一开始就搭好追溯框架能省去巨大的返工成本。

版本一致，基线管理

提交注册时，所有文档的版本号必须与待测软件版本、测试报告版本严格匹配，不能出现任何错位。

对现成软件（SOUP）保持警惕

操作系统、数据库、开源库都属于SOUP。架构文档中要列出它们，评估安全缺陷，并在维护计划里写明如何持续跟踪其漏洞公告。

几点建议

先搭追溯骨架，再填充内容：需求ID确定后就把RTM的框架建好，每写一条需求或一个用例都及时填入，避免最后补得手忙脚乱。

时刻问自己“怎么测”：写任何需求或设计时，心里立刻想这条将来能不能被客观地验证，避免写出无法测试的模糊描述。

用好工具，事半功倍：推荐使用Polarion、Doors等专业文档管理工具，或者用GitLab Markdown配合版本管理，自动生成追溯矩阵和版本快照。

找成熟模板参照：借鉴已经通过审评的文档框架，避免出现结构性缺失，比自己从零摸索高效得多。

本文由广州佳誉医疗器械有限公司/佛山浩扬医疗器械有限公司联合编辑