Il contesto italiano del FSE e della regionalizzazione della sanità

LuMiR deve essere compreso nel contesto più ampio delle politiche italiane di sanità elettronica dei primi anni Duemila. L’Italia si trovava allora in una situazione particolare: il Servizio Sanitario Nazionale conservava i principi unitari del diritto alla salute, ma l’organizzazione e l’implementazione dei servizi erano fortemente regionalizzate. Ogni regione doveva costruire le proprie infrastrutture informatiche, a condizione che esse potessero comunicare tra loro, in modo che un cittadino italiano potesse essere curato anche al di fuori della propria regione di residenza.

Da questa tensione è nato il problema centrale del Fascicolo Sanitario Elettronico: fascicoli regionali, ma interoperabili a livello nazionale. I documenti del Tavolo Permanente Sanità Elettronica e la strategia architetturale IBSE formulavano requisiti che sarebbero diventati essenziali anche per LuMiR: disponibilità dell’informazione clinica da qualunque punto del territorio, architettura federata, sicurezza e protezione dei dati personali, alta disponibilità, modularità, implementazione progressiva, minima invasività rispetto ai sistemi esistenti e uso di standard aperti.

RMMG e medicina territoriale in Basilicata

In Basilicata, questa visione generale doveva essere tradotta in un sistema concreto. La regione era piccola, montuosa, con popolazione dispersa e con una struttura sanitaria territoriale complessa. Il programma italiano RMMG (Rete di Medici di Medicina Generale) mirava a potenziare la medicina territoriale e l’assistenza primaria, integrando i medici di medicina generale e i pediatri di libera scelta nel sistema informativo sanitario regionale.

Il medico di famiglia non era più concepito solo come punto isolato di contatto clinico, ma come principale intermediario tra il cittadino, i distretti socio-sanitari, gli ospedali e le altre strutture presenti sul territorio. Questo cambiamento era decisivo: il baricentro della cura doveva essere spostato, per quanto possibile, dall’ospedale verso il territorio, lasciando all’ospedale soprattutto il ruolo di trattamento dei casi acuti.

In questo quadro, LuMiR doveva offrire l’infrastruttura attraverso la quale la medicina territoriale potesse diventare effettivamente connessa, e il medico di famiglia potesse seguire il paziente nel suo rapporto con i servizi specialistici, l’ospedale, il laboratorio, la farmacia e l’amministrazione sanitaria regionale.

La convenzione CNR–Regione Basilicata

LuMiR fu definito formalmente nell’ambito della convenzione CNR–Regione Basilicata, con il titolo Lucania – Medici in Rete. Lo scopo del progetto era la realizzazione di una rete ICT per i medici di medicina generale della Basilicata, destinata al potenziamento dei servizi territoriali e dell’assistenza primaria, allo spostamento del baricentro dall’ospedale al territorio e all’orientamento dei servizi verso il paziente.

Il progetto perseguiva due obiettivi strategici: l’integrazione in rete dei medici e dei pediatri per la continuità della cura e l’integrazione dei servizi sanitari e sociali a livello territoriale. Non si trattava solo di progettare una banca dati medica, né soltanto di trasferire documenti dalla carta al formato elettronico. La posta in gioco era più alta: costruire uno spazio informatico regionale nel quale applicazioni diverse, fornitori diversi, ospedali, ambulatori, medici di famiglia, laboratori e strutture amministrative potessero cooperare intorno al paziente.

Il rapporto con MobiDis

LuMiR non deve essere confuso con MobiDis. MobiDis era stato un altro progetto, legato alla telemedicina, alla malattia cronica, alla telefonia mobile e all’idea di un sistema centrato sul paziente. Tuttavia, alcune soluzioni concettuali adottate in LuMiR si ispiravano all’esperienza di MobiDis: il paradigma patient-centric, l’idea del fascicolo sanitario personale e l’integrazione delle informazioni cliniche in un sistema coerente, accessibile in diversi contesti di cura.

Dunque LuMiR era un progetto distinto, istituzionale e regionale, ma non nasceva dal nulla. Esso riprendeva e trasformava, in un quadro amministrativo reale, una serie di idee sviluppate in precedenza intorno alla telemedicina, alla malattia cronica e alla continuità della cura.

Il mio ruolo nel progetto

La mia collaborazione con il Consiglio Nazionale delle Ricerche era precedente a LuMiR. Era iniziata dieci anni prima con borse di ricerca e periodi di collaborazione scientifica, proseguendo poi attraverso la vicinanza ai gruppi italiani interessati all’informatica medica. Con LuMiR, però, il mio rapporto con il CNR assunse un’altra natura: non si trattava più solo di collaborazione scientifica o di articoli, ma di un coinvolgimento diretto, come dipendente dell’Istituto di Tecnologie Biomediche del CNR, in un progetto regionale reale.

