基于插件架构的手术室设备集中控制系统

王云龙

上海医疗器械股份有限公司，上海市，200093

基于插件架构的手术室设备集中控制系统

【作 者】王云龙

上海医疗器械股份有限公司，上海市，200093

手术室设备集中控制对于提高手术效率具有重要的意义。由于国内手术室医疗设备普遍存在种类繁多，通信接口不一致以及控制面板差异较大等问题，设计和实现设备集中控制，是一体化手术室建设的重点和难点。该文基于插件程序架构，通过定义通信插件接口和设备插件接口，把设备的差异性封装在具体的设备插件动态链接库中来实现兼容性，通过反射机制动态加载调用，具有很好的灵活性和可扩展性，实现了手术室医疗设备的集中控制。

手术室；集中控制；插件；反射

0 引言

一体化手术室是随着微创技术的发展而诞生的一个新的医疗应用，它是以创造手术室的高效率、高安全性以及提升手术室对外交流为目的的多个系统(如音视频、设备控制、通讯、信息系统等)的综合运用。在手术过程中，医生需要根据手术操作的需要，对多个设备的参数进行设置调整。由于设备控制面板繁多以及无菌区域使用空间的限制，给医生的手术操作带来困难，设备功能也得不到有效利用[1]。采用计算机网络技术将多个手术设备集成到一个系统中，充分体现高性能、数字化、智能化、洁净化，手术医生能通过中央控制系统来完成对各种设备的控制，提高设备的可操作性，节约手术的准备时间，提高手术室工作效率，更安全、精确、高效地完成手术[2]。本文针对手术室设备集中控制的难题，基于插件程序架构，实现医疗设备的集中控制。

1 一体化手术室医疗设备的集中控制

一体化手术室可以通过一台主机集中控制手术室内的主要设备、实时记录设备的运行数据和手术过程。一体化手术室的核心部件是集中控制触摸屏工作站，通过触摸屏对手术室内医用设备进行集中管理与监控[3]，包括无影灯的光照强度、手术床升降倾角等位移动作、高频电刀工作模式及频率、内窥镜参数及冷光源亮度的调整等，如图1所示。

图1 医疗设备集中控制示意图Fig.1 Centralized control diagram

一体化手术室建设的重要环节是设备集中控制的实现，本节介绍设备集中控制中面临的问题，并提出相应的解决方案。

1.1 设备集中控制面临的难题

（1）设备控制的兼容性。在现有的手术室内，医疗设备种类繁多，各种设备控制面板的差异较大。面板按键及键盘工作方式各不相同，面板指示（包括LED灯、七段数码管等）也不相同。并且现有手术室设备大多数都是独立的单元，没有对外统一的通信接口。

（2）设备配置的差异性。不同功能的手术室的设备配置有较大的差异，各设备的生产厂家不同，通信控制协议也会不同，难以设计一套包罗万象的集中控制程序。

（3）集中控制的安全可靠性。集中控制的通信质量优劣直接关系到手术的安全性及效率，由于手术室空间有限、电气设备繁多，这就要求主控工作站和受控设备之间的通信要及时、准确、可靠，抗干扰能力强。所以手术室内医疗设备集中控制的实现具有一定的困难。

1.2 设备集中控制解决方案

分析设备集中控制所面临的问题，可知手术室医疗设备的控制与配置差异性大，缺乏基于统一标准的数字化接口，要求设备集中控制系统具有很好的兼容性、灵活性与可扩展性。插件程序结构由框架程序和插件组成，每一个插件可以单独实现，通过安装或配置加入到框架程序中，很适合设备集中控制程序的要求。通过定义通信插件接口和设备插件接口，把设备的通信接口和操作的差异性封装在具体的设备插件动态链接库中来实现兼容性，通过反射机制动态加载调用，具有很好的灵活性和可扩展性。

对于没有通信接口的现有产品实施升级改造，我们选择实时性好、可靠性强、布线方便的CAN总线[4]作为通信接口标准，采用单片机和CPLD设计了通信接口板[5]，实时接受集中控制的操作信号并向其反馈设备的显示数据。

2 设备集中控制程序设计

2.1 插件式结构

插件式程序由主体程序和插件（Plug-in或addon）组成，插件是一种遵循插件接口编写出来的程序，主要是用来扩展软件功能。插件的本质是在不修改主体程序的情况下对软件功能进行加强。不同插件之间相互独立，互不影响，方便软件功能的封装。只要知道插件接口，任何人都可以自己设计插件来扩展程序的功能。插件通过安装或配置加入主体程序，具有很好的灵活性和可扩展性。

