Di chi sono gli strumenti della sanità?

Read in English →

Sviluppare uno strumento come MediFlow è interessante perché permette di sperimentare con gli strumenti che tutti i giorni fanno parte del proprio lavoro e che talvolta si danno per scontati, proprio perché fanno parte dell’operatività di una struttura sanitaria. Una cartella, un prescrittivo, un’interfaccia per consultare un referto: a un certo punto ci si abitua al loro funzionamento e diventa difficile separare il modo in cui sono fatti dal modo in cui immaginiamo quel lavoro.

Lavorarci è un po’ come mettere le mani nelle operations. Se qualcosa mi ha insegnato il master di management, è proprio a mettere il naso nei processi e negli strumenti che qualificano il lavoro. Perché il lavoro viene qualificato anche dagli strumenti che si utilizzano: conoscerli meglio permette una comprensione più chiara dei processi, una migliore capacità di analisi dei colli di bottiglia e, forse, qualche idea in più su come affrontarli.

Mentre cerco di portare a compimento la 0.8.6, questa riflessione torna spesso. Pensare a come mettere in esercizio responsabilmente uno strumento attraverso cui passano i dati sanitari di una persona porta anche a ragionare su questioni più ampie: la privacy, il controllo dei dati, la responsabilità di maneggiare informazioni così delicate. E secondo me è qui che si incontra anche la scalabilità di un prodotto in sanità: nella possibilità di crescere senza perdere il controllo dei processi e delle responsabilità che si porta dietro.

Un progetto amatoriale, una domanda pubblica

MediFlow nasce sicuramente come un progetto amatoriale. Nasce però soprattutto per dare corpo a una domanda: come alimentare il dibattito su una piattaforma sanitaria pubblica e open source, valutabile da sviluppatori e sviluppatrici, ma anche dalle persone che quegli strumenti li utilizzano?

Le aziende si pongono spesso il problema della dipendenza dai grandi fornitori. Il dibattito sulle suite aperte, come OpenOffice o LibreOffice, rispetto a Microsoft è un esempio familiare: ridurre una dipendenza esterna, contenere i costi, avere più controllo sui formati. Non significa che il passaggio sia indolore. I piccoli intoppi di compatibilità esistono e, sommati nell’operatività quotidiana, possono pesare. In sanità, poi, non basta che un file si apra: bisogna anche che le informazioni mantengano il loro significato.

La riflessione su una piattaforma aperta nasce anche da un problema che, secondo me, ci si pone ancora poco. Mostrare il codice permette di renderlo valutabile dall’esterno. Non rende automaticamente sicuro uno strumento: servono persone che lo leggano, verifiche e manutenzione. Però rende possibile un controllo più ampio e, potenzialmente, un’integrazione più diretta dei suggerimenti che nascono dalla comunità che lo utilizza.

Uno sviluppo democratico, popolare, potremmo dire, ha qualcosa che riconosco nello spirito del Servizio sanitario nazionale. Purché alla possibilità di contribuire corrispondano responsabilità chiare su cosa viene accettato, mantenuto e messo in esercizio. Aprire il codice è un punto di partenza; farne uno strumento affidabile rimane un lavoro.

La robustezza si vede nel lavoro quotidiano

Un altro aspetto è la robustezza d’esercizio. Mi interessa l’idea di uno strumento che permetta di svolgere le operazioni di base anche quando la connessione manca: compilare un referto, esportare i dati di un paziente, utilizzare le codifiche già disponibili sul computer. Le funzioni che richiedono servizi esterni avranno altri vincoli, ma il lavoro essenziale dovrebbe poter continuare.

È una questione cruciale anche fuori dagli ambienti a basse risorse. Pensiamo a un gestionale per un’unità di strada, a un’attività della Croce Rossa, a un intervento sul territorio. Sono esempi di ciò che uno strumento del genere potrebbe servire, non ambienti nei quali sto dichiarando MediFlow già validato. Aiutano però a rendere concreta una domanda: che cosa deve restare possibile quando le condizioni non sono quelle ideali?

Ragionare in sanità pubblica significa anche entrare nel merito di questi strumenti. Non si può rimanere sempre sui massimi sistemi. Se vogliamo dare una caratterizzazione a una scuola di specialità o a una prospettiva sulla salute, secondo me bisogna mettere insieme la lettura generale e la comprensione di ciò che permette, ogni giorno, di svolgere un servizio.

