Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/TR 27809 — 健康信息学：确保健康软件患者安全的措施
健康软件全生命周期的患者安全风险管理技术框架
ISO/TR 27809 概述与适用范围
ISO/TR 27809为识别、评估和缓解与健康软件产品相关的患者安全风险提供了一个结构化框架。随着医疗系统日益数字化，软件导致的患者伤害风险也在相应增加。本技术报告填补了一个关键空白：IEC 62304管理医疗设备软件，ISO 14971涵盖通用风险管理，而ISO/TR 27809专门针对可能不被归类为医疗设备但仍对患者安全产生影响的健康软件。
该报告涵盖整个软件生命周期，从最初的概念和需求规范到设计、实现、验证、确认、部署和退役。它强调患者安全必须主动地设计到健康软件中，而非事后测试。实施ISO/TR 27809的组织可以系统地减少由软件故障、可用性问题或互操作性故障引起的不良事件的可能性和严重性。
将ISO/TR 27809与IEC 62304和ISO 14971结合实施，可创建一个涵盖医疗设备软件和通用健康IT应用的综合性患者安全管理体系。
核心风险管理框架
ISO/TR 27809规定的风险管理方法遵循结构化的迭代过程。它从危害识别开始，系统地对患者伤害的潜在来源进行编目。这包括直接伤害（如剂量计算错误）和间接伤害（如系统不可用导致的治疗延迟）。风险分析随后为每个已识别的危害分配严重性和概率评级，从而对缓解工作进行优先级排序。
| 风险管理阶段 | 关键活动 | 交付物 |
|---|---|---|
| 危害识别 | 系统审查用例、故障模式和环境因素 | 包含上下文描述的危害目录 |
| 风险分析 | 严重性分类、概率估计、风险评分 | 风险评估矩阵 |
| 风险控制 | 设计缓解措施、防护措施、安全信息 | 风险控制记录、验证证据 |
| 残余风险评估 | 评估残余风险是否符合可接受性标准 | 残余风险接受文件 |
| 风险管理评审 | 评审风险管理过程的完整性和有效性 | 风险管理报告 |
| 生产与售后 | 监控现场表现、处理新兴风险 | 售后监督记录 |
ISO/TR 27809中的一个关键概念是可合理预见的误用与异常使用之间的区别。制造商应通过设计选择（如强制功能、确认对话框、输入验证）来预见和缓解可预见的误用，同时不限制合法的临床工作流程。该标准还解决了超说明书使用的问题，即健康软件在其原始预期目的之外的场景中使用。
在风险分析过程中必须处理可预见的误用。常见示例包括在以公斤为单位的字段中输入磅值，或在高压临床情况下绕过安全检查。设计软件时应预见这些场景。
软件生命周期安全措施
ISO/TR 27809在软件生命周期的每个阶段都规定了具体的安全措施。在需求工程阶段，安全需求必须明确记录、具有可追溯性并优先排序。关键安全需求应分配给具有明确职责分配的软件架构元素。报告强调安全需求必须是可验证的、无歧义的，并在整个开发过程中一致表达。
在软件设计和实现阶段，该标准推荐采用防御性编程技术、所有系统边界的输入验证、默认故障安全原则以及人因工程原理。用户界面设计必须考虑临床工作流程背景、认知负荷限制以及环境因素，如照明条件、噪音水平和多任务处理需求。设计评审应包括专门针对健康软件领域定制的安全检查表。
验证和确认活动受到特别重视。ISO/TR 27809建议对安全关键功能进行独立验证，对安全相关代码进行结构覆盖率分析，并解决互操作性危险的集成测试。验证应包括在代表性临床医生参与的、现实条件下的可用性测试，包括模拟紧急情况和时间压力场景。
系统性地应用ISO/TR 27809的组织通常能在部署后实现安全事件的显著减少。一项大规模研究报告称，采用结构化患者安全工程实践后，安全相关软件异常减少了40%。
临床部署与售后监督
从开发到临床部署的过渡代表了一个特别高风险阶段。ISO/TR 27809提供了部署规划指导，包括数据迁移验证、基础设施确认、临床医生培训和切换策略。报告强调部署安全是健康软件制造商和医疗保健提供组织之间的共同责任。清晰沟通已知风险、限制条件和所需缓解措施至关重要。
ISO/TR 27809规定的售后监督超越传统的投诉处理。它包括通过自动日志记录主动监控安全性能、定期安全评审、分析未遂事件以及将反馈系统性地集成到风险管理过程中。该标准建议建立具有多学科成员的安全评审委员会，包括临床、技术和质量保证方面的专业知识。
| 部署阶段 | 安全活动 | 参与方 |
|---|---|---|
| 部署前 | 现场确认、数据迁移测试、基础设施验证 | 制造商、IT部门、临床负责人 |
| 上线 | 受控推广、并行运行、重点支持 | 实施团队、超级用户、帮助台 |
| 稳定期 | 密集监控、快速问题解决、配置调优 | 支持团队、临床带头人 |
| 常规运行 | 性能监控、定期安全审计、用户反馈收集 | 运维团队、安全官 |
| 退役 | 数据归档、系统退役、替换过渡 | IT、法务、临床治理 |
未能充分规划部署过渡是健康IT相关患者伤害的主要原因。确保部署安全计划包含明确的回滚标准、安全事件沟通协议以及上线初期全天候技术支持。
常见问题解答
问1：ISO/TR 27809与IEC 62304有何不同？
IEC 62304专门针对医疗设备软件，包含详细的软件生命周期过程要求。ISO/TR 27809范围更广，涵盖所有健康软件（包括非设备的健康IT应用），并专门关注患者安全措施而非完整的软件生命周期过程。
IEC 62304专门针对医疗设备软件，包含详细的软件生命周期过程要求。ISO/TR 27809范围更广，涵盖所有健康软件（包括非设备的健康IT应用），并专门关注患者安全措施而非完整的软件生命周期过程。
问2：ISO/TR 27809能否获得认证？
ISO/TR 27809是一份技术报告而非规范性标准，因此不提供认证。但它提供了最佳实践指导，可在监管提交或内部审计中引用。组织可以声明其质量管理体系符合其建议。
ISO/TR 27809是一份技术报告而非规范性标准，因此不提供认证。但它提供了最佳实践指导，可在监管提交或内部审计中引用。组织可以声明其质量管理体系符合其建议。
问3：健康软件中最常见的患者安全危害有哪些？
常见危害包括数据输入或显示错误、未能向临床医生警示关键结果、互操作性导致的数据损坏、患者信息未经授权访问、临床护理期间系统不可用以及临床决策支持系统中的算法错误。
常见危害包括数据输入或显示错误、未能向临床医生警示关键结果、互操作性导致的数据损坏、患者信息未经授权访问、临床护理期间系统不可用以及临床决策支持系统中的算法错误。
问4：风险管理过程应该多久重新审视一次？
ISO/TR 27809建议风险管理在软件生命周期中持续进行。主要修订应在每次软件发布时、通过售后监督识别新危害时、安全事件发生后以及软件在不同临床环境下部署时进行。
ISO/TR 27809建议风险管理在软件生命周期中持续进行。主要修订应在每次软件发布时、通过售后监督识别新危害时、安全事件发生后以及软件在不同临床环境下部署时进行。
