In un centro medico automatizzato vengono utilizzati numerosi dispositivi diversi, il cui funzionamento deve essere gestito dal sistema informativo sanitario (MIS), e anche dispositivi che non ricevono comandi, ma devono trasmettere i risultati del loro lavoro al MIS. Tuttavia, tutti i dispositivi presentano diverse opzioni di collegamento (USB, RS-232, Ethernet, ecc.) e modalità di interazione. Supportarli tutti nel MIS è praticamente impossibile, pertanto è stata sviluppata una strato software chiamato DeviceManager (DM), che offre al MIS un'interfaccia unica per inviare comandi ai dispositivi e ricevere risultati.
Per aumentare l'affidabilità del sistema, il DM è stato suddiviso in un insieme di programmi distribuiti sui computer del centro medico. Il DM è composto da un programma principale e da un insieme di plugin che gestiscono l'interazione con un dispositivo specifico e inviano dati al MIS. Nella figura sottostante è mostrata una struttura generale di interazione tra DeviceManager, MIS e dispositivi.
Nella struttura di interazione tra il MIS e il DeviceManager sono mostrati 3 modi di operare dei plugin:
- Il plugin non riceve dati dal MIS e invia i dati elaborati dal dispositivo nel formato comprensibile per esso (corrisponde al dispositivo di tipo 3 nella figura sopra).
- Il plugin riceve dal MIS un compito breve (in termini di tempo di esecuzione), ad esempio, stampare su una stampante o scansionare un'immagine, lo esegue e invia il risultato in risposta alla richiesta (corrisponde al dispositivo di tipo 1 nella figura sopra).
- Il plugin riceve dal MIS un compito lungo, ad esempio, eseguire un esame o misurare parametri, e risponde con lo stato di accettazione del compito (la richiesta potrebbe essere rifiutata a causa di un errore nella richiesta). Dopo aver completato il compito, i risultati vengono convertiti in un formato comprensibile per il MIS e caricati nelle interfacce corrispondenti al loro tipo (corrisponde al dispositivo di tipo 2 nella figura sopra).
Il programma principale del DM avvia, inizializza, riavvia in caso di arresto anomalo e termina tutti i plugin al termine del lavoro. La composizione dei plugin su ogni computer è unica e vengono avviati solo quelli necessari, come indicato nelle impostazioni.
Ogni plugin è un programma autonomo che interagisce con il programma principale. Questa definizione di plugin consente di garantire un funzionamento più stabile, grazie all'indipendenza di tutte le istanze di plugin e del programma principale nella gestione degli errori (se si verifica un errore critico che causa il crash del plugin, questo non avrà effetto sugli altri plugin e sul programma principale). Un plugin consente di interagire con dispositivi di un certo tipo (spesso dello stesso modello), e alcune istanze di plugin possono interagire solo con un dispositivo, mentre altre possono interagire con più dispositivi. Per collegare più dispositivi dello stesso tipo a un DM si utilizza l'avvio di più istanze di uno stesso plugin.
Per lo sviluppo di DM è stato utilizzato l'ambiente Qt, poiché consente, nella maggior parte dei casi, di astrarsi dal sistema operativo specifico. Ciò ha permesso di supportare il funzionamento su computer con Windows, Linux e MacOS, oltre che su schede Raspberry. L'unica limitazione nella scelta del sistema operativo per lo sviluppo dei plugin è la disponibilità di driver e/o software specifico per il dispositivo in concreto.
L'interazione tra i plugin e il programma principale avviene tramite un QLocalSocket sempre attivo con il nome specifico dell'istanza del plugin, secondo il protocollo da noi creato. L'implementazione del protocollo di comunicazione da entrambi i lati è stata realizzata sotto forma di libreria dinamica, consentendo ad altre aziende di sviluppare alcuni plugin senza rivelare completamente l'interazione con il programma principale. La logica interna del funzionamento del socket locale consente al programma principale di sapere immediatamente di un'uscita, tramite un segnale di interruzione della connessione. Al verificarsi di tale segnale, avviene il riavvio del plugin problematico, permettendo una gestione delle situazioni critiche più fluida.
È stata presa la decisione di basare l'interazione tra il MIS e il DM sul protocollo HTTP, poiché il MIS è basato su Web server, in cui è più semplice inviare e ricevere richieste tramite tale protocollo. Inoltre, è possibile distinguere i problemi che potrebbero sorgere durante l'impostazione o l'esecuzione dei compiti da parte dei dispositivi sulla base dei codici di risposta.
Negli articoli successivi verrà esaminato il funzionamento del DM e di alcuni plugin attraverso l'esempio di diversi uffici del centro diagnostico.
Fonte: habr.com