Nei documenti interni del progetto, Fabrizio Ricci compare come responsabile scientifico, mentre io compaio come responsabile della qualità e responsabile del WP1 – Analisi e progettazione. Questa formulazione indica la natura del mio contributo: partecipante diretto alla definizione dell’architettura concettuale e software del sistema.

Nei rapporti di attività di quel periodo compaiono responsabilità molto concrete: preparazione della partecipazione alla gara del progetto LuMiR, partecipazione alla direzione del progetto come responsabile della qualità, raccolta dei requisiti, progettazione del sistema informatico e redazione dei deliverable. In un documento del 2007, il mio ruolo è formulato senza ambiguità: autore dell’architettura software del sistema LuMiR.

L’obiettivo principale

L’idea centrale del progetto fu il passaggio da un modello organisation-centric a uno patient-centric. Non si trattava soltanto di spostare documenti da un luogo all’altro, ma di sostenere processi di cura collaborativi, svolti oltre i confini organizzativi, intorno al paziente e alla continuità della cura.

In questo senso, LuMiR perseguiva due obiettivi nello stesso tempo: da una parte, la comunicazione e lo scambio di informazioni cliniche tra attori autorizzati; dall’altra, la possibilità di costruire applicazioni verticali più intelligenti, orientate ai percorsi clinici, alla misurazione dei risultati, alla governance e all’uso secondario dei dati aggregati.

Il Virtual Healthcare Record come nucleo del sistema

Il nucleo concettuale e funzionale del progetto, che riuscii a imporre, fu il Virtual Healthcare Record, o, nella terminologia italiana utilizzata nel progetto, la Cartella Clinica Virtuale. In LuMiR, il VHR non fu concepito come un semplice deposito documentale, ma come una piattaforma longitudinale, estesa sull’intero territorio, capace di raccogliere, integrare, registrare e recuperare dati clinici relativi agli eventi medici significativi nella vita del cittadino.

Nel capitolo dedicato alle prospettive del sistema LuMiR, questa entità era descritta come una miscela di dati complessi e servizi basati sui processi: una rappresentazione longitudinale dello stato di salute, della storia clinica e dei processi di cura in corso. Essa doveva raccogliere informazioni dall’ambiente, integrarle con i dati già esistenti, mantenere la coerenza del fascicolo, notificare gli eventi rilevanti, avviare e monitorare processi di supporto alla cura e fornire viste diverse in funzione del ruolo dell’utente.

Le applicazioni locali estraevano l’informazione rilevante dai documenti clinici HL7 CDA firmati digitalmente, la associavano agli eventi clinici che l’avevano generata e la trasmettevano all’infrastruttura LuMiR, dove diventava disponibile sotto forma di aggregazioni significative: stato di salute corrente, storia clinica, trattamenti in corso e altre viste utili per i professionisti autorizzati.

Questa idea era importante perché superava il modello strettamente document-centric. I documenti clinici firmati digitalmente restavano essenziali, ma non esaurivano il problema. Il documento era la traccia di un evento clinico, non l’evento stesso. Il fascicolo sanitario non doveva essere soltanto memoria; doveva diventare supporto alla continuità della cura.

➡️ Vedi anche: Virtual Healthcare Record

Il modello informativo: Contact, Episode of Care, Health Issue

Un passo importante compiuto da LuMiR rispetto al modello puramente document-centric raccomandato a livello nazionale fu l’introduzione di ulteriori concetti clinici e organizzativi: Contact, Episode of Care e Health Issue.

In questa visione, i documenti non erano più gli elementi primari del fascicolo, ma le tracce di eventi clinici. Un contact rappresentava l’incontro rilevante tra il paziente e un professionista o un’organizzazione sanitaria. Più contatti potevano formare un episode of care, nel quale un episodio si riferiva a una health issue o a una situazione medica comune, caratterizzata da un inizio di manifestazione, cioè da un evento. Questa modellazione rendeva possibile una ricostruzione più fedele della storia clinica e un’interrogazione più intelligente dei dati.

L’analisi del sistema LuMiR metteva l’accento sull’interoperabilità semantica: non era sufficiente che le applicazioni scambiassero messaggi tecnicamente corretti; esse dovevano condividere un modello semantico comune del dominio, affinché ciò che era trasmesso da un attore fosse compreso nello stesso modo dagli altri partecipanti all’ambiente collaborativo.

