O centro médico automatizado usa muitos dispositivos diferentes, cujo trabalho deve ser controlado pelo sistema de informações médicas (MIS), bem como dispositivos que não aceitam comandos, mas devem transmitir os resultados de seu trabalho ao MIS. No entanto, todos os dispositivos têm opções de conexão diferentes (USB, RS-232, Ethernet etc.) e maneiras de interagir com eles. É quase impossível oferecer suporte a todos eles no MIS; portanto, foi desenvolvida a camada de software DeviceManager (DM), que fornece ao MIS uma interface única para definir tarefas para dispositivos e obter resultados.
Para aumentar a tolerância a falhas do sistema, o DM foi dividido em um conjunto de programas hospedados em computadores no centro médico. O DM é dividido no programa host e em um conjunto de plug-ins que interagem com um dispositivo específico e enviam dados ao MIS. A figura abaixo mostra uma estrutura generalizada de interação com o DeviceManager, MIS e dispositivos.
A estrutura da interação do MIS com o DeviceManager mostra três opções para trabalhar com plugins:
- O plug-in não recebe dados do MIS e envia os dados convertidos para um formato compreensível para ele a partir do dispositivo (corresponde a um dispositivo tipo 3 na figura acima).
- O plug-in recebe do MIS uma tarefa curta (em termos de tempo de execução), por exemplo, imprimir em uma impressora ou digitalizar uma imagem, executa-a e envia o resultado em resposta a uma solicitação (corresponde ao dispositivo do tipo 1 na figura acima).
- O plug-in recebe uma tarefa de longo prazo do IIA, por exemplo, para realizar uma pesquisa ou medir indicadores, em resposta envia o status de aceitação da tarefa (a declaração do problema pode ser recusada se a solicitação estiver incorreta). Após a conclusão da tarefa, os resultados são convertidos em um formato compreensível para o MIS e carregados no tipo de interface apropriado (corresponde a um dispositivo do tipo 2 na figura acima).
O programa principal do DM inicia, inicializa, reinicia em caso de uma parada inesperada (falha) e encerra todos os plugins após a conclusão do trabalho. A composição dos plug-ins em cada computador é diferente, apenas os necessários especificados nas configurações são iniciados.
Cada plug-in é um programa independente que interage com o programa host. Essa definição do plug-in permite uma operação mais estável, devido à independência de todas as instâncias dos plug-ins e da cabeça em termos de tratamento de erros (se ocorrer um erro crítico devido ao qual o plug-in trava, isso não afetará outros plug-ins). Um plug-in permite trabalhar com dispositivos do mesmo tipo (geralmente do mesmo modelo), enquanto alguns plug-ins podem interagir com apenas um dispositivo e outros com vários. Para conectar vários dispositivos do mesmo tipo a um DM, use o lançamento de várias instâncias do mesmo plug-in.
O kit de ferramentas Qt foi usado para desenvolver o DM, porque na maioria dos casos permite abstrair de um sistema operacional específico. Isso possibilitou o suporte ao trabalho com computadores baseados em Windows, Linux e MacOS, bem como computadores de placa única Raspberry. A única limitação na escolha de um sistema operacional ao desenvolver plug-ins é a presença de drivers e / ou software especial para um dispositivo específico.
A interação entre os plugins e a cabeça ocorre através do QLocalSocket constantemente ativo com o nome de uma instância específica do plug-in, de acordo com o protocolo que criamos. A implementação do protocolo de comunicação de ambos os lados foi estruturada na forma de uma biblioteca dinâmica, que permitiu o desenvolvimento de alguns plugins por outras empresas, sem divulgar totalmente a interação com o chefe. A lógica interna do soquete local permite que a cabeça saiba imediatamente sobre a queda usando um sinal de interrupção de conexão. Quando esse sinal é acionado, o plug-in com problema é reiniciado, o que torna possível lidar com situações críticas de maneira mais indolor.
Foi decidido construir a interação entre o MIS e o DM com base no protocolo HTTP, uma vez que o MIS trabalha com base em um servidor Web, no qual é mais fácil enviar e receber solicitações usando esse protocolo. Também é possível distinguir entre os problemas que podem surgir ao definir ou executar tarefas com dispositivos baseados em códigos de resposta.
Nos artigos a seguir, como exemplo de várias salas do centro de diagnóstico, a operação do DM e alguns plug-ins serão considerados.