Separare le applicazioni dai dati, è ora di passare da architetture “app-centric” a “data-centric”

Fonte: EY, How will you design information architecture to unlock the power of data?

I dati oggi sono parte integrante delle applicazioni e quindi frammentati e duplicati tra diversi sistemi. L’interoperabilità è un escamotage ma non la soluzione per risolvere questo problema.

La maggior parte delle applicazioni software sanitarie sono basate su architetture “app-centriche” in cui i dati sono archiviati come parte integrante dell’applicazione stessa, ognuna delle quali è responsabile dell’archiviazione, della protezione, della verifica e della condivisione delle informazioni che gestisce.

Anche le codifiche che l’applicazione utilizza sono parte integrante dei dati che sono quasi sempre in formato chiuso e proprietario, così come le funzioni e le form sono dentro il codice e quasi mai esiste una logica di workflow; gli eventi sono gestiti nel codice.

I sistemi informativi sanitari, come sappiamo, sono formati da decine se non centinaia di diverse applicazioni. Questa situazione determina quattro importanti conseguenze:

  • La frammentazione e la duplicazione di dati
  • La necessità, per far sì che tutte queste applicazioni si parlino tra loro, di perseguire l’interoperabilità tra sistemi, aspetto molto complesso e impegnativo
  • La necessità, al variare di qualsiasi aspetto che riguardi dati, funzioni o flussi di lavoro, di metter mano al codice, compito che richiede risorse tecniche e tempo
  • Il forte lock-in del fornitore che ne deriva.

Bisogna osservare che, per superare questa criticità, non è affatto sufficiente, come molti capitolati richiedono, il possesso della licenza né tantomeno dei codici sorgenti (magari su questo tornerò con un articolo ad hoc).

La presenza di tanti silos dati crea anche un altro problema: il duro e difficile lavoro quando bisogna sostituire un’applicazione e migrarne i dati.

Per tutte queste ragioni è utile pensare di passare da un’architettura incentrata sulle applicazioni a una incentrata sui dati. Questo passaggio elimina i silos di dati, elimina le integrazioni punto a punto tra le applicazioni e fornisce un’architettura composita che accelera lo sviluppo.

Un documento di EY sull’architettura dell’informazione illustra molto bene questo concetto con il seguente diagramma.

Fonte: EY, How will you design information architecture to unlock the power of data?

Le organizzazioni sanitarie che stanno prendendo in considerazione questo cambiamento dovranno valutare attentamente come gestire i propri dati, soprattutto se questi saranno al centro della loro architettura, dal momento che questa è una decisione strategica e a lungo termine, ragione per cui importante non essere legati a un unico fornitore.

C’è poi da considerare che poiché dovranno gestire dati sanitari complessi, sarà necessario un approccio che gestisca questa complessità e permetta di definire con precisione le informazioni. Sarà poi necessario creare un ecosistema di applicazioni intorno ai dati, quindi avranno bisogno di un solido quadro di modellazione che incoraggi l’agilità e il riutilizzo.

openEHR affronta ognuna di queste considerazioni come parte fondamentale del suo progetto. Ha un’architettura aperta, che consente di memorizzare le informazioni centrate sul paziente in un formato neutrale rispetto ai fornitori, di lunga durata, con la gestione delle differenti versioni. In secondo luogo, ha un’architettura semantica che consente di definire con precisione il significato delle informazioni sanitarie e assistenziali. Infine, ha un solido quadro di modellazione, in cui i modelli di dominio sono creati da esperti di dominio (come i medici) e sono separati dai livelli tecnici, il che porta a una maggiore agilità e riutilizzo.

Un approccio incentrato sui dati – implementato con openEHR – consentirà l’emergere di un ecosistema di applicazioni intuitive e incentrate sull’utente. Inoltre, consentirà l’innovazione nella ricerca clinica, nella terapia digitale, nella prevenzione delle malattie e nella gestione della salute della popolazione, sfruttando standard complementari come FHIR, OMOP CDM e modelli come Data Mesh.

Ci sono molti esempi di adozione in tutto il mondo. Forse l’esempio più recente e di alto profilo è quello del Servizio sanitario della Catalogna. Il Servizio sanitario della Catalogna intende utilizzare openEHR per la sua nuova piattaforma di cartelle cliniche in tutta la regione. L’annuncio sottolinea che l’attuale sistema di condivisione delle informazioni è un “ostacolo all’uso sistematico dei dati sanitari“, con “l’interoperabilità semantica che rappresenta probabilmente il problema più grande“.

A Londra è stata implementata una soluzione di pianificazione condivisa delle cure attraverso una piattaforma di dati persistenti con openEHR accoppiata a un ambiente a basso codice per i professionisti della salute e dell’assistenza per evolvere dinamicamente i servizi di pianificazione dell’assistenza digitale.

In Galles, il Digital Health and Care Wales (DHCW) ha annunciato un contratto per l’implementazione di un repository di dati clinici che costituirà una “parte integrante” dell’architettura nazionale e “contribuirà a trasformare l’assistenza e il trattamento dei pazienti“.

In Slovenia, il Ministero della Salute sloveno utilizza openEHR dal 2012, creando servizi di interoperabilità nazionale in tutto il Paese. Nella città di Mosca, oltre 670 fornitori di servizi sanitari utilizzano una piattaforma openEHR per gestire le cartelle cliniche e l’assistenza sociale degli oltre 12,6 milioni di cittadini.

Nell’NHS, la più recente strategia “Data Saves Lives” si impegna a “separare il livello dei dati da quello delle applicazioni [per fornire] un insieme di dati standardizzati… puliti“.

Ma come è possibile affrontare questo cambio di paradigma? Qual è il percorso da intraprendere?

Ne parleremo nel prossimo articolo. Rimanete connessi!

3 thoughts on “Separare le applicazioni dai dati, è ora di passare da architetture “app-centric” a “data-centric”

  1. Fabio Cottini 8 Gennaio 2024 / 15:20

    Le architetture a microservizi non sono certo una novità, ma creare un architettura di questo tipo, che coinvolga più fornitori, mi sembra dura. Se il fornitore “A” sviluppa un applicazione che prevede di ottenere i dati anagrafici dei pazienti da una fonte “B” (che sia fornita da un’azienda sanitaria o da un fornitore terzo, non cambia), la sua applicazione potrà funzionare solo dove è presente un microservizio che implementa la fonte dati “B”. Quindi “A” dovrà necessariamente svilupparsi anche in proprio il microservizio per ottenere i dati anagrafici. Poi ovviamente i microservizi dovranno tutti aderire ad uno stesso “standard”, ma quale? In vent’anni di tentativi, non ho ancora visto convergenza dei fornitori (almeno in Italia) su un solo standard.

Rispondi