L’architettura tecnica

Dal punto di vista tecnologico, LuMiR fu pensato come un sistema distribuito, basato su componenti e su una Service Oriented Architecture. Le applicazioni nei punti di cura erano connesse mediante adattatori software, capaci di trasformare l’informazione locale in messaggi standard e di integrarla nei flussi regionali.

L’architettura era stratificata. Alla base si trovava l’infrastruttura di cooperazione applicativa della pubblica amministrazione; al centro, la componente IBIS e i servizi comuni di autenticazione, autorizzazione e transazione; al di sopra, un’ulteriore architettura SOA attraverso la quale i partecipanti scambiavano messaggi HL7 v3 e documenti HL7 CDA, utilizzando sia interazioni request/reply sia publish/subscribe.

Un ruolo particolare era svolto dal LuMiR Infobroker, mediatore tra le applicazioni locali e l’infrastruttura documentale IBIS. Esso elaborava i messaggi, estraeva i documenti allegati, registrava i metadati nel registro IBIS, conservava le informazioni su contatti ed episodi e notificava i partecipanti interessati agli eventi rilevanti.

Questa architettura combinava due movimenti complementari: da una parte, l’integrazione delle applicazioni locali attraverso adattatori e messaggi standardizzati; dall’altra, la costruzione di uno spazio regionale comune nel quale eventi clinici, documenti e notifiche potevano essere correlati in un percorso di cura coerente.

Standard e interoperabilità

Per garantire l’interoperabilità tecnica e semantica, il progetto tenne conto di diverse iniziative e standard: HL7 v3, HL7 CDA r2, CEN TC/251, ebXML, SAML2, XACML, SPCoop e, a livello terminologico, SNOMED e LOINC. Non si trattava solo di conformità formale, ma del tentativo di costruire una piattaforma abbastanza robusta e al tempo stesso abbastanza flessibile da integrare applicazioni preesistenti, fornitori diversi e processi locali molto eterogenei.

Nella stessa logica fu sviluppato anche un Domain Analysis Model personalizzato, derivato dall’HL7 v3 RIM e completato con concetti dello standard CEN sulla continuità della cura, nonché con elementi specifici del contesto LuMiR.

Lo scenario clinico dello scompenso cardiaco

Un modo concreto di comprendere il sistema è lo scenario del paziente con scompenso cardiaco. Nei documenti di lavoro compare Mario Bianchi, un paziente anziano con scompenso cardiaco cronico e lieve insufficienza renale, seguito dal suo medico curante e dal servizio di cardiologia di Policoro. Un improvviso aumento di peso lo porta dal medico di famiglia, che consulta la storia del paziente, individua un episodio simile avvenuto sei mesi prima, apre un nuovo episodio, modifica la terapia e richiede un teleconsulto cardiologico asincrono.

In questo scenario, il sistema non funziona come archivio statico. Il medico aggiorna il fascicolo, prescrive il farmaco, la farmacia notifica la dispensazione, il cardiologo consulta i dati clinici e l’ECG, emette un referto, il laboratorio produce le analisi, e il medico di famiglia e il cardiologo vengono notificati e possono continuare insieme il percorso terapeutico.

Proprio qui si vedeva il senso profondo di LuMiR: il sostegno a un processo di cura distribuito, nel quale più attori partecipano allo stesso episodio clinico, senza che l’informazione rimanga prigioniera di una sola struttura.

Sviluppo incrementale: LuMiRp0, LuMiR1, LuMiR2

A causa dei vincoli istituzionali, organizzativi e tecnologici, il progetto fu sviluppato in modo incrementale. LuMiRp0 fu una prima versione sul campo, orientata alla sperimentazione e alla validazione del modello di interazione con i professionisti.

LuMiR1 consolidò la piattaforma come sistema distribuito e component-based, più attento all’interoperabilità, alla sicurezza, alla riservatezza e all’affidabilità. In questa fase, l’infrastruttura, gli adattatori, il viewer e l’Infobroker assunsero una forma più matura.

LuMiR2 era pensato come il passo successivo: non solo l’integrazione dei dati estratti dai documenti, ma l’estensione del modello verso i processi assistenziali, il disease management, i profili del paziente, i servizi per il cittadino e il passaggio graduale verso un ecosistema digitale della salute.

L’adozione del sistema nel 2011

