2022年通信专业英语翻译 .pdf

Proceedings of the 29th Annual International Conference of the IEEE EMBS Cit Internationale, Lyon, France August 23-26, 2007. Using Zigbee to Integrate Medical Devices Paul Frehill, Desmond Chambers, Cosmin Rotariu AbstractWirelessly 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 integrated 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 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 logistics 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). The 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 different 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) and Pulse-Oximetry sensors. KeywordsBiomedical Telemetry, Medical Devices, Bioinformatics, Wireless Sensor Networks, Healthcare Information Systems. I. INTRODUCTION MANY devices that exist today by the bedside in 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 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. This 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 patient 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 network such as a Zigbee 1 network there are several more advantages including, cable replacement, mobility and location 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 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 network. 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 the network 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 12 页 - - - - - - - - - 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 (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 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 “ 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 desirable 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 wireless 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. 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, application complexity, and cost. Zigbee offers low cost, low power devices that can communicate with each other and the outside world. ZigBees self-forming and self-healing mesh-network architecture lets data and control messages pass from one node to another by multiple paths. This is particularly useful in a hospital environment where interference from walls, people and general obstacles is a major issue. Zigbee is based upon the IEEE standard 802.15.4 11 for radio hardware and software specification. B. Mobility Zigbee enabled devices support a sleep mode. An off-line node can connect to a network in about 30 ms. Waking up a sleeping node takes about 15 ms, as does accessing a channel and transmitting data. If the requirement is to collect data once a minute the device can be placed in a power saving mode saving significant amounts of energy and increasing the battery life. In sleep mode a zigbee chip can assume as little as 1.0uA 12. This is particularly important in a medical setting where patients are often on the move while still attached to medical devices. C. Co-existence Both Zigbee and IEEE802.11 operate in the license-free industrial scientific medical (ISM) 2.4GHz frequency band.IEEE802.11 is already in widespread use within hospitals which would encourage the adoption of Zigbee solutions in the same environment. However care has to be taken to avoid interference between these 2 neighbouring technologies as described in the paper entitled “ Coexistance of IEEE802.15.4 with other systems in the 2.4GHz-ISM- band” 13. Byselecting an appropriate channel, after performing a simple site survey, these problems can be easily avoided. D. Device Parameters Typical readings available on a ventilator are Inspiratory Tidal Volume, Expiratory Tidal Volume, O2 concentration,Respiratory Rate, Peak Pressure, Expired Minute Volume and Mean 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 12 页 - - - - - - - - - Airway Pressure. The settings on the ventilator are also of interest to medical staff. The most typical settings we vechosen are Inspiratory Tidal Volume, Minute Volume, O2 Concentration, I:E Ratio, Breath Duration and Inspiratory Flow. Similarly we have chosen some common parameters for Vital Signs Monitors. These are Respiratory Rate, Non Invasive Blood Pressure, SPO2 and Temperature. The third device we selected parameters for is the Unfusion Pump. The common parameters we are most interested in here are Volume, Time, Ramp and Occlusion Pressure. Further parameters can be easily added to the system in the future. E. Bandwidth For development purposes we analysed a Maquet Servo-I 14 which supports all the ventilator parameters described above. This ventilator works in a command response manner.When initial configuration has taken place 2 commands which are 7 bytes long each will produce 2 responses of 67 bytes each. Therefore even in a multi hop mesh network it is anticipated we would be able to support several of these devices plus other types of devices on the same 802.15.4 channel. 第29届IEEE EMBS 国际程序会议城市法国 里昂2007年8月23日至27日应用紫蜂技术将医疗器械一体化摘要：无线电技术能够使医疗设备，例如生命体征监视器，呼吸设备以及输液泵做到重要数据的收集。这篇论文讨论了使用无线电传感器联网技术使数据从这些形式的医疗设备中被整合到医用系统中。通过集成设备，你可以保护投资和开发网络技术应用到类似设备的可行性。在这样的背景下，我们讨论怎样使“紫蜂”技术满足我们对于宽带，能源，安全性和移动性的要求。我们已经检验了各种设备的数据总处理能力，要求的数据频率，病人的安全性数据，以及当流动病人连接到设备后的后勤服务。这篇论文描述了一项全新的测试成果，这项成果能够使数据被准确无误的集成到用户界面或者医疗信息系统（ HIS）. 这项设计支持动态的增加新的医疗设备到过去并不支持的系统。为了达到这样的目的，硬件设计被保持原样，软件设计对于不同形式的医疗设备的代码被很好的重新定义。这些设备还可以共享无线电资源，通过其他形式正在开发的传感器，来结合到此项目，例如无线电心电图和脉冲血氧测定传感器。关键字：生物医学遥测医疗设备生物信息学无线传感器网络医疗信息系统引言当前在医院的病房里，重症监护病房，或者其他的临床设置于病床边的医疗设备都有数据输出功能的串行端口和其他类型的接口，如USB接口。这些设备经常是被认为具有重要意义的投资，而且当资金到位时经常是被作为需求以一种特别流行的方式来购买。这样的结果就是从不同制造商购买的设备不能够支持任何的标准协议。这样就会使整合这些设备到一个信号网络变得困难。在医院病房有许多不同品牌的生命体征监视器，呼吸设备以及输液泵，从一个病人到另一个病人通常需要有便携性以及可移动性。通过联网这些设备，医院获得了有所的优点，将病人数据集中储存在电子记录。通过使用设备的部分无线电传感器网络，例如“紫蜂”技术网络技术，可以包含更多的优点：电缆更换，移动性和位置管理。一旦这些设备是可以联网的，他们也能够在同一环境中使用其他的基础设施类似无线电传感器。为了获得这种类型的解决方案，每种设备必须被匹配到一块硬件中，做为一个串行的无限网桥即医疗设名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 12 页 - - - - - - - - - 备接口。 mdi 将会允许设备通过无线传感器网络来接受和发送数据。这种低成本的硬件将是通用的，以适用于广泛的医疗设备。类似的固件可以保持通用而且任何特定的设备通信协议能够在服务器上网络上的后端得到执行。本篇论文描述的工作是大项目中的一部分，其目标是提供完整的病人监护系统。其他功能的整体系统将提供心电图（心电图）和脉冲血氧测定法的数据，通过创新的方式，在无线传感器网络知识获得优先的项目。二 相关工作使用无线传感器网络的医疗服务和无线病人监测的观念一直被别人探索着，但是将数据从其他装置进行整合通常不被讨论。目前正在进行的有关病人监护仪的工作，例如使用无线传感器如“ CodeBlue ”项目在哈佛大学 3 开展。其他人同样也成功地使用无线传感器网络设计的医疗传感器 4 和管理中的传感器数据 5 。它已被确定，这是可取的，通过无线方式使现有的医疗设备，提供生命体征数据，使用的技术，例如 ZigBee的 6 7 。本篇论文所描述的研究力图满足这些要求。使用无线传感器网络在医院进行了广泛的审查。此外，其他无线技术在相同频段，如IEEE 802.11 标准 8 ，已经被在医院一段使用时间 9 。三 需求分析A 无线技术无线应用的既定标准，如蓝牙 10 和IEEE 802.11 ，允许高速传输速率，但是代价是牺牲能耗，应用复杂性和成本。 ZigBee提供低成本，低功率的设备，可以互相交流和外面的世界。ZigBee 的自我形成和自我调整的网络架构让数据和控制信息从一个节点传输到另一个多个路径。这是在特别有用的在医院的墙壁干扰，和一般人的阻碍下，是一个重要问题。ZigBee 是基于 IEEE标准 802.15.4 11 无线电的硬件和软件规范。B 调动实用 ZigBee 功能的设备，支持睡眠模式。离线节点可以连接到一个网络中的大约30毫秒。唤醒一个沉睡的节点约需 15毫秒，因为没有进入的渠道和传输数据。如果要求是收集数据，那么该设备可以放置在省电模式节省大量的能源和提高电池寿命。在睡眠模式的ZigBee 芯片可以承担少 1.0uA 12 。这一点尤其重要，在医疗环境中，病人往往是在轮椅上移动的时候仍然被连接到医疗设备。C 角共存ZigBee 和IEEE802.11 工作在免许可证的工业科学医疗协会（ ISM ）的 2.4GHz频率频段 .IEEE802.11 已经广泛使用在医院，医院将鼓励通过ZigBee 解决方案促使在同一个环境中使用。但是必须注意，以避免干扰这些本论文所描述的两个相邻的技术文件，题为“共存的IEEE802.15.4 与其他系统工作在2.4GHz频带” 13 。通过选择一个适当的渠道，在一个简单的现场调查表现，这些问题可以很容易地避免。D 器件参数可以在呼吸机进行典型的读数如吸气潮气量，呼气潮气量，氧气浓度，呼吸速率，峰值压力，过期每分通气量和平均气道压。医务人员对于仪器上的通风设备也感兴趣。我们已选择的最典型的设置是吸气潮气量，每分通气量，氧气浓度，I ： E 比值，呼吸时间和吸气流量。同样，我们选择了一些常见的参数，生命体征监测器。这些都是呼吸速率，无创血压，血氧饱和度和温度。第三个器件参数，我们选择的是传感频率泵。我们共同最感兴趣的参数是这里的工作量，时间，接线端扭和闭塞压力。进一步参数可以很容易地在后来添加到系统中。E 带宽我们分析了支持所有上述呼吸参数的Maquet Servo-I，发现已达到完善的目的。这种呼吸器工作在命令作反应方式。当初始配置发生改变，7字节长的两个命令，每个生产2答复每个 67字节。因此，即使是在一个多跳网状网，我们预期将能够支持一些这类设备加上其他类型的设备工作在同一802.15.4 频段。F. Scalability The ventilator, having the most parameters of the devicesstudied, requires the most bandwidth. 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 12 页 - - - - - - - - - Experiments carried outon a CSI Vital Signs Monitor 15 show that 44 bytes of data will produce all the information we are interested in. A BraunInfusion Pump 16 exports 24 bytes of data to produce the 4 parameters we need. For any of the medical devices we are concerned with, the readings are typically only required once aminute in a hospital environment. All these devices have their own alarm mechanisms built in; we are purely providing a means of exporting the data automatically. Theoretically a single Zigbee network could have above and beyond 600 Ventilators as each device only requires less than 1KB of bandwidth per minute. The frequency at which we capture the data is decided upon by the clinical staff themselves. A 1 minute interval is a typical value, however even if they were to require the data every few seconds it is clear the network could still support a large number of devices. IV. SYSTEM ARCHITECTURE A. High-Level Architecture The overall System Architecture consists of a Wireless Personal Area Network (WPAN) and a Local Area Network. The WPAN implemented as a Zigbee network communicates with the LAN via a gateway. This gateway also serves as the WPAN coordinator which is responsible for forming the network. Each medical device has a Zigbee node attached(MDI) which enables data to be transmitted wirelessly to the Gateway and then onto a Server existing on the LAN. See Fig. 1 below for a graphical representation of this. When an MDI is powered on it automatically joins the network and makes itself known to the Server. A user can then associate this device with a patient using a GUI client. Once an association has been completed the MDI will be notified to begin transmitting data. Data received by the server will be stored in the Electronic Health Record (EHR) for that patient and displayed on any GUI Client that is subscribed. Figure 1. High-Level Architecture B. Medical Device Interface The diagram in Fig. 2 below shows the key components of the MDI. The hardware comprises of a Zigbee module, a microcontroller and an RS 232 Interface. The microcontroller is responsible for interfacing with both the RS232 Interface and the Zigbee module. 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 12 页 - - - - - - - - - Figure 2. MDI Block Diagram When the MDI is powered on, the Zigbee stack will automatically join a Zigbee network within range. 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 in 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 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 is 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 responsible 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 which 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 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 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. 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 12 页 - - - - - - - - -