【正文】 vent 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 DLL as shown in Fig. 4 above. If the DLL does not receive any data within a specified timeout period the DLL will reinitiate munication with the medical device. Data that is received by the DLL is checked to see 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 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 extended to integrate with existing hospital systems using HL7 [17] or another uniform interface that is designed specifically for wireless sensor works could be used such as that developed by DERI [18]. V. LABORATORY RESULTS The architecture described here has been implemented and tested successfully in a laboratory environment. For this purpose we connected the MDI to a PC simulator designed to act as a Maquet Servoi ventilator. The Maquet ventilator can return breath readings and settings. To capture these, the SDADB and SDADS Maquet mands are sent to specify which breath readings and settings we wish to retrieve. Then by sending the RADAB and RADAS mands periodically we can capture up to date information from the . 6 shows the simulator handling these mands at runtime. Figure 6. Ventilator Simulator As described in the Architecture the Server DLL maintains a state for each end device so it knows what information to expect in return. In our experiments we successfully retrieved ventilator data at 5 second intervals. We have designed a GUI client which we successfully subscribed to receive this ventilator data. We are collaborating with a local hospital that use the Maquet ventilator and their requirement is data collection at 1 minute intervals. These results are very positive prior to usability tests in the hospital with the actual ventilator. We also performed a limited amount of range testing in the laboratory. We achieved a range of 20m within the confines of the laboratory which would equate to the maximum distance between an end device and a router in the hospital. In addition we carried out some mobility testing by moving the MDI during operation which did not result in any packet loss. Initial results are positive but further extensive testing is needed which will be performed in the hospital environment. VI. CONCLUSION In this paper we have shown that a Wireless Sensor Network is a suitable means for capturing data from a medical device. We have discussed how Zigbee meets our requirements in terms of data throughput, power and mobility. Moreover, using this technology we can develop a low cost, scalable solution for a wide range of medical devices. In addition we have an infrastructure that allows us to easily support new devices within the system as needed. This architecture facilitates moving the device data to third party systems and to our own User Interface. We hope that our field trials will result in positive feedback from the clinical staff. 第 29 屆 IEEE EMIEE 國際程序會議 城市 法國 里昂 2020 年 8 月 23 日至 27 日 應(yīng)用紫蜂技術(shù)將醫(yī)療器械一體化 摘要： 無線電技術(shù)能夠使醫(yī)療設(shè)備，例如生命體征監(jiān)視器，呼吸設(shè)備以及輸液泵做到重要數(shù)據(jù)的收集。 Proceedings of the 29th Annual International Conference of the IEEE EMBS Cit233。 we are purely providing a means of exporting the data automatically. Theoretically a single Zigbee work 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 work could still support a large number of devices. IV. SYSTEM ARCHITECTURE A. HighLevel Architecture The overall System A