Nel 2011, il problema principale non era più soltanto la progettazione del sistema, ma la sua effettiva adozione. Qui si vide con grande chiarezza la differenza tra un sistema costruito e un sistema usato. Nelle riunioni con la Regione Basilicata emersero temi molto concreti: formazione del personale, integrazione delle applicazioni locali, problemi di privacy e consenso, stato dei nodi LuMiR, funzionamento del wrapper universale, alimentazione del sistema con documenti e rapporto con i fornitori delle applicazioni esistenti.

L’adozione doveva cominciare in modo pragmatico. Per la prima fase erano previsti i medici di medicina generale che utilizzavano Basmed o Millewin e i pazienti con scompenso cardiaco. Per gli specialisti ospedalieri e ambulatoriali, l’avvio doveva avvenire sempre attraverso la cardiologia. Parallelamente venivano stabiliti programmi di formazione per tecnici, informatici di sistema e personale destinato a supportare i medici.

Prima dell’attivazione completa dovevano essere risolti anche gli aspetti di protezione dei dati: informativa, consenso, autorizzazione all’accesso ai dati e ruolo del medico di famiglia nell’acquisizione del consenso del paziente. Una comunicazione del CNR alla Regione Basilicata proponeva l’avvio di LuMiR come sistema paperless, destinato a crescere gradualmente attraverso i tipi di documenti caricati e le strutture collegate.

Questa fase fu, per me, una delle più istruttive. Mi mostrò che un Fascicolo Sanitario Elettronico non è soltanto un’architettura software e nemmeno una semplice collezione di standard. È una costruzione istituzionale. Si possono avere documenti HL7 CDA, broker, adattatori, registry, repository, notifiche e servizi di sicurezza; l’adozione dipende però dall’amministrazione, dai medici, dai fornitori, dalla formazione, dalle decisioni politiche e dalla capacità di una regione di imporre una direzione comune.

Basilicata, Matera e gli incontri di progetto

LuMiR significò anche una serie di viaggi ripetuti in Basilicata: riunioni tecniche, presentazioni, incontri con i medici e discussioni con i rappresentanti dell’amministrazione regionale. Matera e Potenza non furono soltanto sfondi geografici, ma i luoghi concreti in cui l’architettura del sistema fu confrontata con le esigenze della medicina territoriale.

➡️ Vedi la pagina fotografica: Basilicata, Matera e LuMiR

LuMiR2: dal FSE ai processi assistenziali

Dall’esperienza accumulata in Basilicata prese forma il progetto LuMiR2, concepito come continuazione naturale del progetto iniziale. Se LuMiR era centrato sull’integrazione dei medici di famiglia e sulla costituzione di un FSE regionale, LuMiR2 spostava l’accento verso il Disease Management, la continuità della cura, i percorsi assistenziali, il patient empowerment e il coinvolgimento attivo del cittadino nella propria salute.

In LuMiR2, la Cartella Clinica Virtuale doveva essere estesa come supporto ai processi di cura. Intorno a essa venivano progettate nuove componenti: un editor e un motore per l’esecuzione semi-automatizzata dei percorsi assistenziali, un Libretto Sanitario Elettronico intelligente e multimodale, reti sociali per il rapporto tra cittadino e sistema sanitario, profili del paziente e un Portale della Salute regionale.

Questo mostrava la direzione in cui già allora pensavo: il passaggio dal FSE come infrastruttura di memoria clinica al FSE come piattaforma attiva di coordinamento della cura.

Il libro incompiuto su LuMiR

In quel periodo tentai anche di scrivere un libro su LuMiR, rimasto incompiuto. Il titolo provvisorio era “LUMIR: Un Fascicolo Sanitario Elettronico di Seconda Generazione”. Il libro voleva presentare non solo il progetto tecnico, ma anche le premesse organizzative e tecnologiche che avevano reso necessario il passaggio dal modello organization-centric al modello patient-centric nell’erogazione dei servizi sanitari.

Il mio contributo si concentrò in particolare sui capitoli riguardanti il contesto del FSE, l’analisi del dominio, la progettazione del sistema e le prospettive architetturali di LuMiR. Questi testi mostravano meglio degli articoli sintetici pubblicati come era stato pensato il progetto: dall’analisi della sanità elettronica e del programma RMMG, alla modellazione concettuale dei processi di cura, poi all’architettura tecnica del sistema e, infine, alla trasformazione della Cartella Clinica Virtuale in un nucleo attivo per la continuità della cura.

Il mio coinvolgimento si rifletteva anche nei capitoli tecnici preparati per il libro su LuMiR: l’analisi del dominio, la progettazione del sistema e le prospettive legate alla Cartella Clinica Virtuale portano l’impronta della stessa preoccupazione per il passaggio dal documento clinico isolato a un sistema capace di rappresentare e sostenere processi reali di cura.

