L’idea che sta dietro al progetto Orchestrator realizzato da Ominicom (risultato finalista ai Digital360 Awards 2020 per la categoria Mobile Business – Big Data Analytics – IoT) è stata quella di creare una applicazione che sia in grado di adattarsi dinamicamente a un qualsiasi possibile processo del Policlinico di Monza.
Orchestrator, tutti i dettagli del progetto
Il progetto ha previsto l’integrazione di due componenti base della applicazione attraverso un terzo componente motore di orchestrazione. Nello specifico, i primi due componenti si occupano rispettivamente di rappresentare i dati e di istanziare gli stessi secondo un modello a classi (campi strutturati, ereditarietà).
Il terzo componente (l’Orchestrator) governa la logica del flusso (stati) e si occupa di informare la dashboard sulla gestione del dato nei confronti del documentale.
La logica della base dati prevede un database per gli eventi e uno per la rappresentazione (modello Data Transfer Object) dei dati, secondo quanto definito dal pattern CQRS – Command Query Responsibility Segregation.
L’architettura a micro servizi permette di fruire di sistemi distribuiti e ROA (Resource Oriented Architecture) oltre a Loose coupling ed elevate resilienza e scalabilità.
Per implementare il modello Request/Response, è stata adottata la architettura REST (Representational State Transfer), direttamente ispirata dal Web.
Dal canto suo, l’Orchestrator definisce: la sequenza degli elementi che caratterizzano un processo; l’interazione tra diversi rami dello stesso processo; l’interazione tra diversi processi; le modalità di interazione con il sistema di archiviazione dati.
I processi sono mostrati tramite elementi grafici dinamici. All’interno delle singole aree dei processi, si possono definire: quali informazioni mostrare; in quale posizione mostrare le informazioni; con quale tipologia di contenitore rappresentare le informazioni. Per questo progetto specifico i dati dell’assistito sono presentati come Card (contenitori), con due modalità di visualizzazioni, small e large.
Le informazioni possono anche essere rappresentate tramite grafici di tipo TimeLine, dove il dato segue il flusso delle attività.
La gestione verso il collegamento dei devices o verso altri nodi di input di informazioni (per esempio, servizi resi da AWS), è stato definito tramite un ambiente grafico di workflow utilizzando dei tools chiamati Activity.
Lo stesso modello architetturale è utilizzato per definire l’area Medical Journal. Questa è resa disponibile al singolo fruitore del servizio come ambiente dove contattare, consultare e condividere le informazioni sia amministrative (prenotazioni, informazioni generali, …) sia sanitarie (cicli di terapie farmacologiche, meeting eccetera) con i propri referenti della struttura in ospedale. Secondo i promotori del progetto è proprio a questo livello che si concretizza l’idea di un nuovo modello di offerta dove non necessariamente il soggetto che richiede assistenza deve recarsi presso l’istituto, ma è quest’ultimo che si reca, in senso virtuale, presso il richiedente.
Per quanto riguarda l’implementazione del progetto Orchestrator si è partiti dall’analisi per la definizione dei processi e dalla loro rappresentazione virtuale nel sistema. È stata poi adottata la metodologia SCRUM, con la definizione di Sprint e quindi di fasi progressive con coinvolgimento diretto del committente.
I benefici raggiunti
Interoperabilità; virtualizzazione; funzionalità in tempo reale; facilità e agilità nel cambiamento delle configurazioni sono i principali vantaggi ottenuti dal progetto Orchestrator.
Inoltre, grazie alla soluzione Omnicom il Policlinico di Monza può decidere di virtualizzare in modo progressivo i processi e procedere a una maggiore condivisione delle informazioni, all’adozione del cloud computing, all’uso dell’Internet for Things per la personalizzazione del servizio e l’assistenza in tempo reale; il tutto all’insegna di sicurezza e protezione dei dati per la salvaguardia della privacy dei pazienti.
