
Non è possibile avere i benefici della certificazione continuando però a voler del software fatto su misura. È un concetto che, volenti o nolenti, le aziende sanitarie dovranno accettare.
Le normative in vigore sulla certificazione del software come dispositivo medico (MDR) richiedono, da parte dei produttori, l’adozione di iter di progettazione, sviluppo e validazione molto rigidi. Il software, in questa accezione, cessa di essere un oggetto dinamico e in continua evoluzione per diventare un prodotto industriale nel vero senso del termine.
La normativa attuale (MDR) che ha sostituito la precedente (MDD) definisce dei criteri molto precisi e più stringenti sulla classificazione del software. Mentre in precedenza si poteva registrare un software clinico in classe 1, ossia mediante un processo di auto-certificazione, la normativa attuale richiede, nella maggior parte dei casi, un livello superiore (IIa o IIb) che comporta il ricorso a un ente certificatore e che prevede un iter più complesso (per non parlare poi dei costi). La normativa prevede anche che in caso di “cambiamento rilevante” sia necessario ricertificare il software.
Si tratta di un cambiamento davvero epocale. La definizione di “Software As a Medical Device” significa che il software è, dal punto di vista concettuale ed ingegneristico, come un dispositivo medico. Nessuno penserebbe di mettere in commercio un dispositivo che verrà poi perfezionato o completato nel tempo; così come nessuno chiederebbe al produttore di un dispositivo una serie di modifiche per soddisfare le proprie esigenze (vere o presunte).
Sappiamo bene invece cosa succede nel mondo del software clinico. I produttori sviluppano le loro applicazioni sulle richieste delle aziende sanitarie che, pertanto, sono in continuo sviluppo, delle versioni beta senza fine. Le aziende sanitarie sono abituate a pretendere dai loro fornitori una serie di modifiche e personalizzazioni volte sia a migliorare, a loro giudizio, il software, sia a renderlo più aderente ai loro modelli organizzativi o alle consuetudini che si sono affermate nel tempo.
Le forniture di cartelle cliniche elettroniche sono dei cantieri in cui il software che è stato scelto rappresenta soltanto una base da cui partire per realizzare ciò che l’azienda sanitaria vuole.
Ma come si concilia tutto ciò con la normativa attuale? Il problema è che non si concilia. I produttori hanno certificato i loro software con la precedente normativa e sono al lavoro per ottenere la nuova. In base a questa qualsiasi cambiamento “maggiore” implica la decadenza della precedente certificazione, anche per una classe 1, e la necessità di ottenere la nuova con la classe prevista dall’attuale regolamento. Poiché i controlli sono molto scarsi, i produttori si danno una certa libertà nel modificare i loro software in base alle richieste delle aziende sanitarie senza ricertifcarli.
Queste ultime non hanno cambiato modus operandi. Nei capitolati tecnici si richiede il vincolo della certificazione, in qualche caso andando anche oltre la normativa attuale, e si chiede al fornitore che, in caso di modifiche, questo si impegni a ricertificare il software, assicurando quindi per tutto il periodo di fornitura la sua aderenza alla normativa.
Questa asserzione non tiene però conto di tre aspetti fondamentali:
- I tempi necessari per certificare un prodotto che, al momento, sono tra i 13 e i 18 mesi;
- I costi che la certificazione richiede e che non sono considerati nel valore economico complessivo;
- La complessità, per un fornitore, di gestire una varietà di prodotti certificati, ciascuno dei quali comporta un lavoro rilevante.
Il primo solleva poi un altro problema: fintanto che il prodotto non è stato ricertificato non può essere utilizzato. Ciò implica un allungamento dei tempi dei progetti che già di norma sono molto lunghi a prescindere da questo aspetto.
In conclusione non è possibile avere i benefici della certificazione continuando però a voler del software fatto su misura. È un concetto che, volenti o nolenti, le aziende sanitarie dovranno accettare.
One thought on “Certificazione e personalizzazione del software: l’antitesi che gli enti sanitari non vogliono accettare”