数字医疗设备的信息安全测试

【作 者】刘炯

上海市医疗器械检测所，上海市，201318

0 引言

我们已经身处大数据时代，数据即将成为最大的交易商品。未来数据将会是一种基础设施，是一种国家战略资源。大数据时代的一个最重要的特点就是物联网的快速发展。作为物联网的一种医学应用，覆盖全国的医学信息网正在逐步形成。原先那些我们熟知的医疗设备就像众多的信息孤岛，各自承担着自己的任务和完成着自己的预期用途，但是通过物联网，这些医疗孤岛相互联系起来。这些信息化了的医疗设备相互进行信息交换和通讯，实现了一种具有智能化诊断治疗、自动定位跟踪、远程监控和移动管理等功能的一种十分复杂的医疗信息网络。

近日，国家食品药品监督管理局发文：《关于开展先进医疗设备标准体系研究工作的通知》（国械标管函【2012】10号），这是为了顺利推进国家标准化管理委员会和国家食品药品监督管理总局关于《先进医疗设备标准体系研究项目》的实施。其中特别针对医疗信息产品的安全有效性提出了前瞻性的研究要求。

1 典型的医疗信息产品

目前我们根据医疗信息产品的信息化的程度，可以把典型的医疗信息产品分为三类：

(1)单纯的软件产品 其中可以是单独的客户端产品，例如放射医学图像后处理工作站；也可以是网络服务信息系统，例如PACS系统。PACS系统是一种典型的医用网络软件。PACS主要的任务就是把日常产生的各种医学影像（包括核磁，CT，超声，各种X 光机等设备产生的图像）通过各种接口（模拟，DICOM，网络）以数字化的方式保存起来，当需要的时候在一定的授权下能够很快的调回使用，同时增加一些辅助诊断管理功能。

(2)带有网络功能的独立的物理软硬件产品 如磁共振成像系统，超声诊断系统，心电监护系统等。这些设备本身就可以独立获取患者的医疗信息，是独立的物理硬件，同时又具有网络信息传输的能力。当不使用网络功能时，基本不影响这些系统的预期用途和临床性能。

(3)信息网络和物理硬件结合的综合系统 这种综合系统是最复杂，信息化程度最高的系统，具有医疗物联网的明显特点。例如：医疗报警监护系统，临床信息系统（CIS）、放射学信息系统(RIS)、医院信息系统(HIS)、实验室信息系统（LIS）等。这些系统的突出特点是无论离开物理硬件还是离开信息网络，他们的预期用途都不能完成。

图1 远程医疗系统结构实例Fig.1 Example of architecture of telemedicine system

2 常见的问题

标准不足是阻碍目前我国信息化医疗设备发展的重要因素[2]。现在的医疗器械的标准体系基本上考虑的是硬件的安全有效性，而对于信息化的新特征，网络化的新功能却没有很好地加以规范。现行的标准主要为：GB25000.51-2010。这份标准主要考虑了商用现货软件的广告说明，说明书和软件功能有效性[1]。这份标准的要求相对笼统，在实际执行中容易产生歧义，把握的自由度过大。在我们开展信息设备检验的4年中，我们发现业内仍然存在如下一些主要问题：

(1)各种医用软件已经比比皆是，而执行的标准是借用软件行业的标准，术语定义不统一[2]，部分条款完全不适合医疗领域。我们建议修改相关的标准体系，制定有针对性的新标准来加以规范。

(2)人机交互界面的易用性问题突出，功能显示不准确、界面不规范，使用有歧义，易引发与现有标准相抵触的问题。当使用web作为交互界面时，往往由于网络拥塞或者网络吞吐量的问题导致负载不稳，使得实际的产品易用性大幅降低。

(3)企业标准对自身产品的可靠性和准确性的要求过于笼统，应通过测试解决许多通过网络所提供的信息数据的可信度和比对问题，保证数据的接收端和发出端的信息一致，不应该造成信息被修改，丢失等网络问题，确保医疗信息设备给出的信息和功能是可信的，可测量或可认证的。

(4)安全性考虑不足，没有标准来要求产品抵抗非预期的数据修改，对于病人数据的隐私保密性基本没有考虑，病人信息已经大量外泄，还发现一些软件遭到非预期的修改（如硬件故障导致）后引发了安全性的问题，各家软件企业基本没有要求用户准备防病毒防木马的解决方案。

(5)兼容性问题严重，企业对于信息数据通过有线网络，无线通讯网路等方式进行传输时，链路完整性、传输兼容性考虑不周。数据格式不统一造成大量的资源浪费。规范兼容性迫在眉睫。

3 测试技术

