32、医疗级软件开发与合规评估

医疗级软件开发与合规评估

1. 云计算在医疗软件中的应用与挑战

在医疗软件领域，使用云计算来处理和存储关键数据时，网络安全和信息安全的需求变得更加迫切。架构设计是应对这些安全需求的关键信息，同时也是反复审视风险管理活动的重要背景。

如果要在云端构建关键的医疗设备服务，即便采用常见的技术，其任务也远比组装一件平板家具复杂。云计算引入了新的交互类型，可能会带来新的恶意和意外危害源。中间人可能并非客户，但在规划中需要考虑这类不受欢迎的用户。

采用云计算进行医疗软件开发时，有两种常见的失败方式：一是认为在独立环境中有效的方法在云端也足够；二是因复杂度增加而望而却步，没有深入了解云计算对应用程序的意义。应避免陷入这两种陷阱，以免错失云计算带来的机遇。

2. 边缘智能在医疗领域的应用

边缘智能（Edge AI）是一种人工智能，其智能并非位于独立设备或云端，而是处于网络边缘。它与云计算、边缘计算和人工智能有许多相同的概念，但在医疗设备领域具有特殊吸引力。在医疗设备中，数据集可能非常庞大，数据和专有算法需要保护，同时还涉及到与之相关的人类生命安全。

边缘智能的工作源于跨学科的医疗人工智能研究，也与医疗设备领域日益复杂的软件监管相关。欧盟医疗器械法规（EU MDR）、欧盟人工智能法案以及美国食品药品监督管理局（FDA）的预认证计划等都与之相关。

边缘智能可以为克服传统云解决方案和独立软件解决方案面临的问题提供新的实用方案。它提供了一个低延迟、高功率且具有高可扩展性的计算环境，类似于洁净室的软件环境，能够让大量数据、专有分析算法和医生在一个不仅能最小化数据传输需求，而且由于其按需瞬态性质而具有内在网络安全性的环境中协同工作。

作为人工智能的一种形式，边缘智能打破了从独立设备到云端的传统设备分类，在设计医疗软件时值得考虑。

3. 合规评估的重要性

软件开发完成并明确适用要求后，软件的最终考验可能是官方的 IEC 62304 合规评估。其目的是确保开发过程及其成果符合预期，目标是保障使用软件的医疗设备不会对他人造成伤害。

过去几十年，软件在医疗设备中的作用不断增加。不仅越来越多的医疗设备中包含软件，而且软件所实现的功能及其在医疗诊断和治疗指导中的作用也在不断扩大。随着先进机器学习和人工智能等技术的应用，这一趋势将持续下去。

软件在安全性和合规性方面受到越来越多的审查。这些审查是根据设备的预期用途进行的，特别是当引入新功能到复杂多样的医疗环境中时。这种高度关注也导致医疗设备法规和标准中增加了新的软件特定要求。

将通用医疗设备要求转化为软件的具体要求，并在软件开发背景下理解这些要求，是一项挑战。软件的复杂性、分布式特性以及软件通过接口和网络连接对其他设备的影响，通常需要深入分析来评估。

4. 评估人员的要求

评估软件的安全性、性能和法规合规性通常比评估简单的物理医疗设备复杂得多。评估人员需要具备以下能力：
- 理解适用于软件的法规要求，如欧盟 MDR、协调标准、技术水平概念、IEC 60601 - 1 第 14 条、IEC 62304 和 IEC 82304 - 1。
- 理解风险管理流程和文档，这是实现设备必要安全和性能水平的基石。
- 了解软件开发生命周期模型，如经典瀑布模型、敏捷模型，以及这些模型各阶段产生的可交付成果。
- 了解软件技术，包括编程语言、软件架构和网络安全模型。

