Um centro médico automatizado utiliza diversos dispositivos, cujo funcionamento deve ser controlado por um sistema de informação médica (MIS), bem como dispositivos que não aceitam comandos, mas devem transmitir os resultados de seu trabalho ao MIS. Porém, todos os dispositivos possuem diferentes opções de conexão (USB, RS-232, Ethernet, etc.) e formas de interagir com eles. É quase impossível suportar todos eles no MIS, por isso foi desenvolvida a camada de software DeviceManager (DM), que fornece uma interface única para o MIS atribuir tarefas aos dispositivos e obter resultados.
Para aumentar a tolerância a falhas do sistema, o DM foi dividido em um conjunto de programas localizados nos computadores do centro médico. O DM é dividido em um programa principal e um conjunto de plugins que interagem com um dispositivo específico e enviam dados para o MIS. A figura abaixo mostra uma estrutura generalizada de interação com DeviceManager, MIS e dispositivos.
A estrutura de interação entre MIS e DeviceManager mostra 3 opções de plug-ins:
- O plugin não recebe nenhum dado do MIS e envia dados convertidos em um formato compreensível para ele a partir do dispositivo (corresponde ao tipo de dispositivo 3 na figura acima).
- O plugin recebe uma tarefa curta (em termos de tempo de execução) do MIS, por exemplo, imprimir em uma impressora ou digitalizar uma imagem, executa-a e envia o resultado em resposta à solicitação (corresponde ao tipo de dispositivo 1 na figura acima ).
- O plugin recebe do MIS uma tarefa de longo prazo, por exemplo, para realizar uma pesquisa ou medir indicadores, e em resposta envia o status de aceitação da tarefa (a tarefa pode ser recusada caso haja erro na solicitação). Após a conclusão da tarefa, os resultados são convertidos em um formato compreensível para o MIS e carregados nas interfaces correspondentes ao seu tipo (corresponde ao dispositivo tipo 2 na figura acima).
O programa DM principal inicia, inicializa, reinicia em caso de parada inesperada (travamento) e encerra todos os plugins quando desligado. A composição dos plugins em cada computador é diferente; apenas são lançados os necessários, que estão especificados nas configurações.
Cada plugin é um programa independente que interage com o programa principal. Esta definição de plug-in permite uma operação mais estável devido à independência de todas as instâncias do plug-in e do cabeçote em termos de tratamento de erros (se ocorrer um erro crítico que cause o travamento do plug-in, isso não afetará outros plug-ins e o cabeçote) . Um plugin permite que você trabalhe com dispositivos de um tipo (geralmente do mesmo modelo), enquanto alguns plugins podem interagir apenas com um dispositivo, enquanto outros podem interagir com vários. Para conectar vários dispositivos do mesmo tipo a um DM, inicie várias instâncias do mesmo plugin.
O kit de ferramentas Qt foi usado para desenvolver o DM porque nos permite abstrair de um sistema operacional específico na maioria dos casos. Isso possibilitou o trabalho com computadores baseados em Windows, Linux e MacOS, bem como dispositivos de placa única Raspberry. A única limitação na escolha de um sistema operacional no desenvolvimento de plugins é a disponibilidade de drivers e/ou software especial para um dispositivo específico.
A interação entre os plugins e o head ocorre através de um QLocalSocket constantemente ativo com o nome de uma instância específica do plugin, de acordo com o protocolo que criamos. A implementação do protocolo de comunicação em ambos os lados foi desenhada como uma biblioteca dinâmica, o que possibilitou o desenvolvimento de alguns plugins de outras empresas sem revelar completamente a interação com o responsável. A lógica interna do soquete local permite que o cabeçote aprenda imediatamente sobre a queda usando um sinal de interrupção de conexão. Quando tal sinal é acionado, o plugin problemático é reiniciado, o que permite lidar com situações críticas de maneira mais fácil.
Optou-se por construir a interação entre MIS e DM baseada no protocolo HTTP, uma vez que o MIS opera em um servidor Web, o que facilita o envio e recebimento de solicitações por meio deste protocolo. Também é possível distinguir problemas que podem surgir ao definir ou executar tarefas com dispositivos baseados em códigos de resposta.
Nos artigos seguintes, a partir do exemplo de diversas salas de centros de diagnóstico, será examinado o funcionamento do DM e de alguns plug-ins.
Fonte: habr.com