
Mentre le tecnologie cambiano velocemente, il modo di realizzare le applicazioni sanitarie rimane lo stesso, ad esclusivo vantaggio di chi le produce.
Il sistema geocentrico è stato la teoria astronomica prevalente per circa due millenni prima di essere sostituita dal sistema eliocentrico di Niccolò Copernico. Ma cosa c’entra tutto ciò con la sanità digitale? La riflessione mi è venuta spontanea ragionando sul confronto tra visione “app-centrica” e “data-centrica” di cui ho parlato in questo post.
Sinora le applicazioni sono state e sono tuttora il centro della sanità digitale. Ogni cosa ruota intorno ad esse, incluso i dati che ne sono parte integrante. Le aziende che sviluppano software investono tempo e denaro per costruire delle applicazioni che siano aggiornate tecnologicamente e che abbiano un grande livello di configurabilità a livello di processi, form, dati. Il fatto che questi siano dentro le applicazioni e siano gestiti nel codice o nella struttura della base dati determina una notevole complessità che si ripercuote in una serie di criticità: difficoltà nel preservare il concetto di “prodotto” rispetto alla “soluzione custom”; lo sforzo per manutenere ed evolvere il prodotto; la fragilità di alcuni meccanismi che, se modificati per un’esigenza, possono impattare negativamente sui clienti.
Il ricorso ad architetture a servizi o a micro servizi non risolve il problema anche se un po’ lo mitiga. Il problema è proprio nell’approccio che, in una sanità sempre più articolata e digitale, ha come limite la sua stessa natura.
Confrontandomi con i software vendor su questo tema osservo come per loro sia difficile cambiare il paradigma, ossia il punto di vista da cui progettare a una soluzione di sanità digitale. L’idea di “separarsi” dai dati è fonte di scetticismo sulla effettiva fattibilità di una cosa del genere e preoccupazione per la possibile perdita di controllo su un aspetto fondamentale per ogni applicazione.
I servizi o i micro servizi vanno bene soltanto se operano con la propria base dati, qualcosa che controllo appieno. Separare a livello logico e fisico i dati dalle applicazioni è un concetto comprensibile ma difficile da accettare.
A ben guardare però le resistenze che ci sono non riguardano soltanto gli aspetti tecnici ma sono anche di natura commerciale. Tenere tutto insieme, con logica proprietaria, assicura un forte lock-in da parte del fornitore che non si scalfisce né con la cessione della licenza d’uso, né tantomeno con quella dei codici sorgenti.
Ecco allora – qui capirete cosa c’entra Ulisse – che collocare un sistema in un cliente assicura tanto lavoro in un mercato captive per gli anni a venire. Un sacrificio economico iniziale, nella risposta di gara, permette non solo di recuperare nel tempo il mancato introito ma di difendere la propria posizione sul cliente per molti anni. Se poi l’azienda sanitaria vorrà cambiare fornitore, i costi e le difficoltà della migrazione saranno a suo carico.
Ma il passaggio da visione “app-centrica” a “data-centrica” non è il solo aspetto da considerare. Alcune riflessioni si devono anche fare su come sono sviluppate le applicazioni. Di questo parleremo nel prossimo post.