An automated medical center uses a variety of devices, the operation of which must be managed by a medical information system (MIS), as well as devices that do not accept commands but must transmit the results of their operation to the MIS. However, all devices have different connection options (USB, RS-232, Ethernet, etc.) and ways to interact with them. Supporting all of them in the MIS is practically impossible, which is why a software layer called DeviceManager (DM) was developed, providing the MIS with a unified interface for issuing tasks to devices and receiving results.
To increase the fault tolerance of the DM system, it was divided into a set of programs deployed on computers in the medical center. DM is split into a main program and a set of plugins that perform interaction with specific devices and send data to the MIS. The diagram below illustrates the generalized structure of interaction between DeviceManager, the MIS, and the devices.
The structure of interaction between the MIS and DeviceManager shows 3 modes of plugin operation:
- The plugin does not receive any data from the MIS and sends data from the device transformed into a format understandable to it (corresponds to device type 3 in the diagram above).
- The plugin receives a short (in execution time) task from the MIS, for example, printing on a printer or scanning an image, performs it, and sends the result in response to the request (corresponds to device type 1 in the diagram above).
- The plugin receives a long task from the MIS, for example, conducting an examination or measuring indicators, sends back a status of task acceptance (task acceptance may be denied in case of an error in the request). After completing the task, the results are transformed into a format understandable to the MIS and uploaded to the corresponding interfaces of its type (corresponds to device type 2 in the diagram above).
The main DM program starts, initializes, restarts in case of unexpected shutdown (failure), and finishes all plugins when the work is completed. The set of plugins on each computer is unique; only the necessary ones specified in the settings are launched.
Each plugin represents an independent program that interacts with the main program. This definition of a plugin ensures more stable operation due to the independence of all plugin instances and the main program in terms of error handling (if a critical error occurs causing a plugin to crash, it will not affect other plugins or the main program). One plugin allows working with devices of one type (often of one model); at the same time, some plugins may interact with only one device, while others can handle multiple devices. To connect several devices of the same type to one DM, multiple instances of one plugin are launched.
The DM was developed using the Qt toolkit because it allows for abstraction from specific operating systems in most cases. This enabled support for computers running Windows, Linux, and macOS, as well as Raspberry Pi single-board computers. The only limitation in choosing an operating system for plugin development is the availability of drivers and/or special software for a particular device.
Interaction between plugins and the main program occurs through a constantly active QLocalSocket with the name of the specific plugin instance, following the protocol we developed. The communication protocol implementation on both sides was designed as a dynamic library, allowing other companies to develop some plugins without fully revealing the interactions with the main program. The internal logic of the local socket allows the main program to immediately detect a failure by signaling a connection break. Upon receiving such a signal, the problematic plugin is restarted, which helps to more smoothly handle critical situations.
The interaction between the MIS and DM was decided to be based on the HTTP protocol since the MIS operates on the basis of Web servers, making it easier to send and receive requests using this protocol. There is also the possibility to distinguish problems that might arise during task assignment or execution by devices based on response codes.
In the following articles, the operation of the DM and some plugins will be discussed using examples from several diagnostic center offices.
Source: habr.com
