In an automated medical center, many different devices are used, the operation of which must be controlled by a medical information system (HIS), as well as devices that do not receive commands, but must transmit the results of their work to the HIS. 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, so the DeviceManager (DM) software layer 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, DM was divided into a set of programs placed on computers in the medical center. DM is divided into a main 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 HIS interaction with DeviceManager shows 3 options for plug-ins:
- The plug-in does not receive any data from the MIS and sends the data converted into a format understandable for it from the device (corresponds to the type 3 device in the figure above).
- The plugin receives a short task (in terms of execution time) from the MIS, for example, printing on a printer or scanning an image, executes it and sends the result in response to a request (corresponds to type 1 device in the figure above).
- The plug-in receives a long-term task from the MIS, for example, to conduct a survey or measure indicators, in response it sends the task acceptance status (the task may be denied if the request is incorrect). After the task is completed, the results are converted into a format understandable for the MIS and uploaded to the interfaces corresponding to their type (corresponds to the type 2 device in the figure above).
The DM head program launches, initializes, restarts in case of an unexpected stop (crash) and terminates all plug-ins upon shutdown. The composition of the plug-ins on each computer is different, only the necessary ones are launched, which are specified in the settings.
Each plug-in is an independent program that interacts with the main program. This plugin definition allows for more stable operation, due to the independence of all plugin instances and the head in terms of error handling (if a critical error occurs, due to which the plugin crashed, then this will not affect other plugins and the head). One plugin allows you to work with devices of the same type (often of the same model), while some plugins can interact with only one device, while others can interact with several. To connect several devices of the same type to one DM, launching several instances of the same plug-in is used.
For the development of the DM, the Qt toolkit was used, because it allows you to abstract from a specific operating system in most cases. This made it possible to support work with computers based on Windows, Linux and MacOS, as well as single-board Raspberry. The only limitation in choosing an operating system when developing plug-ins is the availability of drivers and / or special software for a particular device.
Interaction between plugins and the head occurs through a constantly active QLocalSocket with the name of a specific plugin instance, according to the protocol we created. The implementation of the communication protocol on both sides was framed as a dynamic library, which allowed other companies to develop some plug-ins without fully revealing the interaction with the head. The internal logic of the local socket allows the head to immediately know about the fall using the connection disconnect signal. When such a signal is triggered, the problematic 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 based on the HTTP protocol, since MIS operates 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 by devices based on response codes.
In the following articles, using the example of several rooms of the diagnostic center, the work of DM and some plug-ins will be considered.
Source: habr.com