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

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

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

　　因此，很多公司改变方法，改善软件过程，采用欧盟和美国近期签署的医疗产品设计标准IEC62304。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）的关键所在。

　　需求跟踪与SOUP

　　需求跟踪矩阵是一种用于管理和跟踪需求的习惯做法，在管理软件需求和系统所用SOUP项目方面起着重要作用。RTM能够通过医疗器械应用的架构设计在与SOUP有关的高级需求之间实现可追踪性（图2）。

　　图2 需求跟踪矩阵（RTM）在开发生命周期模型中起着重要作用，即使是在SOUP项目是系统的一部分的时候。各个阶段的典型产物都直接与需求矩阵相连，各个阶段的变更都会自动更新RTM。

　　为了确保SOUP能够满足IEC 62304规定的系统级要求，医疗器械制造商需要规定：

　　? 预期用途所需的SOUP项目的功能和性能要求

　　? 让SOUP项目正常运行所需的系统硬件和软件的生产规范

　　? 证明医疗器械架构能够让任意SOUP项目正常运行所需的详情

　　大多数情况下，SOUP项目是作为源代码提供的，但是不带设计文件，这样就很难分析它们。使用现代测试工具有助于实现早期代码设计可视化。

　　不论它是否应用于语句模块、进程（或类）、应用和/或系统，现代测试工具提供的系统可视化设施功能都非常强大。应用和系统实体的分层示意图如图3a内的静态调用图所示；图3b内的静态流程图展示了整个程序模块的控制流程。利用彩色编码图对于了解SOUP极有好处。这类调用图和流程图只是综合分析代码内使用的所有参数和数据对象的一部分优势。

　　图3 静态调用图（a）和流程图（b）以图形的形式分别说明了代码的结构和逻辑。

　　需求管理和跟踪已经证明了它们在软件开发生命周期内的优势，能够确保实现所有需求和所有开发成果都可以追溯到一个或多个需求。同样的，需求管理与跟踪可以保证根据系统要求添加和验证SOUP项目。

　　RTM在架构设计和SOUP项目之间实现了可追踪性。由于这些项目都包含在源代码内并且现在需要按照IEC 62304的要求进行系统级合规性测试，所以代码验证就成了制造商的责任。

　　大多数SOUP项目都不严谨，从而为系统集成商提高了严格验证与风险分析要求。由于SOUP验证非常耗时，所以开发人员一开始通常需要满足一系列编码标准，再逐渐采用其他规则。虽然测试工具只辨别而不纠正代码内存在的违规之处和本征误差，但是它们确实通过指出问题所在而加快了代码纠正速度。

　　IEC 62304希望医疗器械制造商评估SOUP项目供应商提供的软件异常列表，以便确定已知异常是否会引发事件，进而导致出现危险情形。

　　测试工具的静态分析能力能够确定异常及其对软件系统的影响。如果确定了SOUP供应商提供的列表以外的任何其他异常，则应告知相应供应商以解决问题。

　　静态分析和异常纠正完成后，进行动态分析（包括系统、集成度和单元测试）以便验证SOUP项目的功能和结构覆盖率。虽然全系统功能测试提供了SOUP项目的功能简介，但是它不测试所有代码路径。测试工具确定使用过的软件部分，并且重点突出需要注意的区域，要对这些区域进行单元测试以便保证各个单元都能够独立运行。

　　进行功能测试与结构覆盖率分析能够确保使用了所有代码路径和验证了多个单元之间的接口。它还有助于确保系统能够按照设计要求运行，即使集成了SOUP项目。值得注意的是，IEC 62304要求SOUP项目验证遵循软件规划期间制定的集成计划，再一次表明IEC 62304强调的重点在于确保医疗软件升级不会引入误码。

　　根据先前制定的测试计划，RTM在对SOUP项目进行的各种分析之间实现了可追踪性。该测试计划包括有待执行的测试用例以及基于系统要求的预期结果。利用RTM，项目经理可以评估整合的SOUP项目的影响以及它们如何影响系统安全。

　　SOUP项目维护

　　医疗器械行业的很多意外都与医疗器械系统的服务或维护有关，包括软件更新和升级不当。在这里，SOUP项目还起着重要作用，因为这些项目由不同的供应商提供并且需要验证。

　　在IEC 62304中，软件维护过程和软件开发过程一样重要。强调维护旨在抑制产品发布以后（如软件维护期间）引入的高医疗器械软件缺陷率。

　　维护过程要求，制造商监控组织内部和用户提供的已发布产品相关的反馈信息。必须记录和分析该反馈信息，以便确定是否存在问题。发现问题时，应编写和分析问题报告，以便确定SOUP项目是否增加了问题的严重性。如果SOUP就是问题所在，则必须将该问题传达给相应的供应商，以便通过升级或补丁来解决问题。

　　IEC 62304要求制造商制定规程，以便评估和实现SOUP项目升级、漏洞修复、补丁和报废。必须分析和验证每个升级、漏洞修复和补丁，以便确定这些升级是否引入了其它潜在的、可能导致出现危险情形的因素。一如往常，必须确定是否需要采取其它软件风险控制措施。

　　维护期间，要求制造商分析SOUP项目变更，以便确定软件修订是否会干扰现有的风险控制措施。制造商必须制定独特的配置项目和版本识别机制。对于使用的各种SOUP配置项目，制造商需要记录标题、SOUP制造商名称和独特的SOUP标志符。该标识符可以确定医疗器械软件内包含的软件配置项目及其版本。

　　通过采用IEC 62304的高级软件过程，公司能够更好地开发安全的产品，避免代价高昂的召回，确保相同的开发过程能够巩固维护和升级过程。