SaMD设计开发文档要求

对软件医疗器械而言，设计开发文档既是研发过程的产物，也是证明产品安全有效的主要证据。无论是注册申报、体系核查还是飞行检查，审核人员都通过文档还原开发过程的可控性。本文从文档体系、内容要点与管理要求三个层面梳理SaMD设计开发文档的编制方法。

文档体系与设计历史文档（DHF）

SaMD的设计开发文档通常构成设计历史文档（DHF），记录从策划到确认的全过程。建议按层级组织：第一层为策划类文档，包括软件开发计划、风险管理计划、验证与确认计划；第二层为需求与设计类文档，包括用户需求、软件需求规格、体系结构与详细设计说明；第三层为实现与验证类文档，包括配置管理记录、测试计划与报告、静态分析记录、缺陷清单；第四层为确认与交付类文档，包括临床评价或确认报告、可用性报告、发布说明与用户文档。层级清晰有助于审核追溯，也便于不同角色各取所需。

需求文档：从用户需求到软件需求

需求是文档体系的源头，其质量直接决定后续设计与验证的有效性。用户需求应描述临床使用场景、使用者特征、期望达成的医疗目的与关键性能；软件需求则须转化为可验证的表述，包含功能需求、性能需求（响应时间、精度、并发量）、接口需求、数据需求、安全需求与运行环境约束。每条需求应有唯一编号与可验证的验收准则，避免使用快速、友好这类含糊措辞。需求变更时须保留历史版本与变更理由，确保任何时候都能回答为什么这样设计，这一点在审评问答与缺陷调查中尤为重要。

设计文档与可追溯矩阵

体系结构文档应说明模块划分、模块间接口、数据流与控制流、外部系统依赖以及安全隔离设计；详细设计则描述关键算法、数据结构、异常处理与状态机。设计文档的实际价值在于支撑风险分析与变更影响评估，因此不必追求形式上的厚度，而应保证关键决策可解释、可复核。可追溯矩阵是文档体系的枢纽，通常用表格建立用户需求、软件需求、设计元素、风险措施、测试用例与缺陷之间的双向关联。缺失追溯是审评发补与检查缺陷的高频原因，建议在需求基线确定后即同步建立矩阵，并随开发推进持续维护。

验证与确认文档

验证文档回答是否正确地构建了软件，确认文档回答是否构建了正确的软件。验证侧应包含测试计划（范围、策略、环境、准入准出准则）、测试用例与执行记录、缺陷记录与回归测试记录，必要时补充静态代码分析与覆盖率分析；确认侧则包括临床评价资料或同品种比对资料、可用性评价报告、真实场景或模拟场景的用户确认记录。对于输出诊断或治疗建议的软件，确认证据尤为关键。所有测试都应记录环境版本、数据版本与执行人，保证结果可复现，并便于后续缺陷定位与回归。

文档受控、变更与归档

设计开发文档必须纳入文件控制与记录控制：版本受控、审批留痕、作废版本隔离、电子文档具备权限管理与审计追踪。变更发生时，应按变更控制程序评估对安全有效性、已验证状态与注册资料的影响，并在实施后更新受影响文档与追溯矩阵。文档归档应明确保存期限（通常不短于产品生命周期加法定年限）、存储介质与责任人，电子归档需考虑备份与长期可读性迁移。内审时应抽查文档与实际代码、实际产品的一致性，这是验证文档真实性、防止事后补写的最有效手段。

好的设计开发文档不是事后补写的装饰品，而是研发过程留下的真实足迹。以需求为源头、以追溯为主线、以受控为保障，企业才能建立起既满足监管要求、又真正服务于研发质量的文档体系。