应用紫蜂技术将医疗器械一体化外文翻译(编辑修改稿)

应用紫蜂技术将医疗器械一体化外文翻译(编辑修改稿)内容摘要：

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 Architecture consists of a Wireless Personal Area Network (WPAN) and a Local Area Network. The WPAN implemented as a Zigbee work municates with the LAN via a gateway. This gateway also serves as the WPAN coordinator which is responsible for forming the work. 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 work 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 pleted 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. HighLevel Architecture B. Medical Device Interface The diagram in Fig. 2 below shows the key ponents of the MDI. The hardware prises 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. Figure 2. MDI Block Diagram When the MDI is powered on, the Zigbee stack will automatically join a Zigbee work 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 municate directly with the medical device the server will send any necessary mands 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 runtime and have a standard interface that each designer must adhere to in order to interoperate with the system. A designer must also plete 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. Figure 3. New Data 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 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 for a ventilator. When the timer expires the DLL retrieves the mand 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 event 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。