Device Manager Extend MIS to devices
The automated medical center uses many different devices, the work of which must be controlled by the medical information system (MIS), as well as devices that do not accept commands, but must transmit the results of their work to the MIS. However, all devices have different connection options (USB, RS-232, Ethernet, etc.) and ways to interact with them. It is almost impossible to support all of them in the MIS, therefore, the software layer DeviceManager (DM) was developed, which provides the MIS with a single interface for setting tasks for devices and obtaining results.
To increase the fault tolerance of the system, the DM was divided into a set of programs hosted on computers in the medical center. DM is divided into the host program and a set of plug-ins that interact with a specific device and send data to the MIS. The figure below shows a generalized structure of interaction with DeviceManager, MIS and devices.
The structure of the interaction of MIS with DeviceManager shows 3 options for working with plugins:
- The plugin does not receive any data from the MIS and sends the data converted to a format that is understandable to it from the device (corresponds to a type 3 device in the figure above).
- The plug-in receives from the MIS a short task (in terms of execution time), for example, printing on a printer or scanning an image, performs it and sends the result in response to a request (corresponds to type 1 device in the figure above).
- The plugin receives a lengthy task from the IIA, for example, to conduct a survey or measure indicators, in response sends the status of the acceptance of the task (the statement of the problem may be refused if the request is incorrect). After the task is completed, the results are converted into a format that is understandable to the MIS and uploaded to the appropriate type of interfaces (corresponds to a type 2 device in the figure above).
The DM head program starts, initializes, restarts in the event of an unexpected stop (crash), and terminates all plugins upon completion of work. The composition of the plug-ins on each computer is different, only the necessary ones that are specified in the settings are launched.
Each plug-in is an independent program that interacts with the host program. Such a definition of the plug-in allows for more stable operation, due to the independence of all instances of the plug-ins and the head in terms of error handling (if a critical error occurs due to which the plug-in crashes, this will not affect other plug-ins). One plug-in allows you to work with devices of the same type (often of the same model), while some plug-ins can interact with only one device, and others with several. To connect several devices of the same type to one DM, the launch of several instances of the same plugin is used.
The Qt toolkit was used to develop the DM, because it allows in most cases to abstract from a specific operating system. This made it possible to support work with computers based on Windows, Linux and MacOS, as well as Raspberry single-board computers. The only limitation in choosing an operating system when developing plugins is the presence of drivers and / or special software for a particular device.
The interaction between the plugins and the head occurs through the constantly active QLocalSocket with the name of a specific instance of the plugin, according to the protocol we created. The implementation of the communication protocol on both sides was framed in the form of a dynamic library, which allowed the development of some plugins by other companies, without fully disclosing the interaction with the head. The internal logic of the local socket allows the head to immediately know about the fall using a connection break signal. When such a signal is triggered, the problem plug-in is restarted, which makes it possible to handle critical situations more painlessly.
It was decided to build the interaction between MIS and DM on the basis of the HTTP protocol, since the MIS works on the basis of a Web server, in which it is easier to send and receive requests using this protocol. It is also possible to distinguish between problems that could arise when setting or performing tasks with devices based on response codes.
In the following articles, as an example of several rooms of the diagnostic center, the operation of DM and some plug-ins will be considered.