La proprietà pubblica può riguardare le pareti, il personale e le attività, ma anche l’infrastruttura tecnologica. Immaginare un’infrastruttura regionale, o finanche nazionale, aperta, analizzabile e pubblica significa provare a portare quella responsabilità anche negli strumenti. Il codice aperto non equivale da solo alla proprietà pubblica; può però essere una delle condizioni per costruire un’infrastruttura veramente di tutti. È una prospettiva che mi sembra nello spirito del sistema salute e anche nello spirito del tempo.

Quando il feedback incontra un limite

Io sono prima di tutto un medico e, in secondo piano, un appassionato di tecnologia. Esistono sicuramente persone molto più titolate di me per sviluppare un software o sviscerare questi concetti. Negli anni, però, quando sono stato interpellato nello sviluppo di piattaforme regionali, software o servizi, perché direttamente interessato dal loro utilizzo, mi è stato spesso difficile accettare quanto poco incidessero i feedback.

Non perché pensassi che la mia opinione dovesse avere chissà quali conseguenze. Il punto è che, come per tanti colleghi e colleghe, il bisogno era reale. Eppure esaudire certe richieste sembrava incontrare limiti tecnici molto importanti. Da utilizzatore non sempre potevo sapere quanto dipendesse dalla tecnologia, dai contratti, dalle risorse o dalle priorità. Restava comunque quella distanza fra un’esigenza concreta e la possibilità di darle una risposta.

Gli strumenti di sviluppo assistito permettono oggi di portare nel mondo reale idee che prima avrebbero richiesto tempo, denaro e competenze difficili da mettere insieme. Se si è sufficientemente informati e anche un filo volenterosi nello studiare qualcosa al di fuori del proprio campo, si possono ottenere risultati soddisfacenti. Non viene meno la necessità di capire cosa si sta costruendo, di verificarlo e di riconoscerne i limiti. Cambia però la possibilità di provarci.

La raffinatezza che riesco a esplorare oggi nello sviluppo mi interessa anche quando non riguarda direttamente una funzione rivolta al paziente. Può riguardare l’architettura, l’infrastruttura, il modo in cui le informazioni vengono gestite, come un’interfaccia serve un contenuto e come dialogano le strutture che raccolgono dati. Sono aspetti meno visibili, ma qualificano profondamente il lavoro.

Ridurre la distanza

La sanità e il settore pubblico vivono spesso a una certa distanza dai boati delle grandi innovazioni tecnologiche. A torto o a ragione, quel ritardo permette da un lato di digerire alcuni fenomeni e dall’altro limita l’impatto che potrebbero avere tecnologie nuove. I sistemi intelligenti devono entrare nella discussione anche per ridare spazio a chi lavora: personale sanitario e amministrativo, operatori e operatrici, oltre naturalmente al paziente.

L’Unione europea si muove. Lo European Health Data Space è un riferimento concreto per il controllo e lo scambio dei dati sanitari, con un’applicazione progressiva. Non è un programma per rendere open source tutta la sanità, e un progetto individuale non ne rappresenta automaticamente un’implementazione conforme. È però parte di quel quadro più ampio con cui vale la pena confrontarsi.

La cosa che trovo bella è la possibilità di ridurre la distanza fra le intenzioni e i disegni prodotti da organismi autorevoli e le idee dei singoli. Portare un’idea in una forma che possa essere mostrata, condivisa, discussa. Avere qualcosa di concreto su cui ragionare insieme, anche per capire dove non funziona.

Molto dipende dalla forza dell’idea e dalla qualità dell’implementazione. E il valore che io vedo in MediFlow può essere condizionato dal fatto che sono io a svilupparlo. Anche se il risultato non fosse abbastanza soddisfacente, però, penso che ci sarebbe già un merito nelle domande che riesce a far nascere. A volte basta poco per iniziare una discussione.

Per me MediFlow è anche questo: un modo per mettere le mani nelle operations e, da lì, tornare a una domanda più grande. Quanto dovrebbe essere pubblica la sanità anche negli strumenti attraverso cui lavora?