上一篇我们讲了一次性无源器械的可用性文档体系，这一篇来聊聊，带嵌入式软件的有源器械，这套文档到底该怎么写，才能既对得上 62366‑1，又经得起 MDR 技术文档审查。

这类产品因为带上了触摸屏、菜单、报警逻辑、用户权限、软件版本更新，问题就会立刻复杂很多。因为你要处理的已经不只是“按钮好不好按”，而是用户会不会在多页面界面里选错患者、误改参数、误解报警优先级，或者在软件升级后继续按旧习惯操作。

这篇文章就以含嵌入式软件的有源器械为例，比如带触摸屏的床旁监护设备、输注泵或治疗设备，来讲清楚 IEC 62366‑1 要求下的可用性工程文档体系：

• UEF 到底要收什么。
• UI 规范、IFU、软件需求和风险管理文件怎么串起来。
• 可用性验证为什么不能只做一个“界面测试”。
• MDR 技术文档里，这一块通常会被怎么看。

一、先把场景说清楚：为什么这类产品的文档特别容易“散”

先用一个比较常见的场景来代入：一台带触摸屏的床旁监护设备，能显示多个生理参数、触发不同优先级的报警、允许用户静音、确认报警、修改阈值，还会随着软件版本更新调整部分页面结构和交互逻辑。

这类设备的预期用户一般是护士和医生，使用环境则是病房、ICU、恢复室这类高干扰场景。现实中的问题不是“用户不会点按钮”，而是他们可能在疲劳、夜班、多人交接、同时面对多设备报警的情况下操作，于是任何一个菜单层级、颜色编码、提示文案或确认逻辑，都可能变成真正的 use-related risk。

也正因为这样，这类产品的可用性文档特别容易散。软件团队有一套 UI 稿和需求文档，硬件团队有一套设计输入，风险管理有自己的 hazard analysis，验证团队又单独出测试方案和报告，最后每份文件都“看起来有关”，但真正到了 UEF 或 MDR 技术文档里，却未必能讲清楚：到底是哪一个界面风险，被哪一个设计控制了，又由哪一次评价证明它降下来了。

二、UEF 在这类产品里，核心不是“多一份文件”，而是把版本和证据链收拢

IEC 62366‑1 里的 UEF，本质上不是一本固定格式的报告，而是一组在可用性工程过程中形成的记录和文件集合。它通常至少会包括使用相关特征、使用相关风险分析、关键任务或 hazard-related use scenarios、形成性评价、可用性验证，以及能把风险控制和验证证据连起来的可追溯关系。

到了含嵌入式软件的有源器械这里，UEF 最容易缺的，不是“有没有内容”，而是有没有把软件版本和界面版本真正纳进来。因为这类产品的用户界面会变，报警逻辑会变，页面结构也会变，如果 UEF 不明确写清楚“当前可用性证据对应的是哪个 UI 或软件版本”，那很多验证结论在审查时都会变得站不住脚。

所以对这类设备来说，一份实用的 UEF 至少要多回答三件事：

• 当前可用性工程活动对应哪个软件版本、哪个 UI 版本。
• 哪些 use-related risk 主要来自软件界面，而不是纯硬件或纯说明书。
• 当 UI 或报警逻辑发生显著变更时，哪些形成性、可用性验证或风险分析需要重新触发。

换句话说，UEF 在这里更像一个“总装台账”。它不一定把所有东西全文复制进来，但至少要让审查者顺着一条线看明白：从 intended user、use environment，到 hazard-related use scenario，再到 UI 规范、软件逻辑、验证测试和残余风险结论，中间没有断链。

三、真正的难点，不是“界面美不美”，而是 use-related risk 怎么写

很多团队一提可用性，脑子里先出现的是界面配色、图标风格、菜单是否直观。可在 IEC 62366‑1 和监管审查语境里，最关键的从来不是这些视觉层面的“顺不顺眼”，而是哪些用户操作错误可能导向伤害，哪些任务因此变成关键任务，哪些场景必须被验证。

以一台带嵌入式软件的床旁监护设备为例，常见的 use-related risk 往往包括下面几类：

• 用户在错误患者或错误页面上修改参数。
• 误静音高优先级报警，或者误以为“静音”就等于“问题已解决”。
• 误解报警信息，不知道是生理参数异常还是导联脱落。
• 软件升级后，原有操作路径改变，用户继续按旧习惯完成任务。
• 在多设备环境里，用户把本设备的报警和旁边设备的报警混淆。