对于评估未联网的医疗设备软件，评估人员需要具备以下能力：
- 识别适用的法规和标准，并了解这些内容。
- 识别适当的评估标准，并能将其应用于实际案例。
- 了解软件开发生命周期和各阶段的可交付成果。
- 具备软件开发知识和阅读代码的能力。
- 有软件架构和需求方面的经验。
- 能够理解文档要求和在风险控制或缓解背景下的可追溯性。
- 有使用软件工具的经验。
- 掌握基本安全、基本性能和风险控制措施等基本概念，并能将其应用于软件评估。
- 掌握 ISO 14971 风险管理原则和要求，并在评估中具有实际应用经验。

如果要评估联网设备，评估人员还需要具备以下能力：
- 具备网络安全和信息安全原则、解决方案和技术方面的专业知识。
- 具备在复杂的人机交互网络中的可用性工程和风险管理专业知识。
- 具备网络拓扑及其对安全和性能影响的专业知识。
- 了解云技术，包括其典型实现差异和每种情况下的风险场景。
- 掌握多种同时使用的编程语言和编程工具。

从评估单个独立设备到评估由不同组件组成的联网设备，复杂度显著增加。随着预期行为变得更加复杂，设备中使用的软件组件数量通常也会增加，对评估人员风险管理能力的要求也相应提高。

5. 评估方式

IEC 62304 评估有多种形式，但目标始终是评估制造商的软件开发过程和文档在多大程度上符合标准要求。实践中，有两种有效的评估模型：

5.1 审计式评估

评估人员逐一审查所有要求，评估文档如何满足标准要求，同时考虑适用的法规期望。任何观察结果都使用审计表或 IEC 62304 测试报告模板记录。

5.2 预填测试报告评估

要求制造商预先填写测试报告表格，回答相同问题，并将此信息和相关文档提供给评估人员。评估人员审查答案和证据，提供最终的合规评估。这种方式通常更具成本效益，因为制造商提前确定了正确的文档，大部分评估工作可以在现场外完成。

评估模型的选择由制造商和评估人员决定。通常进行初步评估是一个实用的步骤。在初步评估中，制造商和评估人员可以校准彼此的期望，制造商明确所需的文档，评估人员了解制造商的整体设置以及流程和文档的状态。当制造商的文档齐全时，正式评估开始。有时初步评估可能会发现文档严重不足，从而避免不必要的评估，节省时间和金钱。

以下是 IEC 60601 - 1 和 IEC 62304 评估中测试报告的示例：
| 标准条款 | 要求说明 | 制造商证据 | 通过/失败 |
| — | — | — | — |
| 14.6 | 风险管理流程 | - | - |
| 14.6.1 | 制造商在将 PEMS 集成到 IT 网络时考虑了与软件和硬件相关的危害 | 见下文。风险管理文件（RMF）包括可预见的危害、IT 网络特征、第三方组件和遗留子系统。RMF 引用了特定危害，所需项目出现在风险分析中，从产品特定风险分析文件中查看实际示例。 | P |
| 5.4 | 软件详细设计 | - | - |
| 5.4.1 | [B, C] 制造商将软件细分到由软件单元表示的程度 | 详细设计将架构设计细化到软件单元级别，详细设计记录在文档 DOC - 341144 中。 | P |
| 5.4.2 | [C] 制造商以足够的细节记录设计，以便正确实现软件单元 | 详细设计达到预期的详细程度，详细设计记录在文档 DOC - 341144 中。 | P |

评估完成的标志是制造商对所有要求都提供了满意的答复。如果评估目的只是评估运营状态和确定改进点，部分答案可能缺失或未达到标准期望。在 CE 标志认证的背景下，某些要求的失败可能是可以接受的，但在认证机构的 CB 计划下，所有要求都必须通过，否则软件的认证将失败。

评估的范围和所需文档的程度取决于软件的安全分类（ABC 分类，从低风险 A 到高风险 C）。分类基于所涉及的风险，必须通过文档证明分类的合理性，并体现适当的临床专业知识。如果设备分类未来发生变化，可能需要进行新的评估和提供新的证据。评估通过后，评估人员将提供最终测试报告，该报告可作为软件和软件开发过程符合 IEC 62304 标准的健康证明，对制造商的认证和质量管理体系评估有重要意义。

