一句话总结
Clause 14 为你的设备中每一个可编程电子子系统建立了从需求到退役的完整软件工程纪律 —— 如果软件失效会威胁基本安全或基本性能，你就必须执行可裁剪的 PEMS 生命周期，并将 IEC 62304 的软件过程嵌入其中。
什么是 PEMS —— 适用性判定（14.1 / 4.2 / 4.3）
PEMS（Programmable Electrical Medical System） 是指包含一个或多个 PESS（Programmable Electronic Subsystem） 的 ME 设备或 ME 系统。
每个 PESS 是一组硬件加软件（含固件）的集合，能执行程序指令。一台典型的 PEMS 可能包含：
- 主控 MCU 上的嵌入式固件
- 上位机 PC 软件或移动端 App
- FPGA 上的软核处理器逻辑
- 云端参与安全决策的处理算法
适用性判定 是你面对 Clause 14 时要做的第一件事。Clause 14 并非对所有含软件的设备自动生效，触发条件如下：
| # | 触发条件 | 判据来源 |
|---|---|---|
| 1 | PESS 提供 基本安全（BASIC SAFETY）功能 | 4.2 |
| 2 | PESS 提供 基本性能（ESSENTIAL PERFORMANCE）功能 | 4.3 |
| 3 | 风险管理显示 PESS 失效会导致 不可接受的风险 | Clause 4 + ISO 14971 |
何时不适用：PESS 仅用于非安全辅助功能（如日志打印、非临床数据统计、UI 美化），且其失效后的风险经评估在可接受范围内。
实践提示：在你的风险管理文件中显式记录"PEMS 要求为何适用或不适用"的判定依据。对绝大多数现代医用电子设备，Clause 14 几乎总是适用。
PEMS 开发生命周期（14.4）
14.4 要求你建立并文档化一个 PEMS 开发生命周期。这不是强制你采用 V-model 或 Agile，而是要求你：
- 定义里程碑：生命周期必须被划分为有意义的阶段节点
- 每个里程碑需明确：完成的活动、验证方法与接收准则、包含的风险管理活动
- 生命周期必须裁剪：针对每个具体开发项目定制，不允许直接套用模板
裁剪应考量：PESS 软件风险等级（A/B/C）、PESS 数量与交互复杂度、SOUP 的存在与依赖程度、是否有遗留子系统、用户可配置/可编程范围。裁剪的决策和理由必须写入 PEMS 生命周期文档。
文档与风险管理的接口（14.2 / 14.3 / 14.6）
14.2 文档控制
PEMS 相关文档须纳入正式的文档控制体系。这意味着所有需求文档、设计文档、测试报告、风险管理记录、问题报告都需受控：版本管理、可追溯性、审批流程缺一不可。
常见失败模式：白板设计、Post-it 需求、口头决定 —— 这些都不满足 14.2。你必须将它们转化为可追溯的文档记录。
14.3 风险管理计划
风险管理计划中必须引用 PEMS 验证计划。两个计划的接口必须在风险管理计划中明确声明 —— PEMS 验证是风险控制措施验证的重要组成部分。
14.6 PEMS 风险管理过程
这是 Clause 14 中最具实质性的子条款之一。你需要识别的致因来源覆盖：
| 致因维度 | 具体示例 |
|---|---|
| 软件方面 | 算法缺陷、时序错误、溢出、死锁、优先级反转、栈溢出、内存泄漏 |
| 硬件方面 | 位翻转（软错误）、EMC 干扰导致数据损坏、时钟漂移、看门狗失效 |
| IT 网络 | 网络延迟/丢包/断连、未授权访问、数据篡改、恶意软件 |
| 第三方来源 | SOUP/SOTA 中的已知缺陷、库函数边界条件未覆盖 |
| 遗留子系统 | 旧版固件与新硬件的兼容性、未文档化的隐式假设 |
五种典型 PEMS 危险：
| 危险 | 说明 | 示例场景 |
|---|---|---|
| 非预期的反馈环路 | 闭环控制中算法输出反作用于输入产生振荡 | 输注泵压力反馈 → 电机调速 → 压力变化 → 不稳 |
| 数据不可用 | 预期数据因软件错误或资源竞争而无法获取 | 波形缓存被日志占满，实时波形无法渲染 |
| 数据完整性缺失 | 数据被意外修改或损坏 | CRC 校验多项式错误，损坏数据被当作有效数据 |
| 非预期的 PESS 交互 | 多个 PESS 之间产生未预见的系统行为 | PESS#1 报警触发 PESS#2 状态转换但未设计握手协议 |
| SOUP 质量未知 | 使用第三方库但未评估安全边界 | 消费电子 RTOS 用于安全关键 PWM 控制 |
风险控制措施可分配到：传感器（输入验证、冗余投票）、执行器（安全状态驱动、看门狗切断能量）、PESS（软件保护环、冗余计算通道）、接口（通信校验、超时处理、退化模式）。分配结果必须在 14.8 架构文档中明确记录。
需求规格与架构设计（14.7 / 14.8）
14.7 需求规格
你必须文档化 PEMS 的需求规格，至少包含：
- 功能需求：PEMS 需要实现的功能
- 性能需求：实时性约束、响应时间、吞吐量（对呼吸机、体外除颤器等软实时设备尤其关键）
- 安全需求：从风险管理导出的安全功能需求（冗余、错误检测、安全状态定义）
- 接口需求：与传感器、执行器、其他 PESS、IT 网络、操作者的所有接口
- 约束条件：硬件资源限制（ROM/RAM/CPU 频率）、操作系统限制、编程语言限制
需求应满足：无歧义（每个需求只有一个合理解释）、可验证（存在客观方法判断是否满足）、可追溯（能追溯到风险控制措施或用户需求）。
14.8 架构
你必须指定满足需求的架构，并将风险控制措施分配到子系统/组件。架构文档应覆盖：
- PESS 之间的数据流和控制流
- 传感器数据采集链路（从物理量到数字量）
- 执行器驱动链路（从控制命令到物理动作）
- 安全状态和故障安全（fail-safe）路径定义
- 外部接口（IT 网络、用户界面、维护接口）的隔离策略
- 关键数据的存储与传输保护
风险控制措施的分层分配示例（输液泵防止过量输注）：
系统级安全需求：防止过量输注
├── PESS 层：速率限制算法 + 累积剂量监控 + 两路独立计时器交叉校验
├── 执行器层：硬件过流保护 + 机械止动
├── 传感器层：双路压力传感器一致性检查
└── 接口层：看门狗超时 → 执行器断电
实现与验证过程（14.9 / 14.10 / 14.11）
14.9 设计与实现
设计应从架构逐层细化到可实现的模块/单元。实现应遵循既定的编码规范/标准。如果采用 IEC 62304，需执行对应风险等级的开发过程要求。
14.10 验证（Verification）
对 PEMS 的每个生命周期阶段输出进行验证，包含三个层次：
| 层次 | 验证内容 | 阶段 |
|---|---|---|
| 单元验证 | 单个软件模块/硬件单元的正确性 | 实现阶段 |
| 集成验证 | 模块间接口和交互的正确性 | 集成阶段 |
| 系统级验证 | PEMS 整体满足需求规格 | 验证阶段 |
验证方法包括代码审查、静态分析、单元测试、集成测试、硬件在环（HIL）测试等。
14.11 PEMS 确认（Validation）
这是 Clause 14 中审核员最常关注的条款。核心要求：
| # | 要求 | 说明 |
|---|---|---|
| 1 | 确认计划必须包括基本安全和基本性能的确认 | 不只看功能正确性 |
| 2 | 确认方法必须文档化 | 明确测试用例、环境、通过/失败判据 |
| 3 | 确认负责人必须独立于设计团队 | 独立性要求 |
| 4 | 设计者不得确认自己的设计 | 防止利益冲突 |
"独立于设计团队"的实践含义：
- 确认者不得是 PEMS 研发项目的直接参与者
- 至少确保确认者和被确认模块的设计者不是同一人
- 小型公司可用其他项目成员或具有相关专业知识的 QA 人员
- 外包开发时，确认需由制造商（法规责任方）指定独立人员执行
变更控制与 IT 网络（14.12 / 14.13）
14.12 变更控制
建立文档化的变更控制流程，适用于 PEMS 的全生命周期：
变更请求 → 影响分析（安全/基本性能/其他功能/62304 等级影响）
↓
评审与批准
↓
实施变更
↓
验证变更
↓
回归测试（受影响的功能和路径）
↓
更新相关文档（需求/架构/设计/风险管理）
↓
发布
关键点：影响分析必须包含对基本安全和基本性能的影响评估；变更在发布前必须经过与原开发同等水平的验证；如果变更影响软件风险等级，需触发风险管理重新评估。
14.13 PEMS 与 IT 网络
如果 PEMS 连接到 IT 网络，随机文件中必须说明：
| 信息要求 | 内容 |
|---|---|
| 连接目的 | PEMS 通过网络做什么（数据导出、远程监控、软件更新） |
| 网络特性要求 | 带宽、延迟、可靠性、协议（TCP/IP、HL7、DICOM） |
| 所需配置 | IP 地址分配方式、防火墙规则、VLAN 隔离建议 |
| 安全规格 | 加密要求、认证机制、访问控制、防病毒建议 |
| 信息流 | 哪些数据流向网络、数据结构、频率 |
| 预期风险 | 网络连接失败、数据延迟、安全攻击的临床风险 |
14.13 的信息属于提供给用户的"使用要求"，目的是让医疗机构 IT 部门在部署前能做合规判断。这些信息应写入随机文件（使用说明书或安装手册）。
IEC 62304 与 PEMS 风险分类 A/B/C
两个标准的接口关系
IEC 60601-1 Clause 14 和 IEC 62304 是"上下级"关系：60601-1 管 PEMS 系统级（硬件 + 软件），62304 管其中的软件生命周期。
| IEC 62304 条款 | 内容 | 在 60601-1 中是否要求 |
|---|---|---|
| 4.3 软件开发计划 | 制定并维持软件开发计划 | 是 |
| 5 软件开发过程 | 需求分析、架构、详细设计、实现、验证 | 是 |
| 6 软件维护过程 | 发布后监控、问题报告、变更管理 | 否（上市后监控由 ISO 13485 + 法规覆盖） |
| 7 软件风险管理过程 | 软件风险分析 | 是（纳入 14.6） |
| 8 软件配置管理过程 | 版本管理、配置识别 | 是 |
| 9 软件问题解决过程 | 问题报告、分析、纠正 | 是（对应 14.5） |
实践建议：虽然 60601-1 不要求 IEC 62304 第 6 章（上市后监控），但几乎所有监管机构（FDA QSR、EU MDR）都要求。实际项目中通常完整实施 62304 的全部条款。
多等级共存策略
一个 PEMS 中可能包含多个不同等级的 PESS：
- 分割原则：不同等级 PESS 的隔离需在架构中明确设计（14.8）
- 粒度建议：将等级 C 的软件功能聚合到独立 PESS/软件单元中，降低维护和变更影响
- 无法彻底分割时：采用"就高原则"——整个 PESS 按最高等级管理
SOUP 管理策略
SOUP（Software Of Unknown Provenance） 在 IEC 62304 中定义为：已开发但未知其开发过程是否充分，或开发过程不充分的软件项。现在更常用术语 SOTA（Software Of Third-party Availability）。包括：商用嵌入式 RTOS（FreeRTOS、ThreadX）、开源通信协议栈（lwIP、MQTT）、第三方数学/信号处理库、芯片厂商 SDK 驱动、编译器运行库。
SOUP 合规处理的六个步骤：
- SOUP 识别：名称、版本、来源、许可证
- 风险评估（14.6）：SOUP 是否参与安全功能 → 决定测试深度
- 异常状态列表（Anomaly List）：来自厂商已知缺陷 + 开源社区 issue tracker
- 后果分析：每种异常状态在设备层面的风险后果及可接受性
- 风险控制措施：输入验证保护、运行监控、看门狗等
- 文档化：将以上全部纳入受控文档
合规检查清单
核心文档（14.x）
| # | 文档/记录 | 条款 | 状态 |
|---|---|---|---|
| 1 | PEMS 适用性判定（不适用时记录理由） | 14.1 | ☐ |
| 2 | PEMS 文档控制体系（版本管理、审批） | 14.2 | ☐ |
| 3 | 风险管理计划（含 PEMS 验证计划引用） | 14.3 | ☐ |
| 4 | PEMS 开发生命周期文档（含里程碑与裁剪理由） | 14.4 | ☐ |
| 5 | 问题解决方案（工具 + 流程 + 记录） | 14.5 | ☐ |
| 6 | PEMS 风险管理记录（致因、危险、措施） | 14.6 | ☐ |
| 7 | PEMS 需求规格 | 14.7 | ☐ |
| 8 | PEMS 架构文档（含风险控制措施分配） | 14.8 | ☐ |
| 9 | 详细设计文档 | 14.9 | ☐ |
| 10 | 验证计划与报告（单元/集成/系统级） | 14.10 | ☐ |
| 11 | PEMS 确认计划与报告（含独立性声明） | 14.11 | ☐ |
| 12 | 变更控制流程与记录 | 14.12 | ☐ |
| 13 | IT 网络连接说明（适用时） | 14.13 | ☐ |
审核重点关注
| 审核重点 | 准备建议 |
|---|---|
| PEMS 确认的独立性 | 确认报告中明确确认人姓名、角色、与设计团队的关系声明 |
| SOUP 异常状态处理 | 准备 SOUP 已知缺陷列表 + 每个缺陷的设备层面风险评估 |
| 风险控制措施可追溯性 | 维护风险控制矩阵：危险 → 控制措施 → 架构分配 → 验证 |
| 变更控制完整性 | 至少一个近期变更的完整流程记录（申请→分析→批准→实施→验证→文档更新） |
| 生命周期裁剪合理性 | 解释为何针对当前项目选择了特定的开发活动组合 |
合规落地的实操建议
从 Ed 2 团队向 Ed 3 过渡，最关键的挑战不是技术，而是过程文档化的习惯转变：
| 旧习惯 | Ed 3 要求 |
|---|---|
| 口头传达需求、代码即文档 | 正式需求规格文档（14.7） |
| 凭经验直觉设计架构 | 文档化架构 + 风险控制分配（14.8） |
| 仅做功能测试 | 系统性验证 + 独立性要求 + 安全验证（14.10/14.11） |
| 代码修改即生效 | 正式变更控制流程（14.12） |
| SOUP 拿来就用 | SOUP 评估 + 异常状态分析 |
| 风险管理以硬件为中心 | 软硬件风险同等对待（14.6） |
核心思想：如果软件可能影响安全，就必须用系统化的工程纪律管理其开发与维护。
- 先判定适用性，再决定投入规模
- 借助 IEC 62304 的成熟框架，不要从零开始
- 独立性确认是关键 —— 审核员必查
- SOUP 不是免费的 —— 风险分析需要专项投入
- 文档是"合规资产" —— 不是形式而是过程留痕
IEC 60601-1 全貌梳理以及系列笔记阅读指南 ← 返回总览