Device Manager. Extend IIA to devices

The automated medical center uses many different devices, the work of which should be managed by the medical information system (IIA), as well as devices that do not accept commands, but must transfer the results of their work to the IIA. However, all devices have different connectivity options (USB, RS-232, Ethernet, etc.) and how to interact with them. It’s almost impossible to support them all in an MIS, so the DeviceManager (DM) software layer was developed, which provides a single interface for MIS to set tasks for devices and get results.


To increase the fault tolerance of the system, the DM was divided into a set of programs hosted on computers in a medical center. DM is divided into the head program and a set of plug-ins that interact with a specific device and send data to the IIA. The figure below shows a generalized structure of interaction with the DeviceManager, the IIA and devices.


On the structure of the interaction of MIS with DeviceManager, 3 variants of plug-in operation are shown:

1. The plugin does not receive any data from the MIS and sends the data converted into its clear format from the device (corresponds to the device type 3 in the figure above).
2. The plugin receives a short (in terms of execution) task from the MIS, for example, printing on a printer or scanning an image, performs it and sends the result in response to a request (corresponds to the device type 1 in the figure above).
3. The plugin 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 (in the formulation of the task it can be refused if the request fails). After the task is completed, the results are converted into a format understandable for the MIS and are uploaded to the appropriate interfaces for their type (corresponds to the device type 2 in the figure above).

The DM head program starts, initializes, restarts in case of an unexpected stop (crash) and terminates all plugins on completion. The composition of plug-ins on each computer is its own, only the necessary ones that are specified in the settings are launched.
')
Each plugin is an independent program that interacts with the head program. Such a definition of a plug-in allows for more stable operation, due to the independence of all instances of plug-ins and the head in terms of error handling (if a critical error has occurred, due to which the plug-in fell, then other plug-ins and the head will not be affected). One plug-in allows you to work with devices of the same type (often one model), with some plug-ins can interact with only one device, and others - with several. To connect several devices of the same type to the same DM, launch multiple instances of the same plug-in.


The Qt toolkit was used for developing DM, because in most cases it allows abstracting 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 the operating system when developing plug-ins is the presence of drivers and / or special software for a specific device.

The interaction between the plugins and the head occurs through a constantly active QLocalSocket with the name of the specific instance of the plug-in, according to the protocol we created. The implementation of the communication protocol on both sides was framed as a dynamic library, which allowed the development of some plug-ins by other companies, without fully revealing the interaction with the head. The internal logic of the local socket allows the head to immediately learn about the fall using the signal to break the connection. When such a signal is triggered, the problematic plug-in is restarted, which allows you to handle critical situations more painlessly.

The interaction between the MIS and DM was decided to build on the basis of the HTTP protocol, since the 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 with devices based on response codes.

In the following articles, the work of the DM and some plug-ins will be considered on the example of several cabinets of the diagnostic center.