正视IEC 62304标准下医疗器械软件的安全规则

软件的安全漏洞会带来诸多隐患，医疗器械软件领域的安全规则一直都不是很严格，造成的后果就会更严重。同时，软件一直都未被欧盟的医疗设备指令正式列为医疗产品。而今，这种现象已有所改变，欧盟已建立了一种新体制管理各类器械中的所有医疗器械软件的开发。

此前的软件安全标准十分适用于低风险的医疗器械，而对于那些由于软件故障可能引起极为严重的后果, 甚至导致死亡的产品则不然。随着越来越多的电子产品开始依赖嵌入式软件，人们关注的焦点也开始转移到器械的软件系统的可靠性及各种用途下的风险方面。 EN/IEC 62304新标准便由此应运而生，它是软件开发周期管理的全球性基准（图1）。

图1：IEC 62304如何融入合规性过程及其与其它标准的关系。

硬件和软件设计的风险分析

医疗产品设计者采用风险管理技术帮助降低器械硬件的相关风险。BS/EN/ISO 14971一般被用作医疗器械风险管理的基本标准。2007版的此标准比此前版本范围更广泛,其中介绍的技术现可应用于软件和硬件系统。

应采取的方法是先全面考虑医疗器械的风险，后分开衡量软件/硬件。然后同时进行硬件风险和软件风险分析，确定器械所需的安全系统。

协调标准

IEC 62304是欧盟和美国均采纳的医疗产品软件设计协调标准。由于该标准是“协调的”，医疗器械制造商采纳它将符合医疗器械指令93/42/EEC (MDD)及修正案M5 (2007/47/EC)所涵盖的有关软件开发的基本要求。这是确保符合MDD要求的最简单途径。美国FDA也将承认ANSI/AAMI/IEC 62304:2006，作为医疗器械软件设计符合可接受标准的证据。该标准的所有基本细节均与EN/ISO版本一致。

根据IEC 62304进行设计能确保采用既定和受控的软件开发过程生产出高质量软件。该过程必须包括根据开发软件的安全分类制定的一整套要求。

软件安全分类

最初，IEC 62304标准希望制造商为整个软件系统指定一个安全类别。这种分类是基于其可造成危险导致用户、患者或其它人受伤的潜在可能。

可将软件分为以下三个大类：
?? ?* A类：不会对健康造成伤害或损伤
??? * B类：不会造成严重伤害
??? * C类：可能导致死亡或严重伤害

定义“严重伤害”、“非严重伤害”、“伤害”和“健康损伤”是进行有效分类的关键。哪些会造成伤害咋一看可能很明显；但当考虑到器械的应用背景时，这个问题就会变得复杂得多。不幸的是, 该标准仅定义了“严重伤害”，具体如下：

- 严重伤害

伤害或疾病可直接或间接造成以下后果：

a) 危及生命，

b) 造成人体功能的永久性损伤或身体结构的永久性伤害，

c) 需要医疗或手术干预来防止人体功能的永久性损伤或身体结构的永久性伤害。

注：永久性损伤是指身体结构或功能的不可逆损伤或伤害（不包括微小损伤或伤害）。

?

图2：关键安全软件系统可以分为不同的项目，每个项目在不同的处理器上运行，且安全分类各不相同。

使用上述定义的反面论述衍生出非严重伤害的定义是相对比较简单的。但A类软件安全分类的伤害定义还值得商榷。由于缺乏对健康伤害或损伤的定义，因此较为复杂。例如，在疾病治疗而非器械本身引起的伤害的正常副反应方面可能存在着灰色地带。

如今已经制定了执行初始分析和定义适用类别的程序。在某些情况下，相关认证机构会对此决策产生影响。一些机构推荐B类作为所有医疗产品的最低适用标准，A类安全分类并不适用于非常严格的软件开发过程。A类和B类代码的开发成本和时间差异较大。因此，医疗器械开发商在开发初期确定分类是非常必要的。安全分类还会对需要的文件和过程产生极大的影响。

软件项目和单元

一旦完成系统的初始安全分类后，则需将系统分为软件项目和软件单元。它们的定义如下：
??? * 软件项目：“计算机程序所有可标识的部分” [ISO/IEC 90003:2004，定义3.14，修订版]
??? * 软件单元：“不可以再细分为其它项目的软件项目” [ISO/IEC 90003:2004，定义3. 28，修订版]

事实上，软件项目可以是系统或其组成部件的分部。需要利用系统结构图说明软件项目和软件单元。如果软件系统的部件可以分隔开，则可降低其安全分类级别。标准的第5.3.5节的注释举例说明了分隔：

“分隔的例子是在不同的处理器上执行软件项目。可以断开处理器间的共享资源，确保分隔的功效。”

事实上，这意味着关键安全软件系统可以分成不同的项目，每个项目在不同的处理器上运行，且安全分类各不相同（图2）。同样，在初期保证分隔正确是确保系统的安全和高质量，且在适当的成本和时间期限内完成的关键。这些过程可以大幅减少医疗器械开发的时间和成本。

表1 安全分类对代码开发文件和过程的影响概况。

?

安全分类的影响

安全分类对代码开发过程的影响巨大。因此在第一时间进行正确分类，以免在项目后期进行昂贵且耗时的返工符合医疗器械制造商的利益。

安全分类对文件和过程的效应的简短总结如表1所示。事实上，所有开发医疗器械软件的公司将对所有软件分类进行验证、集成和系统测试。但差别在于A类代码无需生成正式的详细文件。也无需对要求参照和验证进行正式证明。这大大节约了软件开发的时间和成本。

SOUP

未知来源软件或SOUP是无正式文件或由第三方开发且无开发过程控制证据的代码（工具或资源代码）。这种代码会出现错误。对所有用于软件开发的SOUP代码进行软件风险分析并解释为何使用这些代码是至关重要的。

SOUP的使用受代码安全分类影响。如果代码属于A类，则SOUP代码无需进一步说明即可使用。随着级别上升，风险也随之增加，则需更详细的说明理由。事实上，这意味着只有功能简单、大家熟悉而且应用广泛的SOUP代码可作为C类应用。

专门从事电子产品设计和生产服务的技术解决方案供应商开发出了识别并证明医疗器械软件中的SOUP应用的过程。其服务经验证明该过程可以大幅减少开发时间和成本。医疗器械开发商需将该过程整合到他们的设计过程中。

结论

IEC 62304是开发医疗器械中关键安全和高可靠性软件的良好逻辑标准。该标准已开始生效，医疗器械软件开发商便很难证明符合MDD要求但不遵循该标准的同等途径。这有助于改善患者的安全，也有益于制造商自身，因为该标准建立了一个更为规范的市场环境。这样可以消除不受控制的初级软件开发过程，从而广泛提升了质量。

此外，由于IEC 62304是国际通用的协调标准，它统一了欧洲和美国的质量要求。对于医疗器械制造商而言，选择拥有完善的风险管理系统的软件设计师是十分重要的，因为他们已经建立了符合IEC 62304的基础。（来源：CMDM）
?