设备集中控制程序采用了插件式程序结构，即每一种设备的控制程序都独立开发成可动态加载的设备插件，可采用不同的语言开发，具有不同的外观和独立的功能，只要符合接口要求即可。程序的基本结构如图2所示，由框架主程序、设备插件、通信插件组成。

图2 控制程序插件式结构图Fig.2 Plug-in architecture of control system

2.2 通信插件接口

设备的通信接口多种多样，常见的有串口、网口、红外、CAN等物理接口，网口按照其通信协议又可分为Client和Server方式，还有点对点与总线方式的差异。每种接口的连接参数的数量和类型都有差异，但所提供的服务基本一致，即提供消息的发送和接收服务。为此通过ICommunication接口规定了每种通信插件的调用接口：

public interface ICommunication

{

uint comIdx { get; set; } //通信插件序号

string comName { get; } //通信插件名

uint comID { get; set; } //通信地址号

string comSetting { get; set; } //通信插件设置

ComStatus comStatus { get; } //通信插件状态

string[] copyFiles { get; } //通信插件必备文件列表，用于安装时复制文件

bool Start(string Setting); //在客户机类通信插件中启动连接

bool Stop(); //在客户机类通信插件中关闭连接

bool Send(int Addr,Byte[] msg); //发送数据

event EventHandler Receiving; //通信插件接收数据事件

……

}

2.3 设备插件接口

每种设备都有独立的不同大小的操作界面，有数量不等的按钮和显示单元，与实体设备间通过不同的通信接口相连，通过不同的通信协议发送控制命令和接收状态显示。为此通过IDevice接口规定了设备插件的调用接口：

public interface IDevice

{

IList Communication { get; set; }//插件调用通信的接口

string Name { get; set; }//插件名，由框架程序置入

string DefaultCommType { get; }//默认通信类型

string DefaultCommSetting { get; }//默认通信参数

string DefaultDeviceName { get; } //默认设备名

IntPtr Handle { get; } //插件界面句柄

string[] CopyFiles { get; } //插件必备文件列表，在安装插件时复制

ImageList Icons { get; } //插件图标集，图标大小为64*64

IList GroupHandle { get;}//关联窗体列表，由框架添加

void Load(); //插件加载

void UnLoad(); //插件卸载

void Alarm(); //报警通知

void Notify(Object src, ComEventArgs e); //事件消息处理程序

void MessageProc(Object src, StateMachinArgs e);//消息处理状态机

……

}

3 设备集中控制程序实现

3.1 插件的实现

设备插件是一个动态链接库，一个设备插件主要由设备接口类和界面窗体类组成，其中，设备接口类是设备插件的必备部分，实现了IDevice接口，为框架程序安装设备插件时提供初始的配置信息，也是框架程序在加载时初始化设备插件的入口，同时也是设备的通信插件实例与设备交互的接口。界面窗体类是设备插件的人机界面部分，完成设备的显示、响应按键操作等人机交互，是物理设备的虚拟界面，实现设备的集中显示和控制。界面窗体类由设备接口类实例化，由框架程序控制是否显示以及显示的屏幕与区域位置。此外根据设备的不同可以有0至多个辅助窗体类，通常作为界面窗体类的弹出窗体，用来完成设备的配置信息修改，数据的查询与显示等功能。

项目实施过程中实现了手术床插件、无影灯插件、内窥镜插件(见图3)、冷光源插件、输液泵插件、监护仪插件、呼吸机插件等设备插件，每种设备插件都是一个独立的DLL工程，方便新的设备插件的扩展。

图3 内窥镜插件Fig.3 Endoscopy plug-in

图4 设备管理窗体Fig.4 Device management form

通信插件的实现相对比较简单，由实现ICommunication接口的通信接口类和可选的辅助类组成。实际实现了串口通信插件、CAN通信插件、TCP Server插件及TCP Client插件。同样每个插件都是独立的DLL工程，便于根据新的设备通信接口的需要，添加相应的通信插件。

3.2 框架程序的实现

框架程序DORMain是设备控制系统的主体程序。该软件完成通信插件的安装、设备插件的安装、通信插件的加载、设备插件的加载等初始化工作，响应设备选择面板或菜单栏的操作显示或隐藏对应设备插件，具体的控制操作均由设备插件自身的窗体界面实现。

3.2.1 插件的安装

实现了IDevice接口的设备插件DLL，可以通过框架程序中的设备管理窗体(见图4)进行安装，采用上述反射机制读出该设备插件的配置信息，保存到设备配置文件，供框架程序初始化时使用。通信插件的安装通过通信插件管理窗体进行。设备或通信插件必须经过一次安装，才能被框架程序所使用。

