Continua, con questo articolo, la disamina degli aspetti da gestire per creare valore per i professionisti sanitari e i cittadini.
Nell’articolo precedente, che trovate qui, ho illustrato perché saranno i servizi a determinare o meno il successo del FSE 2.0. In conclusione ho posto una domanda chiave, ossia quali servizi dovrà esporre l’EDS, se limitarsi ai soli dati o includere delle elaborazioni o delle funzioni su di essi.
Proviamo ad approfondire questo aspetto che ha diverse implicazioni. Prima però bisogna ragionare su come sarà utilizzato l’EDS: sarà un backend che sarà richiamato dai sistemi clinici che i professionisti sanitari già impiegano, in primis la Cartella Clinica Elettronica, o comprenderà un proprio front-end che dovrà essere adoperato dagli utenti o ancora entrambi? La risposta più corretta è la terza, in quanto non è ragionevole pensare che i professionisti, durante la pratica clinica, debbano utilizzare un ulteriore sistema rispetto a quelli che già adoperano (e che non sono pochi).
Diverso è il discorso per i cittadini. Nel loro caso è più probabile che sia proprio l’FSE il front-end con cui usufruiranno dei servizi resi disponibili anche se, anche in questo caso, potrebbero impiegare un’app regionale che sia integrata con l’EDS.
Nel primo caso (solo dati) la logica e l’intelligenza per elaborare e rappresentare i dati sarebbe a carico dei sistemi “di consumo”, nel secondo (dati più funzioni) sarebbero a carico del EDS. I sistemi clinici potrebbero così usufruire di una serie di funzioni già sviluppate, da richiamare e visualizzare in modo semplice, ad esempio all’interno di finestre.
Attestare servizi avanzati sull’EDS permetterebbe di aumentare il suo valore, fornendo non soltanto dati ma informazioni e infine conoscenza agli utenti, in modo uniforme, senza differenze tra un sistema e l’altro.
Ma quali sono i servizi che si potrebbero realizzare in questa seconda accezione, con o senza intelligenza artificiale? Proviamo ad elencarne alcuni:
- Visualizzatori evoluti, in grado di aggregare e correlare dati e informazioni secondo criteri clinici, ad esempio per ambito temporale e/o per patologia. È una tipologia di funzioni davvero necessaria per rappresentare in modo sintetico ed efficace i tanti dati specie dei pazienti cronici e degli anziani,
- Cruscotti specializzati per patologia o funzione, ad esempio il diabete o la riconciliazione della terapia farmacologica,
- Supporto alle decisioni cliniche (DSS) basato sull’Evidence Based Medicine per guidare e suggerire la diagnosi e il trattamento delle patologie,
- Accesso alle linee guida, ai protocolli e alle evidenze scientifiche in modo contestuale e pertinente al paziente.
Le funzioni possono anche essere ibride, ossia composte da più servizi, in una vista integrata, come ad esempio fa la Diagnostic Specific Overview di EBMEDS, un CDSS prodotto da Duodecim e distribuito in Italia in esclusiva da Alkimiya.
Attestare e centralizzare i servizi su EDS permette di ridurre il tempo e i costi di sviluppo necessari rispetto alla scelta di duplicarli su più sistemi, per non parlare poi dell’onere della certificazione MDR per quei servizi che vi rientrano (come ad esempio nell’esempio mostrato – MDR classe IIA).
Ma quali servizi è possibile, in concreto, realizzare una volta che l’EDS sarà popolato con i dati estratti dai documenti CDA? Per rispondere a questa domanda dobbiamo esaminare in dettaglio i dati previsti dalle specifiche che sono state rilasciate.
È quanto faremo nel prossimo articolo.
2 – Continua