In un centro medico automatizzato vengono utilizzati molti strumenti diversi, il cui funzionamento deve essere gestito da un sistema informativo medico (SIM), insieme a dispositivi che non ricevono comandi, ma devono trasmettere i risultati del loro lavoro al SIM. Tuttavia, tutti i dispositivi hanno diverse modalità di collegamento (USB, RS-232, Ethernet, ecc.) e modalità di interazione. Supportarli tutti nel SIM è praticamente impossibile, perciò è stata sviluppata una soluzione software, DeviceManager (DM), che offre al SIM un'interfaccia unificata per l'invio di comandi ai dispositivi e per ricevere i risultati.
Per aumentare l'affidabilità del sistema, il DM è stato suddiviso in un insieme di programmi distribuiti sui computer del centro medico. DM è composto da un programma principale e un insieme di plugin, che gestiscono l'interazione con dispositivi specifici e inviano i dati al SIM. Nella figura sottostante è mostrata la struttura generale dell'interazione con DeviceManager, il SIM e gli strumenti.
Nella struttura di interazione tra il SIM e DeviceManager sono mostrati 3 modi di funzionare dei plugin:
- Il plugin non riceve alcun dato dall'MIS e invia i dati trasformati in un formato comprensibile per essa provenienti dallo strumento (corrisponde allo strumento di tipo 3 nell'immagine sopra).
- Il plugin riceve dall'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 allo strumento di tipo 1 nell'immagine sopra).
- Il plugin riceve dall'MIS un compito lungo, per esempio, condurre un'ispezione o misurare parametri, e invia lo stato di accettazione del compito in risposta (l'accettazione del compito può essere rifiutata in caso di errore nella richiesta). Al termine del compito, i risultati vengono trasformati in un formato comprensibile per l'MIS e scaricati nei corrispondenti interfaccie del tipo (corrisponde allo strumento di tipo 2 nell'immagine sopra).
Il programma principale DM avvia, inizializza, riavvia in caso di arresto imprevisto (crash) e termina al termine delle operazioni tutti i plugin. La composizione dei plugin su ciascun computer è unica, vengono avviati solo quelli necessari, specificati 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 tutti gli esemplari dei plugin e del programma principale nella gestione degli errori (se si verifica un errore critico che fa crollare un plugin, gli altri plugin e il programma principale non ne risentiranno). Un singolo plugin permette di lavorare con dispositivi di un certo tipo (spesso di un certo modello); mentre alcuni plugin possono interagire solo con un singolo dispositivo, altri possono farlo con più di uno. Per collegare più dispositivi dello stesso tipo a un DM, si utilizzano più istanze di uno stesso plugin.
Per lo sviluppo del DM è stato utilizzato il toolkit Qt, poiché consente, nella maggior parte dei casi, di astrarsi dal sistema operativo specifico. Questo ha reso possibile il supporto per computer basati su Windows, Linux e MacOS, nonché per 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 questione.
L'interazione tra i plugin e il gestore avviene tramite una QLocalSocket sempre attivo, con un nome specifico dell'istanza del plugin, secondo il protocollo da noi creato. L'implementazione del protocollo di comunicazione da entrambe le parti è stata realizzata come una libreria dinamica, consentendo lo sviluppo di alcuni plugin da parte di altre aziende senza rivelare completamente l'interazione con il gestore. La logica interna del funzionamento del socket locale permette al gestore di sapere immediatamente quando si verifica un'interruzione tramite il segnale di disconnessione. Quando viene attivato tale segnale, si procede al riavvio del plugin problematico, il che consente di gestire le situazioni critiche in modo più indolore.
L'interazione tra il sistema informativo e il DM è stata decisa costruirla basandosi sul protocollo HTTP, poiché il sistema informativo funziona su base Server Web, nel quale risulta più semplice inviare e ricevere richieste secondo questo protocollo. Inoltre, c'è la possibilità di distinguere i problemi che potrebbero sorgere durante l'impostazione o l'esecuzione delle attività da parte degli apparecchi in base ai codici di risposta.
Negli articoli seguenti, verrà esaminato il funzionamento del DM e di alcuni plugin, utilizzando come esempio diversi ambulatori del centro diagnostico.
Fonte: habr.com
