伴随着医疗信息化的深入,医疗仪器的信息集成已经成为医疗信息化的一个非常重要的组成部分。为了使没有统一标准信息接口的医疗仪器具备与信息系统互联互通、信息共享的能力,本研究设计并实现了基于医疗健康信息集成规范-患者护理设备(IHE PCD)技术框架的医疗仪器信息集成网关,该集成网关按照IHE PCD定义的通信框架和健康信息交换第七层协议(HL7)消息格式,通过协议转换引擎和设备驱动Javascript脚本语言,将各种格式的医疗仪器通信协议转换为符合HL7标准的消息。本研究为医疗仪器提供了统一的HL7标准接口,使其能够与信息系统进行无缝连接以及无障碍数据交换,降低了医疗仪器信息集成的门槛,具有良好的应用价值,对在用医疗仪器设备的信息集成尤具价值。
引用本文： 郑建立, 廖芸, 杨勇勇. 基于医疗健康信息集成规范的医疗仪器信息集成技术的研究. 生物医学工程学杂志, 2014, 31(3): 671-677. doi: 10.7507/1001-5515.20140125 复制
引言
伴随着医疗信息化的深入，信息共享需求的增大，医疗仪器的信息集成已经成为医疗信息化的一个非常重要的组成部分，为广大医院以及医疗器械厂商所关注。医疗仪器的研发除了关注创新或完善仪器本身的诊断或治疗功能之外，如何与医疗信息系统互联互通也成为一个共性问题。
医学影像类的医疗仪器设备如CT、MR、US等的数据接口已经广泛采用了医学数字影像传输标准(digital imaging and communications in medicine，DICOM)，所以这类医疗仪器的集成技术相对较为成熟。而其他非影像类医疗仪器设备如监护仪、麻醉机、呼吸机等产品却没有采用统一的标准接口，这类医疗仪器的信息集成存在接口复杂、可扩展性差等问题。目前的状况是厂商自行定义通信接口，不同厂商之间的设备或信息系统间没有通用的互联方案，只能采取Case-by-Case的办法解决。
医疗健康信息集成协会(Integrating the Healthcare Enterprise，IHE)是医疗信息技术领域的重要国际组织。为解决医疗设备的信息集成问题，于2005年开始发布基于健康信息交换第七层协议(Health Level Seven,HL7)和ISO/IEEE 11 073的患者护理设备(Patient Care Device，PCD)技术框架。PCD技术框架规范了通信场景以及医疗设备与医疗设备数据接收单元之间的流程,从而促进医疗环境中设备数据的交换效率，加强患者信息安全，提高医疗保健质量[1-2]。该技术框架得到越来越多厂商的关注，开始在产品设计中应用IHE PCD的集成框架解决医疗仪器的信息集成问题[3]。参与美国医疗健康信息与管理系统协会(Healthcare Information and Management Systems Society，HIMSS)举办的IHE PCD展示的企业从2007年的6家发展到23家，包括GE、德尔格、飞利浦等。 Capsule公司研发的一套符合PCD技术框架的医疗设备信息集成解决方案，可以支持超过600种不同医疗设备的集成，并于2012年IHE 测试会上成功地进行了测试。由Intel发起的240多个业界厂商参与的Continua健康联盟在个人远程健康系统的研究中，将IHE PCD作为个人健康设备通信的解决方案，利用设备数据通信(Device Enterprise Communication，DEC)集成模式实现广域网络接口的患者数据的传送[4]。国内在医疗仪器集成技术方面的研究相对滞后，多为单一设备的HL7接口实现方案[5-7]，对PCD的研究和应用甚少。
1 医疗仪器信息接口分析与集成框架
医疗仪器设备的信息集成存在困难的原因是其信息接口存在较大的差异，主要表现在硬件接口(串口、以太网口、CAN、WLAN、蓝牙、WAN等)、帧格式(波特率、起始符、帧长度、终止符等)、校验方式(奇偶、checksum、CRC等)、域定界方式(定长、分界符等)、编码方式(文本、二进制、BCD等)、信息输出方式(主动式、被动式)和指令集等的不同，如Drager的Fabius GS呼吸机，硬件接口为串口COM，采用的是其medibus通信协议，信息输出方式为被动方式，即请求/响应模式，设备收到系统的请求命令后才会输出信息。而另一些医疗设备的信息输出为主动方式，如NCC X5插件式多参数监护仪采用网口输出，通信协议为自定义等。
本研究提出一种通用医疗仪器集成网关软硬件平台，如图 1所示。该平台兼容多种厂商的设备接口和通信协议，按照IHE PCD定义的通信框架和HL7消息格式，将医疗仪器通信协议转换为统一的IHE PCD事务协议，使得医疗设备能与信息系统进行无缝连接以及无障碍数据交换。该平台包括可配置多接口硬件平台(满足不同硬件接口)、协议转换引擎(实现医疗仪器通信协议转换)、设备驱动(满足不同设备工作模式)以及HL7接口通信模块(实现与信息系统之间的HL7通信)。
图1
医疗仪器集成网关软硬件平台框架
Figure1.
Framework of medical instrument integrating gateway
2 IHE PCD技术框架
IHE PCD技术框架对不同的集成需求定义了多个集成模式。其中DEC 集成模式用于规范医疗仪器设备与信息系统间的设备数据的传输，如血压数据、心率数据等；波形内容模块(waveform content module，WCM)集成模式规范了波形数据的传输，如心电波形数据、SPO2波形数据等；术语映射(rosetta terminology mapping，RTM)集成模式则是对DEC、WCM等集成模式中所涉及的术语进行了规定，以避免二义性。医疗仪器可按照各自的功能要求，选择实现若干集成模式中定义的角色，即可满足集成要求。
2.1 设备数据通信(DEC)集成模式
DEC集成模式基于ISO/IEEE 11073和HL7标准，采用一致的消息格式和设备语义内容将医疗仪器设备信息传输到临床信息系统，现在涉及的仪器设备主要有输液泵、监护仪、呼吸机和麻醉机等。DEC将信息系统与医疗仪器设备分别抽象成设备数据使用者(device observation consumer，DOC)和设备数据报告者(device observation reporter，DOR)两个角色，图 2为DEC的角色事务图[8]。
图2
DEC角色事务图
Figure2.
Actors and transcation of DEC
DOR与DOC之间通过PCD-01事务进行交互，具体是DOR通过HL7 ORU_R01消息将采集的设备数据传送给DOC，DOC正确接收后返回一个HL7 ACK消息给DOR。 ORU_R01消息中包含消息头(message header，MSH)、患者标识(patient identification，PID)、观察请求(observation request，OBR)、观察/结果(observation/result，OBX)四个必要的段，MSH段定义了消息的意图、来源、目的地以及一些语法定义；PID段记录了患者的基本信息包括患者唯一识别信息如患者ID，以及人口统计学信息，如患者姓名；OBR段为观察报告头，记录了相关医嘱信息以及所有观察指标的共同属性；OBX段记录了一个观察指标或一个观察指标片断的结果[9]。
OBX段是可重复的，一条消息可以包含多个观察指标结果，每个观察指标结果用一个OBX段记录，以下是一条记录心率和血氧值的HL7消息：
MSH|∧~\&|Monitor∧A001002003004005∧EUI-64||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID123345|P|2.5|||NE|AL|||||IHE PCD ORU-R01 210∧HL7∧2.16.840 .1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|||monitoring∧A000100020003004||||20100930095729.100+0800
OBX|1|NM|147842∧MDC_ECG_HEART_RATE∧MDC||60|264864∧MDC_DIM_BEAT_PER_MIN∧MDC|||||R||心率OBX段
OBX|2|NM|150456∧MDC_PULS_OXIM_SAT_O2∧MDC||95|262688∧MDC_DIM_PERCENT∧MDC|||||R||血氧OBX段
2.2 波形内容模块(WCM)集成模式
WCM在一定程度上对DEC集成模式进行了扩展，它定义了波形传输的数据结构和语义，提供DOR向DOC传递实时波形数据的方法[10]。波形消息同样采用HL7 ORU∧R01∧ORU_R01消息类型，消息中的每个波形部分采用一个OBR段标识，多个OBX段记录波形数据和参数，其中包含两个必要OBX段，分别是采样率段和波形观察结果段。以下是一个具有两导联心电波形的消息。
MSH|∧~\&|Monitor||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID1233456789|P|2.5|||NE|AL|||||
IHE PCD ORU-R01 210∧HL7∧2.16.840.1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|1||09780979a9879∧ACME HEALTH∧ABCD002343785379∧EUI-64|WAVEFORM|||20080515121000.100 -400|20080515121001.100-400心电波形OBR段
OBX|1|NM|0∧MDC_ATTR_SAMP_RATE∧MDC|1.1.1.1.1|256|264608∧MDC_DIM_PER_SEC心电采样率OBX
OBX|2|NA|131329∧ MDC_ECG_LEAD_I∧MDC|1.1.1.1|24∧72∧12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)|||||||||2008051512 1000.100Ⅰ导联波形观察结果OBX段
OBX|3|NA|131330∧ MDC_ECG_LEAD_II∧MDC |1.1.1.2|24∧72∧ 12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)||||||||| 2008051512 1000.100Ⅱ导联波形观察结果OBX段
2.3 术语映射(RTM)集成模式
RTM集成模式通过“Rosetta表”提供设备数据内容到标准术语ISO/IEEE 11073-10101 MDC(medical device communication)和UCUM(Unified Code for Units of Measure)的映射，MDC规定了医疗设备通信中的标准术语，UCUM是测量值单位规范码[11]。
Rosetta表主要用于规定HL7消息中OBX-3(观察标识)和OBX-6(单位)字段的数据格式，OBX-3格式为CF_CODE10∧REFID∧MDC，OBX-6格式为CF_UCODE10∧ UOM_MDC∧MDC。常用的CF_CODE10和REFID如表 1所示，CF_UCODE10和UOM_MDC如表 2所示。
表1
常见设备观察指标术语表
Table1.
Common observation codes
表2
常见设备单位术语表
Table2.
Common unit terminological codes
3 集成引擎的设计与实现
由于医疗仪器设备的输出信息不同、格式多种多样，难以通过一套固定的程序代码来实现全兼容，因此本研究采用协议转换引擎外挂设备驱动模块来加以解决。协议转换引擎是固定不变的，而设备驱动模块则可以根据不同仪器设备的信息通信协议进行定制，提高其灵活性。为降低编程的难度，使得用户也有可能自行扩充，我们选择Javascript脚本语言作为设备驱动模块的编程语言。
3.1 协议转换引擎的实现
协议转换引擎是实现医疗仪器通信协议与HL7标准之间转换的关键组件。该组件通过调用设备驱动模块的Javascript脚本，实现与医疗仪器的信息交换；同时实现DEC、WCM集成模式的DOR角色功能，通过HL7通信组件实现与医疗信息系统的PCD-01事务通信。
协议转换引擎需要实现以下功能：① 初始化设备驱动模块：加载编译协议转换脚本，获取设备接口信息，启动设备通信接口，等待接收设备数据；② 初始化HL7通信模块：获取DOC的配置信息，与信息系统建立通信连接；③ 实现DOR角色功能：将设备数据转换为HL7 ORU-R01消息并发送，同时接收DOC的ACK消息。
协议转换引擎采用C++语言编写，在其中内嵌一个V8 Javscript 引擎以连接设备驱动模块。V8 Javascript 引擎是由Google公司开发的一个开源的Javascript引擎，应用在 Google的开源浏览器Chrome中[12]，用C++编写而成，加载脚本后先对脚本进行编译，生成机器语言，因此执行效率高。
协议转换引擎工作流程如图 3所示，具体实现步骤如下：
(1)创建一个V8 Javascript 引擎实例，主要是创建HandleScope对象和Context对象；
(2)加载设备驱动模块脚本文件，通过Script::Compile()编译加载后的脚本，得到Handle＜Script＞实例script；
(3)获取脚本中GetCommConfig、GetDOCConfig、GetDeviceId、Parse等函数的调用入口：通过当前脚本执行环境Context实例的Global()函数获取全局对象globalObj，再将函数名作为参数分别调用globalObj-＞Get(),得到Handle＜Function＞类型的函数指针getcommconfig、getdocconfig、getdeviceid、parse等；
(4)调用getdocconfig-＞Call()，获取信息系统所在服务器的IP地址和端口号，作为参数实例化HL7通信类hl7comm；
(5)调用getcommconfig-＞Call()，得到设备通信接口配置信息，初始化相应通信接口，接收设备数据帧，暂存入数据缓冲区中；调用getdeviceid-＞Call()，得到设备标识；
(6)从数据缓冲区中读取一个设备数据帧；
(7)调用脚本中的全局函数parse-＞Call()，函数参数为设备数据帧字符数组，返回的字符串值即为解析结果(格式为“观察指标1=值1，观察指标2=值2，……”)；
(8)用步骤7得到的解析结果作为参数，依次调用hl7comm的MakeMSHSeg、MakePIDSeg、MakeOBRSeg以及MakeOBXSeg函数，将得到的段组合成HL7 ORU_R01消息；
(9)调用hl7comm.Send()函数，参数为上一步骤得到的ORU_R01消息，由HL7通信模块完成消息发送和确认消息的接收；
(10)若继续转换转步骤6，否则结束。
图3
协议转换引擎流程图
Figure3.
Flow chart of protocol conversion engine
3.2 HL7通信模块的实现
HL7通信模块实现了HL7Comm类，封装了HL7消息构造、HL7消息解析、MLLP通信等功能。
3.2.1 HL7消息构造
HL7 ORU_R01消息包含MSH、PID、OBR及OBX四种消息段。其中OBX段的数目可变，为灵活构造消息，HL7通信模块中仅提供段构造函数，由调用者按需组合出HL7消息。
//MSH段构造函数
//输入：sendingApp 发送方标识
//输出：MSH段
string MakeMSHSeg(string sendingApp);
//PID段构造函数
//输入：patientId 患者标识号
// patientName 患者姓名
//输出：PID段
string MakePIDSeg(string patientId,string patientName);
//OBR段构造函数
//输入：orderNo 医嘱号
// serviced 服务标识号
/// startTime波形采样开始时间，构造DEC消息时为空串
//输出：OBR段
string MakeOBRSeg(string orderNo,string serviceId,string startTime);
//OBX段构造函数
//输入：index 消息段号
/// rosMDC 观察标识
/// level 观察层次
/// obsValue 观察值
/// rosUCUM 单位，构造WCM消息时为空串
//输出：OBX段
string MakeOBXSeg(string index,string rosMDC,string level,string obsValue,string rosUCUM);
3.2.2 HL7消息解析
HL7消息解析采用了正则表达式。正则表达式是对字符串操作的一种逻辑公式，通过描述字符串规则从而对字符串进行检索、替换、匹配等操作。本研究通过调用Boost库实现正则表达式的处理。
HL7消息分为消息段、字段、组件、子组件，分隔符分别为回车符、“|”、“∧”、“&”，据此编写出相应的正则表达式对HL7消息进行全解析或按需解析[13]。本研究中只需要对HL7消息进行按需解析，即根据指定的字段号或组件号获取相应的数据。
① 按需解析消息字段
一个字段可以表示为以“|”开头(正则表达式为\|)，后面有非“|”字符(正则表达式为[∧\|])0至多个(正则表达式为*)，即\|[∧\|]*。按需解析指定“消息段名-字段号”消息字段值的正则表达式为：
消息段名(\|[∧\|]*){字段号-1}\|([∧\|]*)
以获取PID-5(患者姓名字段)为例，主要解析过程如下:
//定义正则表达式，其中\|[∧\|]*重复4次
regex rgx(“PID(\\|[∧\\|]*){4}\\|([∧\\|]*)”);
//message：被解析消息 match：匹配结果
string PID_5 = “”;
if(regex_search(message,match,rgx))
PID_5=match[2];
② 按需解析消息组件
组件是以“∧”为分隔符的子字符串，在上述解析得到字段值的基础上，用以下正则表达式得到指定组件号的值：
(\∧[∧\∧]*){组件号-1}\∧([∧\∧]*)
3.2.3 MLLP(Minimal Lower Layer Protocol)通信
因为在TCP/IP 上传递的数据是一串连续的比特流，而HL7的封装协议要求通信代码能够识别每条消息的开始和结束。MLLP 是标准中规定的通过 TCP/IP网络传送 HL7 消息的机制，每个 HL7 消息用一个消息头(0x0B)和一个消息尾(0x1C和0x0D)封装，以标示消息的开始和结束。
HL7Comm构造函数传入DOC的IP地址和端口号，创建Socket实现TCP/IP网络通信，在此基础上实现HL7的MLLP协议。发送时按MLLP协议对消息进行头尾封装，接收时按MLLP协议根据头尾标记获取消息。
3.3 设备驱动模块的实现
设备驱动模块负责集成引擎与设备端的通信连接以及设备数据的解析处理等功能。不同的医疗设备有着不同的通信接口和数据格式，因此这部分代码的变动较大。为通用性和灵活性，在本研究中用Javascript脚本语言编写。在集成引擎中针对COM、CAN、TCP Server、TCP Client等接口类型，实现了通用的底层通信功能，只需要从设备驱动模块中得到设备接口的配置信息。设备驱动模块的另一个任务是对收到的数据进行分帧、校验、解析等处理。主要接口如下：
//获取设备通信配置信息
//输入：无
//输出：设备通信配置信息，格式为“接口类型，参数1，参数2，…”。
// 如“COM,1,9600,8,n,1”表示串口1，波特率9600，8位数据位，无奇偶校验，1位停止位；
// “TCP Server,510”表示为TCP服务器方式，端口号为510。
function GetCommConfig ();
//获取服务器通信配置信息
//输入：无
//输出：服务器通信配置信息，格式为“IP地址: 端口号”。
function GetDOCConfig ();
//获取设备标识
//输入：无
//输出：设备标识，用于构成服务标识号、医嘱号、发送方标识等
function GetDeviceId();
//获取设备数据查询命令
//输入：数据的MDC编码。为空则查询所有数据
//输出：被动方式设备数据查询命令帧,主动方式设备则返回空
function GetPollCmd(mdccode);
……
//解析数据
//输入：设备数据帧字符数组
//输出：解析结果，格式为“观察指标1=值1，观察指标2=值2，……”
function Parse(msg);
4 结果与讨论
IHE-PCD Pre-Connetathon Test Tool为IHE官方提供的PCD测试工具[14] ，打开测试工具所在网页，按要求配置相关参数。以NCC X5监护仪为被测设备，输出数据经过本研究的集成网关转换后发送给测试工具指定的服务器(IP地址129.6.24 .143 ，端口号13080)。该监护仪通过网口连接向TCP端口(如511)主动输出信息，因此将设备驱动模块的设备通信配置信息设置为“TCP Server，511”，服务器通信配置信息为“129.6.24.143:13080”。
图 4为接收到的一条血压原始数据，字节顺序为低字节在前，其中第10~11字节为收缩压，12~13字节为舒张压，14~15字节为平均压。
图4
血压原始数据
Figure4.
Raw data of blood pressure
协议转换后的HL7 ORU_R01消息如图 5所示。三个OBX段分别记录了收缩压(150 mm Hg)、舒张压(80mm Hg)和平均压(103 mm Hg)的测量值。在IHE-PCD Test Tool测试结果中可见正确接收到了该HL7 ORU_RO1消息并验证成功，如图 6所示。
图5
协议转换结果
Figure5.
Protocol conversion result
图6
测试结果
Figure6.
Test result
本研究可应用于通用型中央监护系统、手术麻醉系统以及数字化手术室集中控制系统等应用系统。这些应用系统只要实现DEC和WCM集成模式的DOC角色，通过局域网连接到本研究实现的集成网关，即可接收呼吸机、麻醉机、监护仪、输液泵等设备的数据，无需为每个设备编写特定的通信接口，提高其通用性与可扩展性。
医疗仪器设备的信息集成是医疗信息建设的难点之一，目前国内对于这类医疗仪器与信息系统集成的研究还在发展阶段。本研究提出的基于IHE PCD的医疗仪器信息集成技术，可将医疗仪器的通信协议转换成符合HL7标准的消息格式，且不仅支持单一设备通信协议的转换，具有一定的通用性，对医疗仪器设备的信息集成和共享具有良好的应用价值，对在用医疗仪器设备的信息集成尤具价值。
引言
伴随着医疗信息化的深入，信息共享需求的增大，医疗仪器的信息集成已经成为医疗信息化的一个非常重要的组成部分，为广大医院以及医疗器械厂商所关注。医疗仪器的研发除了关注创新或完善仪器本身的诊断或治疗功能之外，如何与医疗信息系统互联互通也成为一个共性问题。
医学影像类的医疗仪器设备如CT、MR、US等的数据接口已经广泛采用了医学数字影像传输标准(digital imaging and communications in medicine，DICOM)，所以这类医疗仪器的集成技术相对较为成熟。而其他非影像类医疗仪器设备如监护仪、麻醉机、呼吸机等产品却没有采用统一的标准接口，这类医疗仪器的信息集成存在接口复杂、可扩展性差等问题。目前的状况是厂商自行定义通信接口，不同厂商之间的设备或信息系统间没有通用的互联方案，只能采取Case-by-Case的办法解决。
医疗健康信息集成协会(Integrating the Healthcare Enterprise，IHE)是医疗信息技术领域的重要国际组织。为解决医疗设备的信息集成问题，于2005年开始发布基于健康信息交换第七层协议(Health Level Seven,HL7)和ISO/IEEE 11 073的患者护理设备(Patient Care Device，PCD)技术框架。PCD技术框架规范了通信场景以及医疗设备与医疗设备数据接收单元之间的流程,从而促进医疗环境中设备数据的交换效率，加强患者信息安全，提高医疗保健质量[1-2]。该技术框架得到越来越多厂商的关注，开始在产品设计中应用IHE PCD的集成框架解决医疗仪器的信息集成问题[3]。参与美国医疗健康信息与管理系统协会(Healthcare Information and Management Systems Society，HIMSS)举办的IHE PCD展示的企业从2007年的6家发展到23家，包括GE、德尔格、飞利浦等。 Capsule公司研发的一套符合PCD技术框架的医疗设备信息集成解决方案，可以支持超过600种不同医疗设备的集成，并于2012年IHE 测试会上成功地进行了测试。由Intel发起的240多个业界厂商参与的Continua健康联盟在个人远程健康系统的研究中，将IHE PCD作为个人健康设备通信的解决方案，利用设备数据通信(Device Enterprise Communication，DEC)集成模式实现广域网络接口的患者数据的传送[4]。国内在医疗仪器集成技术方面的研究相对滞后，多为单一设备的HL7接口实现方案[5-7]，对PCD的研究和应用甚少。
1 医疗仪器信息接口分析与集成框架
医疗仪器设备的信息集成存在困难的原因是其信息接口存在较大的差异，主要表现在硬件接口(串口、以太网口、CAN、WLAN、蓝牙、WAN等)、帧格式(波特率、起始符、帧长度、终止符等)、校验方式(奇偶、checksum、CRC等)、域定界方式(定长、分界符等)、编码方式(文本、二进制、BCD等)、信息输出方式(主动式、被动式)和指令集等的不同，如Drager的Fabius GS呼吸机，硬件接口为串口COM，采用的是其medibus通信协议，信息输出方式为被动方式，即请求/响应模式，设备收到系统的请求命令后才会输出信息。而另一些医疗设备的信息输出为主动方式，如NCC X5插件式多参数监护仪采用网口输出，通信协议为自定义等。
本研究提出一种通用医疗仪器集成网关软硬件平台，如图 1所示。该平台兼容多种厂商的设备接口和通信协议，按照IHE PCD定义的通信框架和HL7消息格式，将医疗仪器通信协议转换为统一的IHE PCD事务协议，使得医疗设备能与信息系统进行无缝连接以及无障碍数据交换。该平台包括可配置多接口硬件平台(满足不同硬件接口)、协议转换引擎(实现医疗仪器通信协议转换)、设备驱动(满足不同设备工作模式)以及HL7接口通信模块(实现与信息系统之间的HL7通信)。
图1
医疗仪器集成网关软硬件平台框架
Figure1.
Framework of medical instrument integrating gateway
2 IHE PCD技术框架
IHE PCD技术框架对不同的集成需求定义了多个集成模式。其中DEC 集成模式用于规范医疗仪器设备与信息系统间的设备数据的传输，如血压数据、心率数据等；波形内容模块(waveform content module，WCM)集成模式规范了波形数据的传输，如心电波形数据、SPO2波形数据等；术语映射(rosetta terminology mapping，RTM)集成模式则是对DEC、WCM等集成模式中所涉及的术语进行了规定，以避免二义性。医疗仪器可按照各自的功能要求，选择实现若干集成模式中定义的角色，即可满足集成要求。
2.1 设备数据通信(DEC)集成模式
DEC集成模式基于ISO/IEEE 11073和HL7标准，采用一致的消息格式和设备语义内容将医疗仪器设备信息传输到临床信息系统，现在涉及的仪器设备主要有输液泵、监护仪、呼吸机和麻醉机等。DEC将信息系统与医疗仪器设备分别抽象成设备数据使用者(device observation consumer，DOC)和设备数据报告者(device observation reporter，DOR)两个角色，图 2为DEC的角色事务图[8]。
图2
DEC角色事务图
Figure2.
Actors and transcation of DEC
DOR与DOC之间通过PCD-01事务进行交互，具体是DOR通过HL7 ORU_R01消息将采集的设备数据传送给DOC，DOC正确接收后返回一个HL7 ACK消息给DOR。 ORU_R01消息中包含消息头(message header，MSH)、患者标识(patient identification，PID)、观察请求(observation request，OBR)、观察/结果(observation/result，OBX)四个必要的段，MSH段定义了消息的意图、来源、目的地以及一些语法定义；PID段记录了患者的基本信息包括患者唯一识别信息如患者ID，以及人口统计学信息，如患者姓名；OBR段为观察报告头，记录了相关医嘱信息以及所有观察指标的共同属性；OBX段记录了一个观察指标或一个观察指标片断的结果[9]。
OBX段是可重复的，一条消息可以包含多个观察指标结果，每个观察指标结果用一个OBX段记录，以下是一条记录心率和血氧值的HL7消息：
MSH|∧~\&|Monitor∧A001002003004005∧EUI-64||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID123345|P|2.5|||NE|AL|||||IHE PCD ORU-R01 210∧HL7∧2.16.840 .1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|||monitoring∧A000100020003004||||20100930095729.100+0800
OBX|1|NM|147842∧MDC_ECG_HEART_RATE∧MDC||60|264864∧MDC_DIM_BEAT_PER_MIN∧MDC|||||R||心率OBX段
OBX|2|NM|150456∧MDC_PULS_OXIM_SAT_O2∧MDC||95|262688∧MDC_DIM_PERCENT∧MDC|||||R||血氧OBX段
2.2 波形内容模块(WCM)集成模式
WCM在一定程度上对DEC集成模式进行了扩展，它定义了波形传输的数据结构和语义，提供DOR向DOC传递实时波形数据的方法[10]。波形消息同样采用HL7 ORU∧R01∧ORU_R01消息类型，消息中的每个波形部分采用一个OBR段标识，多个OBX段记录波形数据和参数，其中包含两个必要OBX段，分别是采样率段和波形观察结果段。以下是一个具有两导联心电波形的消息。
MSH|∧~\&|Monitor||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID1233456789|P|2.5|||NE|AL|||||
IHE PCD ORU-R01 210∧HL7∧2.16.840.1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|1||09780979a9879∧ACME HEALTH∧ABCD002343785379∧EUI-64|WAVEFORM|||20080515121000.100 -400|20080515121001.100-400心电波形OBR段
OBX|1|NM|0∧MDC_ATTR_SAMP_RATE∧MDC|1.1.1.1.1|256|264608∧MDC_DIM_PER_SEC心电采样率OBX
OBX|2|NA|131329∧ MDC_ECG_LEAD_I∧MDC|1.1.1.1|24∧72∧12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)|||||||||2008051512 1000.100Ⅰ导联波形观察结果OBX段
OBX|3|NA|131330∧ MDC_ECG_LEAD_II∧MDC |1.1.1.2|24∧72∧ 12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)||||||||| 2008051512 1000.100Ⅱ导联波形观察结果OBX段
2.3 术语映射(RTM)集成模式
RTM集成模式通过“Rosetta表”提供设备数据内容到标准术语ISO/IEEE 11073-10101 MDC(medical device communication)和UCUM(Unified Code for Units of Measure)的映射，MDC规定了医疗设备通信中的标准术语，UCUM是测量值单位规范码[11]。
Rosetta表主要用于规定HL7消息中OBX-3(观察标识)和OBX-6(单位)字段的数据格式，OBX-3格式为CF_CODE10∧REFID∧MDC，OBX-6格式为CF_UCODE10∧ UOM_MDC∧MDC。常用的CF_CODE10和REFID如表 1所示，CF_UCODE10和UOM_MDC如表 2所示。
表1
常见设备观察指标术语表
Table1.
Common observation codes
表2
常见设备单位术语表
Table2.
Common unit terminological codes
3 集成引擎的设计与实现
由于医疗仪器设备的输出信息不同、格式多种多样，难以通过一套固定的程序代码来实现全兼容，因此本研究采用协议转换引擎外挂设备驱动模块来加以解决。协议转换引擎是固定不变的，而设备驱动模块则可以根据不同仪器设备的信息通信协议进行定制，提高其灵活性。为降低编程的难度，使得用户也有可能自行扩充，我们选择Javascript脚本语言作为设备驱动模块的编程语言。
3.1 协议转换引擎的实现
协议转换引擎是实现医疗仪器通信协议与HL7标准之间转换的关键组件。该组件通过调用设备驱动模块的Javascript脚本，实现与医疗仪器的信息交换；同时实现DEC、WCM集成模式的DOR角色功能，通过HL7通信组件实现与医疗信息系统的PCD-01事务通信。
协议转换引擎需要实现以下功能：① 初始化设备驱动模块：加载编译协议转换脚本，获取设备接口信息，启动设备通信接口，等待接收设备数据；② 初始化HL7通信模块：获取DOC的配置信息，与信息系统建立通信连接；③ 实现DOR角色功能：将设备数据转换为HL7 ORU-R01消息并发送，同时接收DOC的ACK消息。
协议转换引擎采用C++语言编写，在其中内嵌一个V8 Javscript 引擎以连接设备驱动模块。V8 Javascript 引擎是由Google公司开发的一个开源的Javascript引擎，应用在 Google的开源浏览器Chrome中[12]，用C++编写而成，加载脚本后先对脚本进行编译，生成机器语言，因此执行效率高。
协议转换引擎工作流程如图 3所示，具体实现步骤如下：
(1)创建一个V8 Javascript 引擎实例，主要是创建HandleScope对象和Context对象；
(2)加载设备驱动模块脚本文件，通过Script::Compile()编译加载后的脚本，得到Handle＜Script＞实例script；
(3)获取脚本中GetCommConfig、GetDOCConfig、GetDeviceId、Parse等函数的调用入口：通过当前脚本执行环境Context实例的Global()函数获取全局对象globalObj，再将函数名作为参数分别调用globalObj-＞Get(),得到Handle＜Function＞类型的函数指针getcommconfig、getdocconfig、getdeviceid、parse等；
(4)调用getdocconfig-＞Call()，获取信息系统所在服务器的IP地址和端口号，作为参数实例化HL7通信类hl7comm；
(5)调用getcommconfig-＞Call()，得到设备通信接口配置信息，初始化相应通信接口，接收设备数据帧，暂存入数据缓冲区中；调用getdeviceid-＞Call()，得到设备标识；
(6)从数据缓冲区中读取一个设备数据帧；
(7)调用脚本中的全局函数parse-＞Call()，函数参数为设备数据帧字符数组，返回的字符串值即为解析结果(格式为“观察指标1=值1，观察指标2=值2，……”)；
(8)用步骤7得到的解析结果作为参数，依次调用hl7comm的MakeMSHSeg、MakePIDSeg、MakeOBRSeg以及MakeOBXSeg函数，将得到的段组合成HL7 ORU_R01消息；
(9)调用hl7comm.Send()函数，参数为上一步骤得到的ORU_R01消息，由HL7通信模块完成消息发送和确认消息的接收；
(10)若继续转换转步骤6，否则结束。
图3
协议转换引擎流程图
Figure3.
Flow chart of protocol conversion engine
3.2 HL7通信模块的实现
HL7通信模块实现了HL7Comm类，封装了HL7消息构造、HL7消息解析、MLLP通信等功能。
3.2.1 HL7消息构造
HL7 ORU_R01消息包含MSH、PID、OBR及OBX四种消息段。其中OBX段的数目可变，为灵活构造消息，HL7通信模块中仅提供段构造函数，由调用者按需组合出HL7消息。
//MSH段构造函数
//输入：sendingApp 发送方标识
//输出：MSH段
string MakeMSHSeg(string sendingApp);
//PID段构造函数
//输入：patientId 患者标识号
// patientName 患者姓名
//输出：PID段
string MakePIDSeg(string patientId,string patientName);
//OBR段构造函数
//输入：orderNo 医嘱号
// serviced 服务标识号
/// startTime波形采样开始时间，构造DEC消息时为空串
//输出：OBR段
string MakeOBRSeg(string orderNo,string serviceId,string startTime);
//OBX段构造函数
//输入：index 消息段号
/// rosMDC 观察标识
/// level 观察层次
/// obsValue 观察值
/// rosUCUM 单位，构造WCM消息时为空串
//输出：OBX段
string MakeOBXSeg(string index,string rosMDC,string level,string obsValue,string rosUCUM);
3.2.2 HL7消息解析
HL7消息解析采用了正则表达式。正则表达式是对字符串操作的一种逻辑公式，通过描述字符串规则从而对字符串进行检索、替换、匹配等操作。本研究通过调用Boost库实现正则表达式的处理。
HL7消息分为消息段、字段、组件、子组件，分隔符分别为回车符、“|”、“∧”、“&”，据此编写出相应的正则表达式对HL7消息进行全解析或按需解析[13]。本研究中只需要对HL7消息进行按需解析，即根据指定的字段号或组件号获取相应的数据。
① 按需解析消息字段
一个字段可以表示为以“|”开头(正则表达式为\|)，后面有非“|”字符(正则表达式为[∧\|])0至多个(正则表达式为*)，即\|[∧\|]*。按需解析指定“消息段名-字段号”消息字段值的正则表达式为：
消息段名(\|[∧\|]*){字段号-1}\|([∧\|]*)
以获取PID-5(患者姓名字段)为例，主要解析过程如下:
//定义正则表达式，其中\|[∧\|]*重复4次
regex rgx(“PID(\\|[∧\\|]*){4}\\|([∧\\|]*)”);
//message：被解析消息 match：匹配结果
string PID_5 = “”;
if(regex_search(message,match,rgx))
PID_5=match[2];
② 按需解析消息组件
组件是以“∧”为分隔符的子字符串，在上述解析得到字段值的基础上，用以下正则表达式得到指定组件号的值：
(\∧[∧\∧]*){组件号-1}\∧([∧\∧]*)
3.2.3 MLLP(Minimal Lower Layer Protocol)通信
因为在TCP/IP 上传递的数据是一串连续的比特流，而HL7的封装协议要求通信代码能够识别每条消息的开始和结束。MLLP 是标准中规定的通过 TCP/IP网络传送 HL7 消息的机制，每个 HL7 消息用一个消息头(0x0B)和一个消息尾(0x1C和0x0D)封装，以标示消息的开始和结束。
HL7Comm构造函数传入DOC的IP地址和端口号，创建Socket实现TCP/IP网络通信，在此基础上实现HL7的MLLP协议。发送时按MLLP协议对消息进行头尾封装，接收时按MLLP协议根据头尾标记获取消息。
3.3 设备驱动模块的实现
设备驱动模块负责集成引擎与设备端的通信连接以及设备数据的解析处理等功能。不同的医疗设备有着不同的通信接口和数据格式，因此这部分代码的变动较大。为通用性和灵活性，在本研究中用Javascript脚本语言编写。在集成引擎中针对COM、CAN、TCP Server、TCP Client等接口类型，实现了通用的底层通信功能，只需要从设备驱动模块中得到设备接口的配置信息。设备驱动模块的另一个任务是对收到的数据进行分帧、校验、解析等处理。主要接口如下：
//获取设备通信配置信息
//输入：无
//输出：设备通信配置信息，格式为“接口类型，参数1，参数2，…”。
// 如“COM,1,9600,8,n,1”表示串口1，波特率9600，8位数据位，无奇偶校验，1位停止位；
// “TCP Server,510”表示为TCP服务器方式，端口号为510。
function GetCommConfig ();
//获取服务器通信配置信息
//输入：无
//输出：服务器通信配置信息，格式为“IP地址: 端口号”。
function GetDOCConfig ();
//获取设备标识
//输入：无
//输出：设备标识，用于构成服务标识号、医嘱号、发送方标识等
function GetDeviceId();
//获取设备数据查询命令
//输入：数据的MDC编码。为空则查询所有数据
//输出：被动方式设备数据查询命令帧,主动方式设备则返回空
function GetPollCmd(mdccode);
……
//解析数据
//输入：设备数据帧字符数组
//输出：解析结果，格式为“观察指标1=值1，观察指标2=值2，……”
function Parse(msg);
4 结果与讨论
IHE-PCD Pre-Connetathon Test Tool为IHE官方提供的PCD测试工具[14] ，打开测试工具所在网页，按要求配置相关参数。以NCC X5监护仪为被测设备，输出数据经过本研究的集成网关转换后发送给测试工具指定的服务器(IP地址129.6.24 .143 ，端口号13080)。该监护仪通过网口连接向TCP端口(如511)主动输出信息，因此将设备驱动模块的设备通信配置信息设置为“TCP Server，511”，服务器通信配置信息为“129.6.24.143:13080”。
图 4为接收到的一条血压原始数据，字节顺序为低字节在前，其中第10~11字节为收缩压，12~13字节为舒张压，14~15字节为平均压。
图4
血压原始数据
Figure4.
Raw data of blood pressure
协议转换后的HL7 ORU_R01消息如图 5所示。三个OBX段分别记录了收缩压(150 mm Hg)、舒张压(80mm Hg)和平均压(103 mm Hg)的测量值。在IHE-PCD Test Tool测试结果中可见正确接收到了该HL7 ORU_RO1消息并验证成功，如图 6所示。
图5
协议转换结果
Figure5.
Protocol conversion result
图6
测试结果
Figure6.
Test result
本研究可应用于通用型中央监护系统、手术麻醉系统以及数字化手术室集中控制系统等应用系统。这些应用系统只要实现DEC和WCM集成模式的DOC角色，通过局域网连接到本研究实现的集成网关，即可接收呼吸机、麻醉机、监护仪、输液泵等设备的数据，无需为每个设备编写特定的通信接口，提高其通用性与可扩展性。
医疗仪器设备的信息集成是医疗信息建设的难点之一，目前国内对于这类医疗仪器与信息系统集成的研究还在发展阶段。本研究提出的基于IHE PCD的医疗仪器信息集成技术，可将医疗仪器的通信协议转换成符合HL7标准的消息格式，且不仅支持单一设备通信协议的转换，具有一定的通用性，对医疗仪器设备的信息集成和共享具有良好的应用价值，对在用医疗仪器设备的信息集成尤具价值。