针对上述问题，我们建议了一些测试方法。需要指出的是国内软件测试行业刚刚起步，2001年的信息产业部5号令才开始规定软件必须测试和登记。而对于作为医疗器械看待的医疗信息产品的第三方测试，开始的时间仅仅起步于2008年。而对于信息网络的测试就更加少了。

按照测试深入的程度，一般分为白盒测试、黑盒测试和介于两者之间的灰盒测试。

白盒测试也称结构测试，一般被企业内部进行的单元测试或者模块测试所采用，测试人员依据程序内部逻辑结构的相关信息，对程序所有逻辑路径进行测试，检查程序的所有模块的状态是否与预期的状态一致。

黑盒测试着眼于程序外部结构，主要针对软件界面和软件功能进行测试。它检查程序功能是否能够按照需求规范文档和功能规范文档的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试主要用于发现如下几类错误：(1)功能遗漏或错误；(2)界面错误；(3)数据访问错误；(4)性能偏离或错误；(5)其他非预期的偏离或错误。

注册检测作为一种第三方检验一般不会深入到程序内部的每一条逻辑路径。近年来，第三方检验已经开始涉及到部分更加细节的地方，一些审评和风险要求使得第三方机构也要针对一些原先系统黑盒测试不能完成的地方进行分析，现在的测试更多的是一些介于白盒测试和黑盒测试之间的灰盒测试过程，即带有部分逻辑路径验证的功能测试。

3.1 人机和网络交互测试

现在的众多的医用软件中基于Web的应用组件很多，一些HIS，CIS系统的客户端就是基于Web的，甚至一些PACS系统的客户端也有直接使用浏览器的Web客户端，在这些客户端中可以实现整个信息系统中大部分的图像处理功能和一些信息录入功能，部分简单的信息管理功能也能实现。Web应用的简单实用和通用性强的特点为部署这些应用提供了便利。

我们现在进行的是客户端和服务器端的检验。客户端测试，包括功能验证测试，用户界面的交互性检验。界面交互性测试，包含界面上的语言是否有利于医疗活动，界面上的信息是否和随机文件一致，医疗术语是否符合学术规范，颜色和声响是否和现在已有的标准冲突等。

服务器端测试则主要考虑网络测试。 网络测试主要是利用一些网络性能测试仪表，解码分析仪表和一致性测试软件／仪表产品对通讯网络进行检验以便考察样品的吞吐量，丢包率、延迟等指标。同时也应注意到网络测试现在的测试重点将逐渐转向可靠性测试和安全性测试，网络协议的一致性测试。

协议分析仪是定位和排除故障的关键工具，对于网络协议的一致性测试，一般有专门的测试工具来支持，比如说对ISDN、ATM、ADSL、帧中继等的测试都有专门的测试仪，但是对于DICOM3.0的协议并没有专业测试仪，对于那些已经开发出的实验性的测试工具在稳定性和可靠性上还不成熟[3]。

我们在进行网络测试时主要进行如下过程：

(1)网络可靠性测试

使被测试网络在较长时间内（通常是24～72 h）经受较大负载，通过监视网络中发生的错误和出现的故障，验证在高强度环境中网络系统的存活能力。

(2)网络瓶颈测试

测试中将要测试的计算系统按照每天吞吐量施加压力，然后再在单个网络组件上进行该项测试，明确各自的最大吞吐量。通过单个组件的最大吞吐量和系统最大可支持吞吐量之间的差额，我们就能发现系统瓶颈的位置以及哪些组件有多余容量。

(3)网络吞吐量测试

吞吐量测试检测的是每秒钟传输数据的字节数和数据报数，用于检测服务器、磁盘子系统、适配卡等。

(4)网络响应时间测试

检测医疗信息系统完成一系列任务所需的时间，本项测试是用户最关心的。在不同负载，即不同实际或模拟用户的数目下，运行某一预先设定的测试用例，对每个被测试的应用事件生成一个负载响应时间曲线。

3.2 负载和压力测试

根据GB25000.51要求的效率描述，我们认为产品并不是简单的实现了功能，还有实现功能的效率问题。

服务器为了响应多个客户端的请求，有可能出现响应错误、响应缓慢、数据丢失等错误。用户连接到Web应用系统的速度根据上网方式的变化而变化，如果Web系统响应时间太长，用户就会因没有耐心等待而离开。导致医疗信息的损失。

应用负载压力测试正是用来检验效率的。那些宣称能在一定的多用户多任务下并行处理请求的医疗信息处理系统，例如远程医疗系统或者是PACS系统，我们即可以通过逐步增加系统负载，测试系统性能的变化，最终确定在什么负载条件下系统性能不能达到其宣称的那样，并以此来获得系统能提供的最大服务级别。也可以直接达到系统宣称的服务级别，观察在这个压力下系统的性能是否变得不可接受。我们会针对系统的特点灵活选择如下测试计划：① 单用户下多任务的压力测试；② 多用户下的单任务并发压力测试；③ 多用户下的多任务并发压力测试；④ 长时间多任务的循环强度测试；⑤ 大数据量访问测试。

