應(yīng)用紫蜂技術(shù)將醫(yī)療器械一體化外文翻譯 英文

1、 Abstract— Wirelessly enabling Medical Devices such as Vital Signs Monitors, Ventilators and Infusion Pumps allows central data collection. This paper discusses how data from these types of devices can be integrate

2、d into hospital systems using wireless sensor networking technology. By integrating devices you are protecting investment and opening up the possibility of networking with similar devices. In this context we present

3、 how Zigbee meets our requirements for bandwidth, power, security and mobility. We have examined the data throughputs for various medical devices, the requirement of data frequency, security of patient data and the l

4、ogistics of moving patients while connected to devices. The paper describes a new tested architecture that allows this data to be seamlessly integrated into a User Interface or Healthcare Information System (HIS). Th

5、e design supports the dynamic addition of new medical devices to the system that were previously unsupported by the system. To achieve this, the hardware design is kept generic and the software interface for differe

6、nt types of medical devices is well defined. These devices can also share the wireless resources with other types of sensors being developed in conjunction on this project such as wireless ECG (Electrocardiogram) an

7、d Pulse-Oximetry sensors. Keywords—Biomedical Telemetry, Medical Devices, Bioinformatics, Wireless Sensor Networks, Healthcare Information Systems. I. INTRODUCTION ANY devices that exist today by the bedside in

8、 the hospital ward, intensive care unit or other clinical setting have data output features over serial ports and other types of interfaces such as USB. These devices are usually considered a significant investment

9、and are usually purchased in an ad hoc fashion as required when finance becomes available. The consequence of this is that devices are often from different manufacturers that don’t support any standard protocol. Th

10、is can make integrating these devices into a single network difficult. In the hospital ward Vital Signs monitors, Ventilators and Infusion Pumps of many different brands are usually portable and wheeled from patien

11、t to patient as required. By networking these devices the hospital gains all the advantages associated with storing patient data centrally in electronic records. By making the device part of a wireless sensor netwo

12、rk such as a Zigbee [1] network there are several more This work is supported by Enterprise Ireland. Paul Frehill is with the Department of IT, National University of Ireland Galway, Ireland (phone: 353-91-492040; e-m

13、ail: p.frehill1@ nuigalway.ie). Des Chambers is with the Department of IT, National University of Ireland Galway, Ireland (e-mail: des.chambers@nuigalway.ie). advantages including, cable replacement, mobility and lo

14、cation management. Once these devices are networked they can also use the infrastructure of other deployments of similar wireless sensor networks in the surrounding environment. To achieve this type of solution each

15、device must be fitted with a piece of hardware that will act as a serial to wireless bridge, a Medical Device Interface (MDI). This MDI will allow the device to receive and transmit data within the wireless sensor n

16、etwork. This inexpensive hardware will be generic to fit a wide range of medical devices. Similarly the firmware can be kept generic and any specific device communication protocols can be implemented on a server on

17、 the network backend. The work described in this paper is part of a larger project, the goal of which is to provide a complete patient monitoring system. Other features of the overall system will be to provide ECG (

18、Electrocardiogram) and Pulse-Oximetry data in a novel way over a wireless sensor network using expertise gained on prior projects [2]. II. RELATED WORK The concept of using wireless sensor networks for Medical Care

19、and wireless patient monitoring has been explored by others but integrating data from other devices is generally not discussed. There is ongoing related work in patient monitoring using wireless sensors such as the “

20、CodeBlue” project at Harvard [3]. Others have also proven successful with wireless sensor networks designs for medical sensors [4] and in the management of sensor data [5]. It has been identified that it is desirab

21、le to wirelessly enable existing medical devices that provide vital signs data using technologies such as Zigbee [6], [7]. The research described in this paper aspires to meet these requirements. The use of wireles

22、s sensor networks within the hospital has been extensively examined. Moreover, other wireless technologies within the same frequency band, such as IEEE 802.11 [8], have existed within the hospital for some time [9].

23、 III. REQUIREMENTS ANALYSIS A. Wireless Technologies Established standards for wireless applications, such as Bluetooth [10] and IEEE 802.11, allow high transmission rates, but at the expense of power consumption, a

24、pplication complexity, and cost. Zigbee offers low cost, low power devices that can communicate with each other and the outside Cosmin Rotariu is with the Department of IT, National University of Ireland Galway, Irela

25、nd (e-mail: crotariu@vega.it.nuigalway.ie). Using Zigbee to Integrate Medical Devices Paul Frehill, Desmond Chambers, Cosmin RotariuM Proceedings of the 29th Annual International Conference of the IEEE EMBS Cité Int

26、ernationale, Lyon, France August 23-26, 2007.SuB11.41-4244-0788-5/07/$20.00 ©2007 IEEE 6717Figure 2. MDI Block Diagram When the MDI is powered on, the Zigbee stack will automatically join a Zigbee network within ra

27、nge. Next the MDI will announce an ID which is also visible on the external surface of the device. This is done using a protocol we designed for this project. The protocol supports these types of status messages i

28、n addition to supporting the actual real data we are interested in. At this point it is possible to make an association with the MDI. To achieve this, the administrator selects the ID from an automatically generated

29、 list on screen, a patient demographic and a type of medical device which is supported in the system. This process results in the server sending the correct RS232 settings to the MDI for the medical device that it i

30、s connected to. Now that the system can communicate directly with the medical device the server will send any necessary commands to initiate a data stream from the device. C. Server Functionality The server is respon

31、sible for decoding specific medical device data. This functionality is implemented in a DLL (Dynamic Link Library) that is run on the server. There is one DLL for each type of medical device the system supports whi

32、ch allows for future medical devices to be supported without upgrading the server software. Any future device can easily be supported within the DLL framework by simply inheriting from the appropriate class for that

33、particular type of device. These DLLs are loaded at run-time and have a standard interface that each designer must adhere to in order to interoperate with the system. A designer must also complete an XML file from

34、a template to indicate which features the new medical device supports. The DLL only handles device specific information; the main server application decodes this information from our project protocol. Figure 3. New D

35、ata Request When the DLL is loaded by the server application it will receive a value to represent how frequently the server wants GUI data. This value is used to create the interval timer represented in the above UML

36、 diagram. When this timer expires the DLL will check the current state it has for the ventilator. Fig. 3 above shows an activity diagram representing a sequence of events surrounding this timer expiration in a DLL

37、for a ventilator. When the timer expires the DLL retrieves the command in the form of a byte array of ASCII characters. Next the DLL raises an event containing the byte array. The server application accepts this eve

38、nt through its event handler, encodes it in our protocol and sends it to the medical device. Figure 4. Handling New Data When the medical device returns a response to the server application this data is passed to the

39、DLL as shown in Fig. 4 above. If the DLL does not receive any data within a specified timeout period the DLL will re-initiate communication with the medical device. Data that is received by the DLL is checked to se

40、e if it is consistent with the format expected and that the checksum is valid if applicable. Once the data is proven to be valid, a generic data structure that is shared between the server application and clients is

41、populated. Finally the DLL will raise another event, this time to indicate that GUI data is available. The server then multicasts the new data to any client that is subscribed to that address. The Server could be e