6. 评估中常见的不足

在 IEC 62304 合规评估中，常见的不足有以下几种：

6.1 需求定义不充分

需求获取困难且对软件开发项目的结果至关重要。许多软件项目失败可归因于需求获取不完整或不正确。在 IEC 62304 评估中，需求问题经常出现，常见原因包括误解、过于简单的方法以及对满足标准要求的忽视。典型挑战包括：
- 确定每个需求适用的软件版本。
- 确定每个需求适用的软件平台。
- 确定基本性能、可用性和风险管理方面的需求。
- 未涵盖不同软件系统之间的接口和通信，影响测试用例的有效性和符合多项 IEC 62304 要求。
- 接受不完整、冲突或不现实的系统需求，导致软件需求推导出现问题。
- 接受不完整、冲突或不现实的软件需求。
- 规划文档不足，可能缺少软件开发生命周期的描述。
- 设计文档之间的可追溯性中断。
- 未充分描述软件的操作及其运行环境，影响对推导需求和后续可交付成果的依赖。

6.2 风险分析不足或过于狭窄

风险识别对一些制造商来说可能和需求识别一样困难，两者通常相互关联。有时会使用过于简单或复杂的风险分类方案，将风险概率与实际测量数据关联也可能存在问题。关键是识别的风险矩阵要足够全面，风险优先级排序合理，并且所有风险控制和跟进措施都得到妥善处理。典型挑战包括：
- 软件开发过程中的风险管理不存在或不足，如没有风险管理计划，风险识别由开发者单独进行，缺乏风险管理专业知识，没有临床专家或领域专家参与。
- 信息安全风险处理不足，特别是在联网或基于云的设备环境中。

6.3 验证和确认活动不足，缺乏证据

部分制造商在验证和确认活动方面存在困难，主要问题是并非所有设计师都理解基本安全和基本性能的概念，特别是在确定软件的适当验证标准时。
- 基本安全（IEC 60601 - 1 第 3.10 条）指设备的结构特性，旨在防止设备在正常条件和所谓的单一故障条件下变得危险。在软件方面，涉及软件在监控隔离接口、处理电源管理和应对过热问题等方面的作用。
- 基本性能（IEC 60601 - 1 第 3.27 条）指临床功能的性能水平，低于该水平可能会出现不可接受的风险。制造商可以指定该水平的限制。在实践中，临床功能通常与设备的预期用途直接相关。IEC 60601 系列标准的附属和特定标准对基本性能有直接要求，涉及需求分析、设计、测试用例定义、验证、确认和风险管理等方面。对于软件，基本性能通常指所采用的算法从生物信号中检测、识别和分割某些医疗特征的能力。

IEC 62304 未提及这两个概念，但它们对适当的需求定义和风险分析是相关的实用工具。典型挑战包括：
- 验证计划和报告不足。
- 确认计划和报告不足。
- 缺少确认报告（虽然 IEC 62304 未要求，但 IEC 60601 - 1、IEC 82304 - 1 和 ISO 13485 等法规和标准期望有此报告）。

综上所述，医疗级软件开发在云计算和边缘智能的应用中面临着安全和技术挑战，而 IEC 62304 合规评估则是确保软件质量和安全性的重要环节。制造商和评估人员需要共同努力，克服评估中常见的不足，以保障医疗软件的有效和安全使用。

7. 解决评估常见不足的建议

7.1 完善需求定义

• 明确需求适用范围 ：建立详细的需求管理文档，清晰记录每个需求所适用的软件版本和平台。可以使用表格形式进行整理，例如：
  | 需求编号 | 需求描述 | 适用软件版本 | 适用软件平台 |
  | — | — | — | — |
  | R001 | 实现患者信息录入功能 | V1.0 | Windows 10 |
  | R002 | 支持远程数据传输 | V1.1 | iOS 14 |