目前可以利用一些商业化的测试工具结合适当的负载压力测试计划进行测试，例如：Loadrunner，ApacheJMeter，Testmaker等。我们以系统资源监控的指标（网络，数据库，服务器）和程序的响应时间为主要的指针来判断实验的成功与否，包括CPU占用率，内存使用率，磁盘I/O，网络吞吐量等。

负载压力测试可以帮助企业确定样品的如下一些特点：① 确定用户的实际可能的响应时间；② 考察硬件或者软件要求的配置表是否正确；③ 检查系统功能性能一致性；④ 验证系统容量与随机文件的一致性。

3.3 准确性和可靠性测试

国家标准GB25000.51要求，所有软件产品供应商在说明书中给出的功能都必须可用。我们认为功能的可用和可靠性是不能分开的。可靠性指的是医用信息产品在规定的条件下和规定的时间内完成规定功能的能力，或者说信息产品应该在使用说明书允许的任何负载下保持所有功能的可用，给出的结果也是可靠的。我们认为医疗信息系统的可靠性测试主要针对如下情况：

(1)应用环境的复杂性

医用软件内部逻辑高度复杂，驱动的硬件可能简单到只有一台电脑也可能复杂到如磁共振整机等大型设备，虽然硬件的安全防护有大量成熟的国家标准，但是软件的标准不成熟，而且软件失效发生的概率很高[4]。所以遍历所有功能是必要的。我们的手段是编制功能列表和编制UI访问入口或菜单项的列表，并且要求将这些列表写入企业标准等审批资料，按照功能列表和菜单项列表进行测试用例的设计和遍历。

(2) 物理退化

软件不存在物理退化现象，硬件失效则主要由于物理退化所致。这就决定了软件正确性与软件可靠性密切相关，一个正确的软件任何时刻均可靠，然而，一个正确的硬件元器件或系统，则可能在某个时刻失效。硬件失效是软件能否做出适当的应有的反应对于医疗系统的安全至关重要。这里可以参考IEC60601-1-4的要求进行考虑[5]。

(3)医疗信息系统的可移植性要求

软件产品本身是惟一的，软件拷贝不改变软件本身，而任何两个硬件环境和软件环境不可能绝对相同。医疗信息系统的迁移有时没有仔细考虑。所以我们不接受任何移植覆盖的建议，所有移植环境都将被合理的遍历。

(4)版本更新较快

硬件通常更新周期较慢，硬件产品一旦定型一般就不会更改，而软件产品通常受需求的变更，软件缺陷的修复而造成软件版本更新较快，这也给软件可靠性评估带来较大难度。所以每一次检验都将记录产品的版本号，对于何种程度的更新需要申报注册，何种程度的更新（如bugfix）则不需要申报注册的问题则需要管理部门的决定。

(5)最好的可靠性是设计出来的

按照产品可靠性的形成，可靠性可分为固有可靠性和使用可靠性。固有可靠性是通过设计、制造赋予产品的可靠性；虽然有多重模型可以选择用来评估产品的可靠性，但是最终仍然依靠设计和管理，我们重点检查的是产品是否含有的冗余设计，检错设计，降低复杂度设计，这些设计是否有贯穿于整个研发流程的可靠性管理。

3.4 安全性测试

安全性测试主要考察医疗信息系统的用户认证机制，系统加密机制和安全防护策略，数据备份和恢复手段。医用信息系统中的信息不仅含有一般的身份信息，还有很多医疗人体生理信息，对于用户来说极端重要，所以我们认为所有医疗信息系统的制造商都应该陈述系统所需要的安全环境，包括自带或者要求提供的防病毒系统，防木马系统等。

对系统进行全面保障的安全体系，主要体现在以下5个层次：① 物理层面 基础设施的物理安全；② 软环境层面 网络平台、计算机操作系统、基本通用应用平台（服务，数据库等）的安全 ③ 数据访问层面 系统数据的机密性、完整性、访问控制和可恢复性 ④ 通信链路层面 系统之间数据通信和会话访问不被非法侵犯 ⑤文档提示 在用户手册上对系统安全性的动态维护和保障提供说明，人员应该监控由于时间推移和系统运行导致安全性的变化。

针对一个产品而言，应该重点关注如下测试方向：

(1)防火墙和入侵检测

① 是否提供或者是否在随机文档中指出防火墙的要求；② 足否支持对HTTP、FTP、SMTP等服务类型的访问控制；③ 是否支持对日志的统计分析功能，同时，日志是否可以存储在本地和网络数据库上；④ 对防火墙本身或受保护网段的非法攻击系统，是否提供多种告警方式以及多种级别的告警；⑤能否在检测到入侵事件时自动执行切断服务、记录入侵过程、邮件报警等动作；⑥ 能否提供多种方式对监视引擎和检测特征的定期更新服务。

