Ogni 5 – 9 anni le aziende sanitarie sostituiscono i loro sistemi informativi. Partendo, ogni volta, da zero.
La sostituzione è determinata dalla necessità di aggiornare tecnologicamente i sistemi e/o di procedere a nuove gare di appalto (nella sanità pubblica) non potendo prolungare oltre un certo numero di anni l’assegnazione della manutenzione e dei servizi professionali al fornitore corrente.
Come un film che si ripete, ogni volta uguale, ecco allora che si parte da un capitolato di gara che, rispetto al precedente, ha poche differenze, perlopiù di tipo tecnologico. A parità di dominio applicativo, le informazioni da gestire sono le stesse, così come i processi, i flussi informativi, le periferiche da adoperare. Ad esempio i dati di un ricovero, così come quelli di un pronto soccorso o di un esame di laboratorio sono sempre gli stessi, non cambiano nel tempo, altrettanto si può dire dei processi e delle funzioni da gestire.
I sistemi informativi sanitari sono però degli insiemi chiusi e auto-consistenti. Ciascuno di essi ha un proprio modello dati, una sua business logic e una propria interfaccia utente. Anche quando sono progettati con pattern architetturali che prevedono la separazione tra le diverse componenti logiche, ad esempio Model-View-Controller (MVC), tale impostazione rimane circoscritta all’interno dei sistemi e non può essere utilizzata per preservare delle componenti che non sarebbe necessario cambiare.
Prendiamo ad esempio il modello dati. Questo, se ben disegnato, potrebbe “vivere” molto più a lungo dell’interfaccia utente che al contrario è più soggetta all’evoluzione della tecnologia. Perché allora, ogni volta che si cambia un sistema, bisogna cambiare base dati e realizzare una migrazione dati che è complicata, costosa e spesso porta a risultati poco soddisfacenti?
Lo stesso vale anche per i processi e le funzioni. L’accettazione di un ricovero, ad esempio, non varia nel tempo a meno che non intervengano modifiche normative o organizzative. I sistemi sanitari però implementano i processi e le funzioni direttamente nel codice delle applicazioni (embedded). Se cambio sistema devo quindi accertarmi che il nuovo software implementi le funzioni e gestisca i processi nel modo corretto, ricominciando da zero per la “gioia” di utenti e tecnici.
Tutto ciò è, a ben vedere, uno spreco di risorse e tempo che assorbe buona parte della capacità di investimento che hanno le aziende sanitarie. Ma cosa è possibile fare per evitare questa situazione e non ricominciare ogni volta da capo?
La risposta è nell’architettura globale del sistema informativo e nell’adozione di nuovi paradigmi, come ad esempio HL7 FHIR. Se scomponiamo il mosaico delle diverse componenti e lo decliniamo in chiave di risorse, possiamo progettare un sistema in cui il modello dati è una risorsa indipendente dal sistema applicativo che utilizza queste informazioni.
Anche i processi e le funzioni di base possono essere isolati e gestiti magari con piattaforme software che consentono la definizione di regole e workflow, a prescindere dalle modalità con cui verranno rappresentate e inserite le informazioni da trattare.
Si tratta dunque di superare la tradizionale logica del modulo o del sistema applicativo come oggetto a sé stante ed auto-consistente, per disegnare un’architettura basata sui servizi e su micro-componenti.
Penelope disfaceva di notte la tela perché non voleva ultimare il lenzuolo funebre del suocero Laerte per dare modo ad Ulisse di tornare ad Itaca. Ma i CIO che motivo hanno di disfare ogni 5-9 anni i loro sistemi informativi?