Il post nasce un’osservazione di Marco Tironi in un altro post (https://lnkd.in/dqn7XWvD), in sanità dovremmo imparare a distinguere molto meglio tra:
1️⃣ #Co-#progettazione di una soluzione software:
processo trasversale alle funzioni (clinica, direzione sanitaria, ICT, logistica,…)
capitalizza esperienze di più strutture, anche eterogenee
porta a componenti riusabili, migliorati nel tempo su base aggregata
è il modello che si vede, ad esempio, nei progetti di co-costruzione di moduli EHR con gli utenti clinici (es: progetto ERIOS su visualizzazioni temporali in cartella clinica: https://lnkd.in/d3i_evix)
2️⃣ #Iper-#personalizzazione “#tailor #made” sulla singola UO:
regole, schermate e flussi cuciti solo sul reparto X o Y
difficilmente scalabili ad altri contesti
la letteratura lo collega inevitabilmente a una frammentazione dei workflow, all’aumento del burden documentale e a problemi di usabilità (es. scoping review su EHR e carico di documentazione: https://lnkd.in/dVK64tvq; linee guida “configuration over customization”: https://lnkd.in/dpbfkVzE)
Per anni abbiamo confuso la seconda con la prima, seguendo la moda pluri-decantata della bellezza del “lo facciamo su misura per te, per agevolarti. Risultato: processi spezzettati, silos applicativi e costi di manutenzione altissimi… ma margini ottimi per chi sviluppa software.
Il valore, in realtà, sta quasi sempre in:
motore comune a livello di ospedale/azienda (modello dati, regole base, indicatori condivisi)
capacità di essere adattive per singolo reparto (parametri, soglie, viste)
possibilità di confrontare flussi e KPI tra unità diverse senza dover reinventare la logica ogni volta.
Non è “meno libertà” per i reparti, ma più capacità di imparare come sistema invece che moltiplicare varianti locali ingestibili.