2. 医疗行业法规与标准概览

医疗软件不同于一般商业软件，它的需求与架构从第一天起就被多套法规与标准同时约束。理解这些约束的关键，不是背下标准编号，而是弄清每套法规“管什么、管到哪一层、在需求与架构上留下什么痕迹”。本节按约束对象把主要法规标准分为四类：市场准入类（FDA、NMPA）、软件过程类（IEC 62304）、质量体系类（ISO 13485）、数据合规类（HIPAA、GDPR）。它们并非并列关系，而是分别作用于产品生命周期、组织能力和数据流转三个层面。

一、市场准入：FDA 与 NMPA 决定“能不能上市”

FDA 对医疗软件的核心判断依据是器械的风险等级与预期用途。含软件的产品通常按 510(k)、De Novo 或 PMA 路径申报，软件本身若为独立医疗器械（SaMD），则依据 IMDRF 风险框架分为 I～IV 类。FDA 在审评中重点看两件事：软件描述文档是否覆盖了预期用途、运行环境和风险控制；以及软件是否按“基本要求”建立了可追溯的设计控制。对需求工程而言，这意味着每条需求都要能追溯到风险项和验证证据，需求文档不是功能清单，而是风险控制的载体。

NMPA 的约束逻辑类似但更强调注册检验与体系核查的联动。软件作为医疗器械组成部分或独立软件，需按《医疗器械软件注册审查指导原则》提交软件研究资料，包括软件描述文档、网络安全描述文档和现成软件（SOUP）清单。一个常见的实操要点是：软件版本号的命名规则必须在需求阶段就确定，因为注册资料、说明书、标签和后续变更都要引用同一版本标识。若版本规则在开发中期才补，往往导致注册资料与设计文档不一致，触发发补。

二、软件过程：IEC 62304 决定“怎么开发”

IEC 62304 把软件生命周期划分为开发、维护和风险管理三类过程，并按软件安全等级 A、B、C 规定不同的过程要求。A 级（不可能造成伤害）可只做基本活动；B 级（可能造成非严重伤害）要求架构设计、详细设计和单元验证；C 级（可能造成死亡或严重伤害）还要求更严格的追溯与验证独立性。它对架构的直接影响是：安全等级决定了架构必须被拆到多细、每层要留多少证据。例如 C 级软件要求把安全相关功能与非安全功能在架构上隔离，避免一个模块的失效传播到安全功能。

IEC 62304 还要求对 SOUP（现成软件，如第三方库、操作系统、开源组件）进行清单管理和风险评价。实操中通常建立一张 SOUP 清单，字段包括名称、版本、供应商、用途、已知异常、风险等级和验证方式。这张清单不是文档装饰，它直接约束架构选型：引入一个未经验证的开源库，就要为它补风险分析和验证活动，成本可能高于自研。

三、质量体系：ISO 13485 决定“组织怎么保证一致性”

ISO 13485 是医疗器械质量管理体系标准，它不直接规定软件技术细节，但通过设计控制、文件控制、采购控制、纠正预防措施等条款，把软件需求与架构纳入受控范围。最实际的影响是需求变更必须走变更控制流程：变更申请、影响分析、评审、批准、验证、更新追溯矩阵，缺一不可。对架构而言，ISO 13485 要求设计输入与设计输出之间有可验证的对应关系，因此架构决策记录（ADR）和需求追溯矩阵成为体系审核的常见证据。

四、数据合规：HIPAA 与 GDPR 决定“数据怎么流”

HIPAA 关注受保护健康信息（PHI）的隐私与安全，要求实施访问控制、审计日志、传输加密和最小必要原则。GDPR 则从个人数据主体权利出发，要求合法性基础、数据最小化、目的限制、存储期限和跨境传输合规。两者对架构的约束非常具体：数据分类分级、加密边界、审计日志、数据留存与删除机制必须在架构中显式设计，而不是事后补丁。例如，若系统需要把欧洲患者数据传输到境外服务器，GDPR 要求评估传输合法性并可能采用标准合同条款，这会直接改变部署拓扑。

五、四类约束如何落到需求与架构上

把上述法规标准放在一起看，会发现它们对需求与架构的约束是分层的。市场准入层决定必须提交什么证据，因此需求必须可追溯到风险与验证；软件过程层决定过程必须做到多细，因此架构必须按安全等级拆分并隔离；质量体系层决定变更必须多受控，因此架构决策和需求基线必须留痕；数据合规层决定数据必须怎么流，因此部署拓扑、加密边界和日志策略必须显式设计。

一个常见的误区是把这些标准当成“文档工作”，在开发后期补材料。实际经验是：法规约束越早进入需求和架构，返工成本越低。例如，若在架构设计阶段就确定安全相关模块与非安全模块的隔离边界，IEC 62304 C 级的验证范围会清晰很多；若在需求阶段就定义数据分类和跨境规则，GDPR 合规评估就不会推翻已完成的部署方案。

六、一个简化的对照示例

假设某款软件为 IEC 62304 C 级、面向中国和欧盟市场、处理患者生理数据。其约束映射可简化为：

这张表的价值不在于形式，而在于它迫使团队在写需求和画架构图时，同步回答“这条法规要求我留下什么证据”。当每条需求都能找到对应的法规来源和验证方式，需求与架构就不再是孤立的技术文档，而是合规证据链的一部分。