En el centro médico automatizado se utilizan numerosos dispositivos diferentes, cuyo funcionamiento debe ser gestionado por el sistema de información médica (SIM), así como dispositivos que no reciben órdenes, pero deben transmitir los resultados de su trabajo al SIM. Sin embargo, todos los dispositivos tienen diferentes opciones de conexión (USB, RS-232, Ethernet, etc.) y modos de interacción con ellos. Mantener todos ellos en el SIM es prácticamente imposible, por lo que se desarrolló una capa de software llamada DeviceManager (DM), que proporciona al SIM una interfaz única para asignar tareas a los dispositivos y recibir los resultados.
Para aumentar la resiliencia del sistema DM, se dividió en un conjunto de programas que se alojan en las computadoras del centro médico. DM se compone de un programa principal y un conjunto de plugins que realizan la interacción con un dispositivo específico y envían datos al SIM. En la imagen a continuación se presenta la estructura general de interacción con DeviceManager, el SIM y los dispositivos.
En la estructura de interacción del SIM con DeviceManager se muestran 3 variantes de funcionamiento de los plugins:
- El plugin no recibe ningún dato del SIM y envía datos del dispositivo transformados a un formato comprensible para él (corresponde al dispositivo tipo 3 en la imagen anterior).
- El plugin recibe del SIM una tarea corta (en tiempo de ejecución), por ejemplo, imprimir en una impresora o escanear una imagen, la ejecuta y envía el resultado en respuesta a la solicitud (corresponde al dispositivo tipo 1 en la imagen anterior).
- El plugin recibe del SIM una tarea de larga duración, por ejemplo, realizar un examen o medir indicadores, y responde enviando el estado de aceptación de la tarea (puede rechazarse la asignación en caso de error en la solicitud). Después de completar la tarea, los resultados se transforman a un formato comprensible para el SIM y se descargan en las interfaces correspondientes a su tipo (corresponde al dispositivo tipo 2 en la imagen anterior).
El programa principal de DM inicia, inicializa, reinicia en caso de parada inesperada (caída) y finaliza todos los plugins al concluir el trabajo. La composición de los plugins en cada computadora es específica, y solo se inician los necesarios, los cuales están indicados en la configuración.
Cada complemento es un programa independiente que interactúa con el programa principal. Esta definición de complemento permite una operación más estable, gracias a la independencia de todas las instancias de complementos y el sistema principal en términos de manejo de errores (si se produce un error crítico que provoca el fallo de un complemento, esto no afectará a otros complementos ni al sistema principal). Un complemento permite trabajar con dispositivos de un mismo tipo (a menudo de un mismo modelo), mientras que algunos complementos pueden interactuar solo con un dispositivo, y otros con varios. Para conectar varios dispositivos de un tipo a un solo DM se utiliza el lanzamiento de varias instancias de un complemento.
Para desarrollar el DM se utilizó la herramienta Qt, ya que permite, en la mayoría de los casos, abstraerse del sistema operativo específico. Esto permitió soportar la operación con computadoras basadas en Windows, Linux y MacOS, así como con microcontroladores Raspberry. La única limitación en la elección del sistema operativo al desarrollar complementos es la disponibilidad de controladores y/o software especial para un dispositivo específico.
La interacción entre los complementos y el sistema principal se realiza a través de un QLocalSocket siempre activo con el nombre de la instancia específica del complemento, utilizando el protocolo que desarrollamos. La implementación del protocolo de comunicación por ambas partes se realizó en forma de una biblioteca dinámica, lo que permitió que algunas empresas desarrollaran ciertos complementos sin revelar completamente la interacción con el sistema principal. La lógica interna del funcionamiento del socket local permite al sistema principal enterarse inmediatamente de un fallo mediante una señal de desconexión. Al activarse esta señal, se reinicia el complemento problemático, lo que permite manejar las situaciones críticas de manera más suave.
Se decidió construir la interacción entre el MIS y el DM sobre la base del protocolo HTTP, ya que el MIS funciona sobre Servidores web, en el cual es más sencillo enviar y recibir solicitudes mediante este protocolo. También existe la posibilidad de distinguir problemas que podrían surgir al establecer o ejecutar tareas con los dispositivos basándose en los códigos de respuesta.
En los siguientes artículos se examinará el funcionamiento del DM y algunos complementos, utilizando como ejemplo varios consultorios de un centro de diagnóstico.
Fuente: habr.com