这时候，UEF 里的 use-related risk 分析就不能只写一句“存在误操作风险”。更有效的写法，通常是把它拆成一条条具体的 hazard-related use scenario：谁，在什么环境里，面对什么界面信息，可能做错什么，错了以后会有什么后果，当前的风险控制措施是什么。

例如，不要只写“用户可能误改参数”，而要写得更贴近实际：

夜班护士在两台监护设备并排摆放的病房内，因患者标识区域不够突出，在错误患者页面修改报警阈值，导致真正目标患者的异常报警未被及时识别。

这样的表述更容易和后面的 UI 设计、患者标识强化、确认逻辑以及验证任务一一对应。

四、UI 规范在这里，不是设计稿，而是风险控制文件的一部分

到了含嵌入式软件的器械上，UI 规范的重要性会明显提高。因为 IEC 62366‑1 期待制造商把与安全相关的用户界面特征识别出来，而这些特征不能只存在于视觉稿或者开发口头讨论里，最好能被写成可测试、可追踪、可变更控制的要求。

所以这里说的 User Interface Specification，不是“设计师给研发看的几张图”，而应该是一份偏工程化的文档。它至少要把这些内容说清楚：

• 哪些信息必须在主界面持续可见，例如患者标识、报警优先级、关键参数。
• 哪些操作必须有二次确认，例如参数修改、报警静音、模式切换。
• 报警颜色、声音、图标和文字分别如何对应优先级。
• 页面跳转、状态变化、锁屏或超时返回、权限限制等逻辑如何定义。
• 物理按钮与触屏操作如何分工，哪些关键动作不能只依赖触控完成。

对监管来说，这份 UI 规范的价值不在于“看起来专业”，而在于它能和风险管理、软件需求、验证活动形成对照。也就是说，你在风险分析里说“为降低误静音风险，系统对高优先级报警增加了确认逻辑”，那 UI 规范里就应该能找到这条要求，软件需求规格说明里也应该能看到对应实现，而最终的形成性或可用性验证里还能看到这条逻辑被真正测试过。

这也是为什么很多项目的问题不在于“没做设计”，而在于设计决策没有被写成受控要求。只要 UI 的关键风险控制没有进入规范文件，它就很难稳定地被开发、测试、变更评估和技术文档引用。

五、IFU 在软件型产品里，早就不只是一本说明书了

对含嵌入式软件的有源器械来说，IFU 的边界通常比传统产品更宽。除了纸质说明书本身，还可能包括设备内置帮助页面、快速上手引导、培训材料、在线帮助文档，甚至某些受控的视频演示内容。这些内容并不是“宣传材料”，而是可用性工程体系的一部分。

这类产品里，很多 use-related risk 并不能只靠界面本身彻底消掉。比如某个报警确认流程必须结合培训理解，某个软件更新后的新功能必须通过变更说明让用户避免沿用旧路径，某些限制条件需要在 IFU 和设备界面同时提示，才能达到足够清晰的风险控制效果。

所以在文档上，更稳妥的做法通常不是把 IFU 当作“最后再补上的附件”，而是把它作为 UEF 的一个组成部分来写清楚：

• 哪些风险控制依赖 IFU、内置帮助或培训材料。
• 哪些关键信息在界面和 IFU 中必须一致。
• 当软件版本变化时，这些用户信息是否需要同步修订。
• 在验证中，是否观察了用户能否通过这些信息正确完成任务或理解限制条件。

六、可用性验证不能只测“能不能点出来”，而要测复杂场景下会不会做错

对这类产品来说，可用性验证最容易被低估。很多团队会觉得，界面已经做过一轮轮评审和内部测试，用户也基本会用，那最后再做个“走流程”的测试就行了。可 IEC 62366‑1 更关注的是最终用户在代表性条件下，能否安全有效地完成与风险有关的关键任务，而不是能不能在安静会议室里把页面点通。

因此，这类产品的可用性验证更适合围绕 hazard-related use scenarios 和关键任务来设计。典型任务可能包括：

• 在多患者列表中选择正确患者并修改报警阈值。
• 在多个同时存在的报警中，识别最高优先级报警并采取正确响应。
• 在被中断后重新返回正确界面，完成未结束的关键任务。
• 在软件升级后的新界面中，完成旧版本常见任务。
• 在夜间或低照度模拟环境下识别关键状态信息。