3.2.2 插件的加载

在每一次框架主程序启动时，通过遍历设备配置文件中的Device节点，读取各设备的配置信息，用反射机制实现设备插件的动态加载，完成设备插件的实例化、通信接口的初始化、设备插件实例与通信插件实例的连接、添加到设备选择面板等功能，流程如图5所示，加载完成后的设备选择面板如图6所示。

图5 设备插件的动态加载Fig.5 Dynamic loading of device plug-in

图6 设备选择面板Fig.6 Device control panel

3.2.3 设备插件的显示与控制

在设备加载过程结束时，设备插件自带的图标被添加到设备选择面板，通过响应该图标的点击控制相应设备插件的显示与隐藏。当设备插件界面显示在设备集中控制程序中时，单击该设备界面里的按钮，即可通过通信接口向物理设备发送相应的操作命令，物理设备执行对应的动作，并把操作结果及状态发送回来，设备界面中显示发生相应的改变，使得设备集中控制程序中设备插件界面与物理设备上的控制面板获得同样的操作效果。

图7为设备集中控制程序的截图，右侧为设备选择面板，界面中显示了呼吸机、手术床、无影灯、内窥镜4个设备插件。

图7 设备集中控制程序主界面Fig.7 Main UI of centralized control system

4 结论

一体化手术室是医院数字化的重要标志，也是手术室发展的必然趋势。本文探讨了一体化手术室医疗设备集中控制中面临的一些关键问题与解决办法。基于插件程序架构，通过定义通信插件接口和设备插件接口，把设备的差异性封装在具体的设备插件动态链接库中来实现兼容性，通过反射机制动态加载调用，具有很好的灵活性和可扩展性。本设计实现能够兼容手术室设备多样性的集中控制系统，于2014年成功安装于上海市同济医院妇产科手术室，并进行临床试验。今年初，在对同济医院该设备使用情况的回访过程中了解到：该系统自安装使用以来，每天都要进行至少2~3例手术，主要以妇产科、泌尿外科手术为主。与目前临床的传统手术室设备使用感觉比较，一体化手术室医疗设备集中控制系统在对临床外科手术的完整流程进行监控和信息采集上更加清晰和流畅；在对各种手术室设备的操控上更加安全和可靠，系统在其他方面：如设备的利用率、交叉感染等都具有更大的优势。因此，该架构的设计，是一体化手术室的一种可行解决方案，具有良好的应用前景。

[1] 冯靖炜, 陈华. 数字化手术室规划和建设[J]. 中国医疗设备, 2008, 23(10): 120-123.

[2] 王刚, 王云龙, 郑建立. 积极推进“数字式一体化手术室”产业化进程[J]. 中国医学装备, 2012, 9(4): 42-45.

[3] 宇新民, 李宏斌. 数字化手术室的研究与设计[J]. 中国医学装备, 2011(7): 38-40.

[4] 黄世安, 刘志国. CAN总线在医疗中的应用及展望[J]. 医疗卫生装备, 2014, 8(35): 112-115.

[5] 郑建立, 杨勇勇, 王云龙. 数字化手术室医疗设备集中控制方法的研究[J]. 计算机测量与控制, 2013, 21(3): 674-676.

Plug-in Based Centralized Control System in Operating Rooms

【 Writer 】Wang Yunlong
Shanghai Medical Devices Corporation Ltd., Shanghai, 200093

operating room, centralized control, plug-in, re fl ection dynamics

R472.3

A

10.3969/j.issn.1671-7104.2017.03.008

1671-7104(2017)03-0185-04

2017-04-05

王云龙，E-mail: 13916381305@163.com

【 Abstract 】Centralized equipment controls in an operating room (OR) is crucial to an ef fi cient work fl ow in the OR. To achieve centralized control, an integrative OR needs to focus on designing a control panel that can appropriately incorporate equipment from different manufactures with various connecting ports and controls. Here we propose to achieve equipment integration using plug-in modules. Each OR will be equipped with a dynamic plug-in control panel containing physically removable connecting ports. Matching outlets will be installed onto the control panels of each equipment used at any given time. This dynamic control panel will be backed with a database containing plug-in modules that can connect any two types of connecting ports common among medical equipment manufacturers. The correct connecting ports will be called using reflection dynamics. This database will be updated regularly to include new connecting ports on the market, making it easy to maintain, update, expand and remain relevant as new equipment are developed. Together, the physical panel and the database will achieve centralized equipment controls in the OR that can be easily adapted to any equipment in the OR.