• Capitolo 1 – Stato dell’arte nella Sanità Elettronica
  Il contesto generale dell’e-Health, del Fascicolo Sanitario Elettronico, del programma RMMG, degli standard e della cooperazione applicativa nella sanità italiana.
• Capitolo 5 – Analisi del sistema LuMiR
  Il modello concettuale del dominio LuMiR, l’interoperabilità semantica e la rappresentazione dei processi di cura attraverso concetti come contatto, episodio di cura e problema di salute.
• Capitolo 6 – Progettazione del sistema LuMiR
  La progettazione incrementale LuMiRp0, LuMiR1 e LuMiR2, l’architettura SOA, lo Standard Adapter, il Broker, il Pull Point, il Notification Service, l’Access Gateway, la sicurezza e il portale LuMiR.
• Capitolo 9 – Prospettive per il sistema LuMiR
  Lo sviluppo dell’idea di Cartella Clinica Virtuale come entità capace di integrare dati, servizi, notifiche, processi assistenziali e viste diverse sullo stato di salute del cittadino.

Il libro non fu terminato; alcuni capitoli dei colleghi rimasero solo abbozzati. Esso rimane tuttavia, per me, una testimonianza dell’ambizione concettuale del progetto. LuMiR non era pensato solo come sistema locale, ma come tentativo di definire un FSE di seconda generazione: non soltanto un luogo in cui si raccolgono documenti, ma un’infrastruttura capace di sostenere la collaborazione, la continuità della cura e il governo dei processi assistenziali.

La dimensione socio-tecnica del progetto

LuMiR non fu soltanto un problema di integrazione software. Fin dall’inizio, il progetto dovette tener conto del fatto che i servizi sanitari sono prodotti attraverso l’interazione tra persone, tecnologie e processi di lavoro, e che il cambiamento di uno di questi elementi trascina cambiamenti negli altri. Per questo, la metodologia adottata ebbe anche una componente socio-tecnica: lo sviluppo dell’infrastruttura doveva permettere una trasformazione graduale delle pratiche professionali, non soltanto l’installazione di un nuovo sistema informatico.

Il posto del progetto nelle mie ricerche

Per me, LuMiR fu il momento in cui un nucleo concettuale già formulato – in particolare il Virtual Healthcare Record – fu messo al lavoro in un progetto istituzionale reale, con tutti i vincoli e i compromessi che un sistema sanitario regionale comporta.

Allo stesso tempo, LuMiR mostrò anche i limiti di un’architettura puramente component-based e aprì la strada a una riflessione più ampia, che avrebbe portato più tardi al Digital Healthcare Ecosystem e alle architetture orientate agli agenti. In questo senso, può essere letto come l’anello di passaggio tra il concetto di VHR, come nucleo informazionale, e il quadro più ampio dell’ecosistema digitale della salute.

Guardando indietro, LuMiR occupa un posto speciale nel mio percorso intellettuale. Fu il luogo in cui idee provenienti dall’ingegneria del software, dalla modellazione dei sistemi informativi, dalle architetture orientate ai servizi e dall’informatica medica incontrarono la dura realtà di un sistema sanitario regionale con vocazione nazionale.

➡️ Vedi anche: Virtual Healthcare Record · Digital Healthcare Ecosystem

Articoli sul progetto

Il progetto LuMiR fu presentato in diversi lavori successivi, che colgono fasi e accenti differenti: la prima formulazione sintetica dell’architettura, il contesto regionale e la metodologia incrementale, poi una sintesi matura del progetto e delle sue direzioni di sviluppo.

• LuMiR: A Region-wide Virtual Healthcare Record (2008)
  La prima presentazione sintetica del progetto, centrata sul Virtual Healthcare Record, sull’architettura stratificata e sui concetti di Contact ed Episode of Care.
• LuMiR: The EHR-S in the Basilicata Region (2009)
  Un testo più ampio, incentrato sul contesto regionale della Basilicata, sui principi di progettazione, sulla metodologia incrementale e sul ruolo del LuMiR Infobroker.
• LuMiR: The region-wide EHR-S in Basilicata (2010)
  Una sintesi matura del progetto, con accento sul ciclo di vita LuMiR, sui limiti del modello document-centric e sull’apertura verso LuMiR2 e l’architettura multi-agent.
• Steps towards a digital health ecosystem (2011)
  Il testo in cui LuMiR viene reinterpretato come tappa di transizione verso il Digital Healthcare Ecosystem.