(2)病毒防治

① 是否提示和要求配置一定的防病毒服务；②自身能否支持对病毒和木马的防治；③ 是否支持补丁升级服务；④ 必要时进行模拟攻击实验，例如DDOS攻击等。

(3)证书服务水平

① 证书认证系统是否采用国家密码主管部门审批的签名算法完成签名操作；② 是否提供证书的签发、管理和撤销；③ 证书/证书撤销列表的发布以及证书的审核注册。

(4)密钥管理能力和密码服务系统

① 是否制定了密钥管理策略；② 是否具备密钥生成、密钥发送、密钥存储、密钥 查询、密钥撤消、密钥恢复等基本功能；③ 密钥库管理功能是否完善，例如是否包含审计、 认证、恢复、统计功能；④ 随机文档中是否要求了系统、设备、数据、人员等管理的严密性说明；⑤ 能否提供对多密码算法的支持；⑥ 密钥长度能否达到主流水平，是否在说明书中向用户表明信息。如有必要进行系统速度测试，对应用层的服务器端进行密码破解测试。

我们认为最基本的安全防护系统来自于冗余设计，供应商应该指出产品的故障恢复能力；医用信息设备应该具备数据备份能力；如果能提供容灾备份能力，那就特别值得提倡。

3.5 信息系统的兼容性测试

兼容性的考察主要有如下3个层次：

(1)硬件环境兼容性

包括主机兼容性，驱动硬件兼容性，附件兼容性等，这主要是依据GB25000.51的要求考察最低配置是否能够满足系统运行的需要。在最低配置下，所有的软件功能必须能够完整地实现，软件运行速度、响应时间应在产品说明文档规定的效率的范围内。考察软件对运行硬件环境有无特殊说明。对于服务器，是否允许多种服务部署在一台主机上。

(2)软件环境兼容性

包括操作系统平台兼容性，数据库兼容性，与其他软件的兼容性等。Windows系统，Linux系统，Unix系统等都应该单独测试，同一种系统的不同版本之间也应该单独测试，因为一般任何操作系统公司都不作支持兼容性的承诺，Linux系统即使内核相同，只要发行版的不同也一样不兼容。SQL数据库，Oracle 8i，Oracle 9i，DB2等相互兼容性也不能全部保证的。对于含有数据库的系统应该检查原数据库中各种对象是否能全部移入新数据库，同时比较数据表中数据内容数是否相同。模拟普通用户操作应用的过程，对应用进行操作并检查运行结果，从以往的测试经验来看，如果开发中使用了数据库存储过程，那么在数据库移植时最容易出现问题。

我们在上两项测试通过后，可以针对服务器数据库进行性能测试，并与在原数据库下的性能基准数据进行比照，观察在数据移植后，性能是否有所改变。

(3)网络环境兼容性

主要考察数据接口兼容性、通讯线路兼容性等。应该确保数据在网络传输中数据丢失的补偿措施。丢包率的测试是一种有效的手段。不同企业的数据格式不兼容，应该统一一些医疗软件的常用格式，增强医用信息设备的扩展性，避免一些格式不统一所导致的资源浪费，也可以解决现在大量存在的兼容性问题。

4 总结

上述内容简单介绍了信息化设备的测试技术和方法，这些测试在电子通讯领域是广泛采用的，但是在医疗设备领域，由于标准的缺失，这些测试基本没有得到应用。使得现在市场上的医疗信息产品发展水平层次不齐，鱼龙混杂。很多产品的宣传与实际效果相差甚远。兼容性和安全性问题也导致医院和病患在使用这些设备时遇到了困难和障碍。这些都需要尽快使用标准加以规范。相信以这些测试技术为技术支撑，信息化的医疗设备的标准很快就会出现，这将扫清我国数字医疗信息化发展的最大障碍之一，加快我国医疗信息设备的发展和进步。

[1]中华人民共和国国家质量监督检验检疫总局,中国国家标准化管理委员会.GB/T 25000.51-2010 软件工程 软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求和测试细则[S].

[2]中国医院协会信息管理专业委员会.中国医院信息化状况调查报告(2011-2012年度)[R].

[3]罗静.DICOM测试方法的研究与实现[D].浙江大学,2006.

[4]国家食品药品监督管理局.YY/T 0664-2008 医疗器械软件 软件生存周期过程[S].

[5]IEC 60601-1-4: 2000 Medical electrical equipment-Part 1-4: General requirements for safety – Collateral Standard:Programmable electrical medical systems[S].