• 全面考虑性能与风险 ：在需求分析阶段，引入多领域专家，包括临床专家、风险管理专家等，共同确定基本性能、可用性和风险管理方面的需求。制定详细的需求规格说明书，明确各项需求的具体指标和验收标准。

• 加强接口与通信管理 ：对不同软件系统之间的接口和通信进行详细设计和文档记录。可以使用 mermaid 流程图来展示软件系统之间的交互关系，例如：

graph LR
    A[软件系统 A] -->|接口 1| B[软件系统 B]
    B -->|接口 2| C[软件系统 C]
    C -->|接口 3| A

• 确保需求合理性 ：对系统需求和软件需求进行严格审查，避免接受不完整、冲突或不现实的需求。建立需求评审机制，邀请相关人员参与评审，及时发现和解决问题。
• 完善规划文档 ：编写详细的规划文档，包括软件开发生命周期的描述、项目进度计划、资源分配等。确保文档能够为项目的实施提供明确的指导。
• 建立可追溯性 ：使用需求管理工具，建立设计文档之间的可追溯性。确保每个需求都能在设计、开发、测试等阶段得到有效跟踪和验证。
• 详细描述运行环境 ：在需求文档中，详细描述软件的操作及其运行环境，包括硬件配置、操作系统、网络环境等。为后续的开发和测试提供准确的依据。

7.2 优化风险分析

• 建立风险管理体系 ：制定完善的风险管理计划，明确风险管理的流程、方法和责任。引入专业的风险管理工具，对软件开发过程中的风险进行全面识别、评估和控制。
• 合理分类风险 ：避免使用过于简单或复杂的风险分类方案，根据实际情况制定科学合理的风险分类标准。结合历史数据和行业经验，将风险概率与实际测量数据进行有效关联。
• 引入专家参与 ：在风险识别和评估过程中，邀请临床专家、领域专家和风险管理专家参与。确保风险分析的全面性和准确性，及时发现潜在的风险。
• 加强信息安全管理 ：针对联网或基于云的设备，加强信息安全风险管理。采取加密、访问控制、防火墙等技术手段，保障数据的安全性和完整性。

7.3 强化验证和确认活动

• 理解关键概念 ：加强对基本安全和基本性能概念的培训，确保所有设计师和开发人员都能准确理解这些概念，并将其应用到软件开发过程中。
• 制定完善计划 ：制定详细的验证和确认计划，明确验证和确认的方法、标准和流程。确保计划能够覆盖软件的各个方面，包括功能、性能、安全性等。
• 提供充分证据 ：在验证和确认过程中，及时记录相关的证据，包括测试报告、验证记录、确认文档等。确保这些证据能够证明软件满足相关的标准和要求。

8. 总结

医疗级软件开发是一个复杂且严谨的过程，涉及到云计算、边缘智能等先进技术的应用，同时也面临着网络安全、信息安全等诸多挑战。IEC 62304 合规评估作为确保软件质量和安全性的重要手段，对制造商和评估人员都提出了很高的要求。

在评估过程中，常见的不足如需求定义不充分、风险分析不足和验证确认活动缺乏证据等问题，需要引起足够的重视。制造商应采取有效的措施，完善需求定义、优化风险分析、强化验证和确认活动，以提高软件的质量和安全性。评估人员则需要具备丰富的专业知识和经验，严格按照标准和要求进行评估，确保评估结果的准确性和可靠性。

只有制造商和评估人员共同努力，克服评估中常见的不足，才能保障医疗软件的有效和安全使用，为医疗行业的发展提供有力支持。

挑战类型	具体问题	解决建议
需求定义不充分	需求适用范围不明确、性能与风险考虑不全等	明确适用范围、引入多领域专家、加强接口管理等
风险分析不足	分类不合理、缺乏专家参与等	建立管理体系、合理分类风险、引入专家等
验证和确认活动不足	概念理解不清、计划不完善等	加强培训、制定完善计划、提供充分证据