IEC 62304在医械软件开发中的实施

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

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

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

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

IEC 62304软件开发生命周期

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

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

EIC 62304和SOUP

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

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

图1

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