为开发人员认证医疗器件简化IEC 62304兼容步骤

现在，利用高级医疗器械比以往任何时候都更有助于医疗从业人员轻松、准确地做出诊断。然而，他们对器械的依赖程度也引发了确保器械安全性和质量的担忧。

值得注意地是，医疗器械严重依赖第三方和早期软件，亦即“未知系谱的软件（SOUP）”。该SOUP构成了新发展的基础，其现在可能符合新医疗器械要求或者政府推行的现代编码标准、客户需求或者仅仅是开发组织内的持续改进政策。在满足新标准和进一步开发新功能的同时，对利用SOUP价值的需要提出了它自己的独特挑战。

FDA于1992至1998年间对3140次医疗器件召回事件进行的分析显示，其中有242次（占7.7%）可归因于软件故障。在所有软件召回事件中，192次（占79%）是因软件升级后引入的软件缺陷而起。产品升级过程中引入的高误差率让政府医疗器械机构不仅要集中精力开发新产品，还要关注后期维护和软件变更对现有系统的影响。

因此，很多公司改变方法，改善软件过程，采用欧盟和美国近期签署的医疗产品设计标准IEC 62304。IEC 62304引进了一种基于风险的合规性结构，可以确保医学应用符合其风险评估适用标准的要求。该合规性结构可以分成A~C类，其中C类软件故障可能导致死亡或重伤。

IEC 62304软件开发生命周期

IEC 62304着眼于软件开发过程，定义了大部分软件开发与验证活动。该过程包括软件开发规划、需求分析、架构设计、软件设计、单元实现与验证、软件集成与集成测试、系统测试和软件发布之类的活动。

该标准不仅概括了开发生命周期的各个阶段的要求，还顾及了维护过程、软件变更对现有系统的影响和实现软件变更所涉及的风险。IEC 62304还直接从规划、需求分析、架构设计、维护和风险管理阶段开始详细介绍了SOUP项目的作用。

EIC 62304和SOUP

可重新用于新器件开发的SOUP软件已流行起来，因为医疗器械现在倾向于采用通用嵌入式硬件，以及操作系统，面向USB、以太网或制图的器件驱动器、文件系统、网络堆栈等。在医疗器械中使用SOUP有其优势，因为制造商可以将精力集中在应用软件上。

然而，由于应用需要运行专用功能，所以医疗器械内的SOUP增加了挑战难度。大多数SOUP模块都由第三方供应商提供，而他们不遵守任何软件过程和软件标准，甚至不记录代码。虽然它解决了平台挑战，但SOUP是在紧迫的时间表内开发而来，并且强调的是生产率，而不是标准兼容性。在进行系统测试以便检验功能性时，SOUP项目通常表现出代码覆盖率极差的特点，并且留下了很多未使用的代码路径。图1中的蓝色曲线代表进行了功能测试的代码。采用该代码时，不同的数据和情形有可能第一次使用很多未经测试的路径，从而产生意料之外的结果。图1中的红点曲线表示现场运行应用时使用的代码。

图1 传统功能测试可能无法检验代码的很多部分。蓝色曲线表示传统功能测试使用的代码；红点曲线表示应用现场运行时使用的代码；绿点曲线表示代码增强，其倾向于使用先前未遇到的数据组合，从而出现进入先前未使用路径的可能性。

欧洲软件和系统提案之“利用经验驱动测试（PET）检验误码性能”计划调查了这种现象，并且同意采用的代码通常带有很多误码的观点。PET旨在将发布后报告的漏洞数量减少50%和将每找出一个漏洞所耗费的测试工作时间缩短40%。有意思的是，PET超过了该标准，将报告的漏洞数减少了75%，将测试效率提高了46%。PET的发现表明可以利用较新的测试方法（如静态和动态分析）找出大量漏洞，即使代码已经通过了功能系统测试并于随后发布。

那么，可以采用先前通过功能测试的SOUP做进一步测试。即使它运行良好，代码的某些部分也可能未曾使用过，即使是产品正在现场使用的时候。如果SOUP代码需要作进一步开发以便于后来的修订或新应用，那么先前从未碰到的数据组合也可能会使用先前未使用的代码路径，从而产生意料之外的结果。图1中的绿点曲线表示对SOUP代码进行增强时使用的代码。

为了克服这种潜在弱点，需要进行详细的结构覆盖率分析，以确保早期软件内不存在未使用的代码。IEC 62304要求测试早期软件的功能覆盖率和结构覆盖率，还要详细分析增加这类软件可能引入的风险。功能覆盖率确保软件能够按照系统设计要求运行，而结构覆盖率则确保使用了所有代码并且能够正常运行。

IEC 62304要求整合到医疗器械设计中的所有SOUP项目均符合功能和性能要求规范。医疗器械制造商需要确保任意SOUP项目的正常运行，还要保证它们符合功能和性能要求。

IEC 62304软件开发过程始于软件开发规划，包括所用SOUP项目的详细计划。这些细节介绍了如何将SOUP项目整合到现有系统中、如何管理SOUP相关风险和软件配置、以及变更管理如何影响系统。

紧接着是软件需求管理、架构设计、集成测试、系统测试、风险管理、维护和变更管理阶段。在软件开发生命周期的各个阶段，都需要保持所有阶段之间的可追踪性。

传统的软件开发观点表明了各个阶段如何进入下一个阶段，可能还带有前几个阶段的反馈信息，以及配置管理与过程的周边架构。可追踪性被视为各个阶段间关系的一部分。然而，很少规定记录跟踪链路的机制。

实际上，虽然由于先进工具技术投资，各个阶段都能够有效实施，但是这些工具很少能够自动提高阶段间可追踪性。因此，在整个项目进行的过程中，其间链路的维护就变得越来越差。最终的结果就是需求与设计之间的交叉检验缺失或者流于表面，以及最终系统的机能不全。为了获得真正的自动可追踪性，则需要需求跟踪矩阵（RTM）。RTM是各个项目的核心，是很多开发标准（包括IEC 62304）的关键所在。