El centro médico automatizado utiliza muchos dispositivos diferentes, cuyo trabajo debe ser controlado por el sistema de información médica (MIS), así como dispositivos que no aceptan comandos, pero deben transmitir los resultados de su trabajo al MIS. Sin embargo, todos los dispositivos tienen diferentes opciones de conexión (USB, RS-232, Ethernet, etc.) y formas de interactuar con ellos. Es casi imposible admitirlos a todos en el MIS, por lo tanto, se desarrolló la capa de software DeviceManager (DM), que proporciona al MIS una única interfaz para configurar tareas para dispositivos y obtener resultados.
Para aumentar la tolerancia a fallas del sistema, el DM se dividió en un conjunto de programas alojados en computadoras en el centro médico. DM se divide en el programa host y un conjunto de complementos que interactúan con un dispositivo específico y envían datos al MIS. La siguiente figura muestra una estructura generalizada de interacción con DeviceManager, MIS y dispositivos.
La estructura de la interacción de MIS con DeviceManager muestra 3 opciones para trabajar con complementos:
- El complemento no recibe ningún dato del MIS y envía los datos convertidos a un formato que le sea comprensible desde el dispositivo (corresponde a un dispositivo tipo 3 en la figura anterior).
- El complemento recibe del MIS una tarea corta (en términos de tiempo de ejecución), por ejemplo, imprimir en una impresora o escanear una imagen, la realiza y envía el resultado en respuesta a una solicitud (corresponde al dispositivo de tipo 1 en la figura anterior).
- El complemento recibe una tarea a largo plazo del IIA, por ejemplo, para realizar una encuesta o medir indicadores, en respuesta envía el estado de aceptación de la tarea (la declaración del problema puede ser rechazada si la solicitud es incorrecta). Una vez completada la tarea, los resultados se convierten a un formato que sea comprensible para el MIS y se cargan en el tipo de interfaces apropiado (corresponde a un dispositivo de tipo 2 en la figura anterior).
El programa principal de DM se inicia, se inicializa, se reinicia en caso de una parada inesperada (bloqueo) y finaliza todos los complementos al finalizar el trabajo. La composición de los complementos en cada computadora es diferente, solo se inician los necesarios que se especifican en la configuración.
Cada complemento es un programa independiente que interactúa con el programa host. Dicha definición del complemento permite un funcionamiento más estable, debido a la independencia de todas las instancias de los complementos y del cabezal en términos de manejo de errores (si se produce un error crítico debido al cual el complemento se bloquea, esto no afectará a otros complementos). Un complemento le permite trabajar con dispositivos del mismo tipo (a menudo del mismo modelo), mientras que algunos complementos pueden interactuar con un solo dispositivo y otros con varios. Para conectar varios dispositivos del mismo tipo a un DM, se utiliza el lanzamiento de varias instancias del mismo complemento.
El kit de herramientas Qt se utilizó para desarrollar el DM, ya que permite, en la mayoría de los casos, abstraerse de un sistema operativo específico. Esto hizo posible soportar el trabajo con computadoras basadas en Windows, Linux y MacOS, así como con computadoras de una sola placa Raspberry. La única limitación para elegir un sistema operativo cuando se desarrollan complementos es la presencia de controladores y / o software especial para un dispositivo en particular.
La interacción entre los complementos y la cabeza se produce a través del QLocalSocket constantemente activo con el nombre de una instancia específica del complemento, de acuerdo con el protocolo que creamos. La implementación del protocolo de comunicación en ambos lados se enmarcó en la forma de una biblioteca dinámica, que permitió el desarrollo de algunos complementos por parte de otras compañías, sin revelar completamente la interacción con el jefe. La lógica interna del zócalo local permite que la cabeza sepa de inmediato sobre la caída utilizando una señal de interrupción de conexión. Cuando se activa dicha señal, el complemento del problema se reinicia, lo que hace posible manejar situaciones críticas de manera más sencilla.
Se decidió construir la interacción entre MIS y DM sobre la base del protocolo HTTP, ya que el MIS funciona sobre la base de un servidor web, en el que es más fácil enviar y recibir solicitudes utilizando este protocolo. También es posible distinguir entre los problemas que pueden surgir al configurar o realizar tareas con dispositivos basados en códigos de respuesta.
En los siguientes artículos, como ejemplo de varias salas del centro de diagnóstico, se considerará el funcionamiento de DM y algunos complementos.