Continuiamo la nostra analisi focalizzandoci sulla gestione dei dati.
La piattaforma di telemedicina, oltre ad assicurare i servizi necessari per svolgere televisite, teleconsulti e telemonitoraggi, avrà anche l’obiettivo di consentirne il governo e il monitoraggio. Per svolgere questi compiti sarà dotata di un middleware per la gestione delle logiche operazionali sui dati e per la creazione di cruscotti di analisi. Ci sarà inoltre uno strato per la gestione degli eventi e uno di persistenza di dati anonimizzati e raggruppati di tutte le Regioni su un’architettura “near real-time data ingestion” con lo stream dei dati in base ad eventi.
Sarà compito dell’ambiente regionale chiamare le API REST del Gateway Nazionale per propagare gli eventi concordati sull’ambiente nazionale e di esporre tramite il proprio Gateway Regionale i dati che vanno portati in forma anonimizzata a livello nazionale.
I repository regionali conterranno dunque i dati in forma nominativa. Mediante un servizio di data streaming ed ingestion questi verranno importati e anonimizzati per alimentare il Repository Nazionale di Telemedicina che conterrà quindi dati in forma anonima. I dati di pertinenza del nuovo FSE saranno inviati al repository centrale di questo.
I dati di un singolo evento di telemedicina potrebbero in teoria essere presenti in tre repository: in quello della regione dove si è svolta la prestazione, in forma nominativa; in quello della piattaforma nazionale in forma anonima; nel repository centrale del FSE in forma nominativa.
È una scelta e un’architettura che solleva, a mio giudizio, alcune perplessità, per prima la ridondanza dei dati con tutte le complessità che ne derivano in termini di coerenza e allineamento in caso di errori / correzioni. Questo problema in verità esiste anche nell’architettura del nuovo FSE in cui sono previsti la costituzione di repository regionali FHIR in aggiunta a quello nazionale (per maggiori dettagli potete leggere qui).
La duplicazione dei dati presenta poi criticità relative alla sicurezza e alla gestione della privacy se, per questa, verrà mantenuto lo stesso impianto del FSE attuale (ad esempio la possibilità di oscurare dati da parte del cittadino).
La persistenza a livello regionale verrà realizzata in logica “polyglot”. Questo termine, non ancora molto conosciuto, si riferisce all’utilizzo di più tecnologie per l’archiviazione di dati, ad esempio database relazionali, database a grafo, database a documenti NoSQL.
I dati saranno poi elettorati come risorse FHIR che diventerà quindi lo standard di riferimento per l’interscambio delle informazioni.
Il Front-End dovrà fare riferimento al modello MVC (Model View Control) con interfaccia dinamica a componenti e accederà alle risorse e ai servizi applicativi attraverso un Service Gateway che esporrà le API e l’accesso ai microservizi basati su una architettura “event-driven” orchestrata da un motore di workflow. La componente di IAM (Identity Access Management), basata su SAML/OAuth 2.0, implementerà l’integrazione con i sistemi locali di Regione/Azienda Sanitaria.
4 – Continua