Le centre médical automatisé utilise de nombreux appareils différents, dont le travail doit être contrôlé par le système d'information médicale (MIS), ainsi que des appareils qui n'acceptent pas de commandes, mais doivent transmettre les résultats de leur travail au MIS. Cependant, tous les appareils ont différentes options de connexion (USB, RS-232, Ethernet, etc.) et des façons d'interagir avec eux. Il est presque impossible de les prendre en charge tous dans le MIS, par conséquent, la couche logicielle DeviceManager (DM) a été développée, qui fournit au MIS une interface unique pour définir les tâches des périphériques et obtenir des résultats.
Pour augmenter la tolérance aux pannes du système, le DM a été divisé en un ensemble de programmes hébergés sur des ordinateurs dans le centre médical. DM est divisé en programme hôte et en un ensemble de plug-ins qui interagissent avec un appareil spécifique et envoient des données au MIS. La figure ci-dessous montre une structure généralisée d'interaction avec DeviceManager, MIS et les appareils.
La structure de l'interaction de MIS avec DeviceManager montre 3 options pour travailler avec des plugins:
- Le plugin ne reçoit aucune donnée du MIS et envoie les données converties dans un format qui lui est compréhensible depuis l'appareil (correspond à un appareil de type 3 dans la figure ci-dessus).
- Le plug-in reçoit du MIS une courte tâche (en termes de temps d'exécution), par exemple, imprimer sur une imprimante ou numériser une image, l'exécute et envoie le résultat en réponse à une demande (correspond au périphérique de type 1 dans la figure ci-dessus).
- Le plugin reçoit une longue tâche de l'IIA, par exemple, pour mener une enquête ou mesurer des indicateurs, en réponse envoie le statut d'acceptation de la tâche (l'énoncé du problème peut être refusé si la demande est incorrecte). Une fois la tâche terminée, les résultats sont convertis dans un format compréhensible pour le MIS et téléchargés vers le type d'interface approprié (correspond à un périphérique de type 2 dans la figure ci-dessus).
Le programme DM head démarre, initialise, redémarre en cas d'arrêt inattendu (crash) et termine tous les plugins à la fin du travail. La composition des plug-ins sur chaque ordinateur est différente, seuls ceux nécessaires qui sont spécifiés dans les paramètres sont lancés.
Chaque plug-in est un programme indépendant qui interagit avec le programme hôte. Une telle définition du plug-in permet un fonctionnement plus stable, en raison de l'indépendance de toutes les instances des plug-ins et de la tête en termes de gestion des erreurs (si une erreur critique se produit à cause de laquelle le plug-in se bloque, cela n'affectera pas les autres plug-ins). Un plug-in vous permet de travailler avec des appareils du même type (souvent du même modèle), tandis que certains plug-ins peuvent interagir avec un seul appareil et d'autres avec plusieurs. Pour connecter plusieurs appareils du même type à un DM, le lancement de plusieurs instances du même plugin est utilisé.
La boîte à outils Qt a été utilisée pour développer le DM, car elle permet dans la plupart des cas d'abstraire d'un système d'exploitation spécifique. Cela a permis de prendre en charge le travail avec des ordinateurs basés sur Windows, Linux et MacOS, ainsi qu'avec des ordinateurs à carte unique Raspberry. La seule limitation dans le choix d'un système d'exploitation lors du développement de plugins est la présence de pilotes et / ou de logiciels spéciaux pour un périphérique particulier.
L'interaction entre les plugins et la tête se produit via le QLocalSocket constamment actif avec le nom d'une instance spécifique du plugin, selon le protocole que nous avons créé. La mise en œuvre du protocole de communication des deux côtés a été encadrée sous la forme d'une bibliothèque dynamique, qui a permis le développement de certains plugins par d'autres sociétés, sans divulguer pleinement l'interaction avec la tête. La logique interne de la prise locale permet à la tête de connaître immédiatement la chute à l'aide d'un signal de rupture de connexion. Lorsqu'un tel signal est déclenché, le plug-in de problème est redémarré, ce qui permet de gérer les situations critiques sans douleur.
Il a été décidé de construire l'interaction entre MIS et DM sur la base du protocole HTTP, car le MIS fonctionne sur la base d'un serveur Web, dans lequel il est plus facile d'envoyer et de recevoir des demandes en utilisant ce protocole. Il est également possible de distinguer les problèmes pouvant survenir lors de la définition ou de l'exécution de tâches avec des appareils en fonction des codes de réponse.
Dans les articles suivants, à titre d'exemple de plusieurs salles du centre de diagnostic, le fonctionnement de DM et de certains plug-ins sera pris en compte.