而一份有说服力的验证报告，也不能只停留在“通过率 95%”。更关键的是写清楚：

• 出现了哪些 use error 或 near miss。
• 这些问题的根因更偏向界面设计、信息呈现、培训不足还是环境干扰。
• 最终是否需要设计修改、说明书修改或新增控制措施。
• 在这些修改之后，残余风险为什么仍被认为可接受。

对有源软件型产品来说，还有一个常被忽略的点：软件更新。只要更新改变了关键任务路径、报警逻辑、视觉层级或术语，就可能引入新的 use-related risk，而不是“只是 UI 优化”。这类变化是否需要追加形成性或重新评估可用性验证覆盖，最好在 UEF 里提前定义原则。

七、和 ISO 14971、IEC 62304 的关系，不能只停留在“互相引用”

这类产品的文档体系之所以难，就是因为它天然跨标准。IEC 62366‑1 讲可用性工程，ISO 14971 讲风险管理，IEC 62304 讲医疗软件生命周期。真正成熟的项目，不是把三套文件各写各的，而是让它们之间能互相“对得上”。

在实务上，一个比较清晰的链条通常是这样的：

• 在使用相关特征中定义用户、环境和关键使用场景。
• 在风险管理中识别与使用相关的 hazardous situations。
• 在 UEF 里把这些风险转化成更具体的 hazard-related use scenarios 和关键任务。
• 在 UI 规范和软件需求规格说明里定义风险控制如何实现。
• 在形成性与可用性验证中验证这些控制是否有效。
• 最后把结论回写到风险管理文件和技术文档里，说明残余风险为何可接受。

如果这条链没有打通，就很容易出现典型问题：

• 风险管理文件里写了报警混淆风险，但 UI 规范里没有对应控制要求。
• 软件需求里有确认弹窗，但 UEF 里没有说明它控制的是哪一类 use error。
• 可用性验证里做了用户测试，但场景并不是前面识别出的高风险任务。
• 技术文档里写“按 IEC 62366‑1 执行”，但没有任何清晰可追溯关系。

所以真正的重点从来不是“每个标准单独合不合规”，而是这三者之间有没有形成一条闭环证据链。

八、MDR 技术文档里，这一章通常是怎么被看的？

从 MDR 技术文档审查角度看，含嵌入式软件的有源器械在可用性这一块，通常不会只被问“有没有做 human factors”。更常见的关注点是：

• 预期用户、预期使用环境是否被清晰界定。
• 与安全相关的界面特征和 use-related risk 是否被系统识别。
• UEF 是否足够完整、可追溯，而不是零散报告拼接。
• 软件版本和 UI 变更是否被纳入可用性维护。
• 可用性验证是否覆盖关键任务、高风险场景和代表性用户。
• 残余 use-related risk 是否被合理解释，并与风险管理结论一致。

换句话说，审查者真正想看到的，不是你做过多少“用户体验工作坊”，而是你能不能证明：这台设备在真实用户、真实环境、真实任务里，针对那些会影响安全的使用错误，已经做了系统分析、设计控制、验证和文件化管理。

因此在 MDR 技术文档里，可用性章节更适合写成下面这样的结构：

• 可用性工程流程概述。
• UEF 目录与交叉引用。
• 关键 use-related risks 与风险控制策略摘要。
• UI 规范、IFU、软件需求、风险管理之间的关系说明。
• 形成性与可用性验证结论摘要。
• 软件或 UI 变更管理和 post-market 反馈如何回流到 UEF。

老规矩，三句话总结如下

• 第一句：
   对含嵌入式软件的有源器械来说，可用性风险很多时候不是“不会用”，而是“在复杂界面和高干扰场景下，用错了”。
• 第二句：
   UEF 的价值不是多建一个文件夹，而是把 UI、软件逻辑、风险控制和验证证据真正收拢到一条可追溯链上。
• 第三句：
   真正能过审的可用性文档，不是把 IEC 62366‑1 讲得多漂亮，而是把每一个关键界面风险讲清楚：它从哪里来、怎么被控制、又是如何被证明已经降到可接受水平。

关键词#IEC62366-1 #可用性工程#UEF#嵌入式软件#有源医疗器械#MDR技术文档#HumanFactors#IEC62304#ISO14971

【械逅法规】· 2026-06-02

如果觉得有用，欢迎点赞、在看、转发 。