3. SaMD质量管理体系与设计控制

对SaMD而言，质量管理体系不是一套挂在墙上的文件，而是把“法规要求”翻译成“工程动作”的转换器。ISO 13485给出医疗器械质量体系的通用骨架，21 CFR 820（现已被QMSR并入ISO 13485框架，但设计控制条款的实质要求延续）规定美国市场的设计控制细节，IEC 62304则专门回答“软件怎么算合规”。三者叠加后，落到研发团队手里的核心对象就是：设计输入、设计输出、设计评审、设计验证、设计确认，以及承载全部证据的设计历史文档（DHF）。

三套标准的职责边界

ISO 13485强调“过程方法+风险管理+可追溯性”，它要求组织识别产品实现全过程，并对每个过程规定职责、输入、输出和监视测量方式。21 CFR 820.30的设计控制把产品实现过程切成若干必须留痕的环节：设计输入、设计输出、设计评审、设计验证、设计确认、设计变更、设计历史文档。IEC 62304则把软件生命周期拆成开发过程（5.1~5.8）、维护过程（6.x）、风险管理过程（7.x）、配置管理（8.x）和问题解决（9.x），并按软件安全分级（A/B/C）决定各过程的严格程度。

工程落地的关键不是分别满足三套标准，而是建立一张“要求—过程—证据”的映射表。例如：IEC 62304的5.2“软件需求分析”对应21 CFR 820.30(c)的设计输入，其输出是软件需求规格说明书（SRS）；5.4“软件详细设计”对应820.30(d)的设计输出，输出是详细设计文档（SDD）；5.5“软件单元实现与验证”和5.6“软件集成与集成测试”共同支撑820.30(f)的设计验证；5.7“软件系统测试”与5.8“软件发布”则同时服务于设计验证和设计确认的证据链。

设计输入：把“想要什么”变成“可验证的条款”

设计输入不是一句“系统应安全可靠”，而是可测试、可追溯、无歧义的条目集合。以一款“AI辅助肺结节检测软件”为例，输入至少来自四个方向：用户需求（放射科医生希望在PACS中直接调用，单次分析≤30秒）、法规要求（NMPA三类械、FDA 510(k)、GDPR数据保护）、风险控制措施（算法置信度低于阈值时必须提示“需人工复核”）、以及前代产品的问题报告。每条输入应分配唯一ID，例如INP-001“软件应支持DICOM 3.0格式的CT序列导入”，并注明来源、验收准则和优先级。

IEC 62304 §5.2要求从系统需求中分配软件需求，并评估软件需求对系统风险的贡献。实操中，建议在需求管理工具（如Jama、DOORS或GitLab Issue）中建立需求类型字段：用户需求（UR）、软件需求（SRS）、风险控制需求（RCR）。每条SRS必须能追溯到至少一条UR或RCR，否则就是“无源需求”，评审时应质疑其必要性。

设计输出：从需求到可构建的规格

设计输出是“如何实现”的文档化表达，包括软件架构图、模块划分、接口定义、数据模型、算法流程和单元规格。IEC 62304 §5.3要求架构设计识别软件项及其接口，§5.4要求对每个软件项进行详细设计。输出必须满足输入，且本身可被验证。例如SRS要求“结节检测灵敏度≥95%”，SDD中应明确：预处理采用何种窗宽窗位、模型输入尺寸、推理阈值、后处理NMS参数，以及对应的单元测试用例。

一个常见的工程陷阱是：设计输出只写“调用AI模型”，却不写模型版本、输入张量形状、预处理归一化参数。这会导致验证阶段无法复现，DHF中缺少可审查的技术细节。建议在SDD中为每个算法模块记录：输入数据规格、输出数据规格、依赖库及版本、异常处理策略、性能约束。

设计评审：不是签字仪式，而是缺陷拦截

820.30(e)要求在设计开发各阶段进行正式评审，参与人员应包括各职能代表。评审的有效性取决于“有没有带着问题来”。实操中可采用分级评审：需求评审（检查完整性、可测试性、追溯性）、架构评审（检查模块耦合、接口一致性、安全分级）、代码评审（检查编码规范、静态分析告警）、测试评审（检查用例覆盖率、边界条件）。每次评审应输出问题清单，每个问题指定责任人和关闭期限，并在DHF中保留评审记录和关闭证据。

设计验证与设计确认：回答两个不同的问题

设计验证回答“我们是否正确地构建了产品”，即输出是否满足输入。对软件而言，验证手段包括单元测试、集成测试、系统测试、静态代码分析、代码覆盖率分析。IEC 62304按安全分级规定验证深度：A级可仅做系统测试，B级需单元验证或集成验证，C级必须进行单元验证并达到语句覆盖率要求。例如C级模块要求语句覆盖率100%，分支覆盖率通常要求≥90%（具体阈值应在软件验证计划中定义并说明理由）。

设计确认回答“我们是否构建了正确的产品”，即产品在预期使用环境下是否满足用户需求。SaMD的确认通常包括：模拟临床工作流的端到端测试、可用性测试（IEC 62366）、临床评价或临床试验。确认必须在代表性环境中进行，使用代表性数据。例如肺结节软件应在至少包含不同扫描参数、不同结节大小和位置的测试集上评估，并记录灵敏度、特异度、每例假阳性数等指标。

DHF构建：让证据可检索、可追溯、可审计

DHF不是一堆PDF的堆砌，而是一个结构化、版本受控、可追溯的证据库。820.30(j)要求DHF包含或引用所有设计活动的记录，以证明设计符合批准的设计计划。工程落地建议按以下结构组织：

• 设计计划：阶段划分、职责、评审节点、验证确认策略。
• 设计输入：UR、SRS、RCR及来源文件。
• 设计输出：架构、SDD、接口规格、构建脚本、发布说明。
• 评审记录：评审计划、检查表、问题跟踪、关闭证据。
• 验证记录：测试计划、用例、执行日志、覆盖率报告、缺陷报告。
• 确认记录：临床评价方案、可用性报告、确认测试报告。
• 变更记录：变更申请、影响分析、变更验证、批准记录。
• 追溯矩阵：需求—设计—测试—结果的双向链接。

在工具层面，DHF可以映射到Git仓库的目录结构：/dhf/plan/、/dhf/input/、/dhf/output/、/dhf/review/、/dhf/verification/、/dhf/validation/、/dhf/change/、/dhf/trace/。每个文件带版本标签，与软件发布版本绑定。这样，当审核员问“V2.3.0的结节检测阈值是多少、谁批准的、验证结果如何”时，可以在几分钟内给出完整证据链。

三标准落地的检查要点

把这三套标准落到工程上，最终检验标准只有一个：当审核员随机抽取一条需求，你能否在十分钟内展示它的来源、对应的设计、验证它的测试用例、测试结果、以及任何变更的影响分析。能做到这一点，质量管理体系就不是负担，而是产品迭代的加速器。