The difficulties in MDI lie in the data standards between heterogeneous devices as well as data acquisition modes. In order to allow different devices to achieve interconnection and interworking in a uniform data representation manner, there have some international standards such as HL7, DICOM, CDA, IHE, etc. Grounded upon the SOA technology, literature [1] and [2] put forward a data integration scheme. However, the scheme is dependent on the above standards, while these standards are not mandatory and are not underpinned by all manufacturers’ devices. For devices that are not based on standards, data integration remains difficult. Literature [3] presents the form of gateway to integrate medical devices, but similarly, data integration is still dependent on the standards, and the transceiver protocol between the gateway and the medical devices are all complex. Literature [4] only discussed the storage formats of medical device data, while most importantly, it has neglected the exploration of data collection. Literature [5] proposes a model of software dynamic evolution, which has some reference value for such application scenarios with rapidly changing demands like MDI.

The IoT technology refers to connect all objects by using the information sensing devices to the Internet for information exchange, which is exchanging of physical objects, in order to achieve intelligent identification and management. In this paper, the IoT technology is employed to identify and manage medical devices and the inspected patients.

The U.S. National Institute of Standards and Technology (NIST) defines cloud computing as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. In this paper, cloud computing serves as a filtering and storage carrier for data integration.

The dynamic evolution of software technology is an effective means to meet the open environment of the Internet and also the ever-changing needs of users [6]. It is also the core technology for autonomic computing, grid computing, adaptive software, and network configuration software.

Despite the diversity and heterogeneity of medical devices, focusing on the data integration problem, medical devices can be abstracted and classified by the data characteristics of the devices, and this is what the device abstraction layer does. At this layer, abstract modeling should be first built for the medical devices and the following model can be abstracted as per the data output type of devices:

MD = {standardized output devices, non-standard imaging devices, non-standard value devices}

Wherein, standardized output devices refer to standard devices that support standards such as HL7, DICOM, CDA, and IHE, and to integrate such devices, a number of existing mature schemes can be referred to. For non-standard devices, since they do not support a uniform standard, the data generated by the devices don’t have a fixed format, which causes a great difficulty to integrate. These devices are objects that this model focuses on, and such devices can be subdivided into imaging devices and numerical devices in this model [7].

The device adaptation layer is to resolve the association problem of the device and its functions. For a set of device, its function is to collect the inspection items that it can manage. There is a 1: n relationship between a device and an inspection item. In this paper, the device functions are used to build the model below:

MDF = {collection of inspection items, device type, communication mode}

Wherein, the device type is classified into three categories by the MD, while the corresponding communication mode may be any serial or Ethernet port. The MD and MDF are corresponded to complete the adaptation of medical devices.

A prerequisite for the integration of medical devices is that medical devices should be accessed to an intercommunicating network before acquiring data from them. The effect of the data extraction layer is firstly to provide networking capabilities to the device, and then submit the acquired device data to the next layer for processing. Meanwhile, a matching problem between the device data and the patients inspected should be addressed at this layer. Different from other parts, the realization of this layer’s functions should be combined with hardware.

Data acquired at the acquisition layer may be imaging reports, or formatting output of values. Some are standard while others are custom protocols by manufacturers, and the latter cannot be directly put into storage. It is indispensable to establish uniform rules to filter these data, and this is work at the data filtering layer. At this layer, the model builds a uniform protocol as the basis of data filtering and also the data storage format:

MDIDP = {inspection items, inspection end value, reference value, inspection conclusions}

The numerical results can be directly corresponded to each item in the protocol. For the imaging results, the storage location of imaging files is corresponding to the inspection end value in the protocol.

The device abstraction layer and the device adaptation layer are realized mainly through the OOP technology, which objectifies medical devices. As the definition model of medical devices in Section 2.1, the UML diagram can be applied to show the final realization class diagram.

The data abstraction layer is achieved mainly by using hardware MCU as a data gateway. For each set of medical device, there is MCU hardware to connect with it. According to the output type of medical devices, two connection types are available: RS232 or two RJ45. The design of MCU is based on the IoT technology [9]. MCU can have access to the LAN or the Internet through wireless means. Each MCU has a unique identification code. Therefore, medical devices gain the networking capabilities by docking MCU, while there is a one-to-one relationship between the device and the MCU. The identification of MCU can be used as the identification of the device in the network, and thus the IoT of medical devices has been set up [10].

The final inspection results of medical devices will be sent out via RS232 or RJ45. The docking MCU has special listening services. If there is data transmission, MCU will extract the data first and then transmit them to the cloud server. In order to quickly exchange data and reduce the burden on the MCU, MCU is only responsible for data extraction and forwarding, and not responsible for other calculations. MCU extracts data transmitted by the device from the communication layer, so it can be used universally by all of the medical devices. Further, it does not intrude into the medical devices, and thus data output by devices that do not support HL7, DICOM protocols, etc. can also be collected.

Fig. (2). UML diagram at the device layer.

Fig. (3). Structure map of the data acquisition layer.

Data obtained from medical devices should also be associated with detailed information of patients. For HL7, DICOM and other protocols, the messages themselves will carry patient information. However, it is impossible for non-standard imaging devices and non-standard numerical devices to transmit such data. As a consequence, the output results of these devices will easily be lead to mismatches and eventually turn into useless data. By integrating RFID, two-dimensional code recognition, barcode recognition and other functions on the MCU, information of patients inspected can be obtained [11]. Each time the MCU forwards the data to the cloud, it is triggered by recognizing patient information (swiping cards or scanning codes, etc.), thereby forming a two-tuples [pid, data] to be uploaded to the cloud layer and ensuring the data are always linked to the corresponding numbers of patients.

The final data exchange protocol MDIDP of this model is described in Section 2.4. As per the modeling of the device in Section 2.1, the data filtering layer will transform the protocols of the following three types of data:

Fig. (4). Structure map of the data filtering layer.

Fig. (5). The schematic diagram of system extensions.

1. For standard devices, the data filtering layer will analyze the packets of such protocols as HL7 and DICOM to obtain the desired fields.
2. For output of non-standard imaging devices, the data filtering layer will take the storage path of the image files as the inspection end value.
3. The output of non-standard value devices does not have a standard and unified data format. Each manufacturer has their definition of the output data. Confronting with such a changing and heterogeneous scene, the data filtering layer is realized through the dynamic evolution of software technology. First of all, the data standards of these manufacturers are expressed regularly. Afterward, by reflection, regular matching is conducted on these data in the implementation phase and eventually the corresponding data are obtained.