+390677209020 | +39 0267380552 info@direnzo.biz | sedemilano@direnzo.biz

Lingua

Software Dispositivi Medici: tra vecchia direttiva e nuovo regolamento

L’attuale assetto normativo, basato sulla Direttiva 93/42/CEE, regola il software destinato dal fabbricante ad essere un dispositivo medico (o facente parte di esso) in modo relativamente marginale. Nella Direttiva viene nominato sette volte, di cui una solo per stabilire che va considerato come un dispositivo medico attivo (p.es elettromedicale) e altre due nella definizione stessa di dispositivo medico. Di fatto, l’unica prescrizione esplicita, costituente un Requisito Essenziale, è data dal punto 12.1bis dell’Allegato I.

Esso subordina la convalida del software allo stato dell’arte nel settore di riferimento, tenendo in conto i principi del ciclo di vita dello sviluppo, della gestione dei rischi, della validazione e della verifica. Tutte le altre prescrizioni riguardano i dispositivi medici attivi e quindi basati su un gruppo molto più ampio, variegato e sostanzialmente non finalizzato a prodotti immateriali (come è fondamentalmente un software).

L’effetto di questo approccio è stato duplice. Da un lato, i fabbricanti si sono trovati nella difficoltà materiale di capire se il proprio software fosse effettivamente inquadrabile come dispositivo medico, tanto che l’argomento è stato oggetto di una guida apposita, la MEDDEV 2.1/6, dalla quale è disceso un algoritmo pratico per risolvere il problema. Dall’altro lato, il soddisfacimento dei Requisiti Essenziali imposti dalla Direttiva si è quasi interamente basato sulle prescrizioni riguardanti i dispositivi medici attivi, per larga parte impropri se applicati ad un software. Addirittura, nessuna regola di classificazione nomina i software, per cui la loro stessa classificazione si è basata su quella dei dispositivi medici attivi (Regole da 9 a 12, Allegato IX).

A cascata è disceso il problema di avere molti software inquadrati in classe I secondo Regola 12, perché non ricadenti nelle Regole precedenti a classificazione superiore, ma poco idonei o troppo stringenti per la destinazione prevista di un software. Viceversa, il soddisfacimento dei Requisiti Essenziali, considerabile come problema successivo all’inquadramento legale, si è risolto in virtù del punto 12.1bis sulla base dell’applicazione di un sistema di gestione della qualità (basata su ISO 13485), costituente in sé una delle norme armonizzate fondamentali nell’ambito medicale. In più, si è fatto ricorso alla norma armonizzata specifica per i software basata sulla IEC 62304. Entrambe le norme hanno contribuito a bilanciare gli aspetti generali rispetto a quelli specifici, riuscendo anche a complementarsi sugli aspetti non direttamente trattati (su tutti, l’esclusione della validazione e del rilascio finali del software, anche quando costituente un dispositivo medico a se stante, dall’ambito di applicazione della norma 62304).

Più facile è stata la sorte dei software che fanno parte integrante di dispositivi medici attivi, grazie alla norma armonizzata che li riguarda, che recepisce la IEC 60601-1, oltre che al punto 12.1 dell’Allegato I. In questo caso, in virtù del punto 2.3 dell’Allegato IX, il software è classificabile direttamente in base al dispositivo medico attivo su cui opera e le prescrizioni dettagliate della 60601-1 hanno fatto tutto il resto.

Il nuovo regolamento

Il nuovo Regolamento (UE) 2017/745 che verrà applicato da maggio 2020, avvalendosi ovviamente di tutto il bagaglio di sviluppo tecnologico intercorso rispetto alla stesura della vecchia Direttiva, affronta la regolamentazione dei software (nominati 53 volte) in modo più esplicito, diretto e dettagliato. I vecchi punti 12.1 e 12.1bis della Direttiva diventano i punti 17.1 e 17.2 dell’Allegato I, specificando che l’intero punto 17 riguarda direttamente anche i software.

Qui si trova, al punto 17.3, la prescrizione riguardante i software destinati ad essere utilizzati su piattaforme mobili, consapevoli dell’odierna predisposizione delle “app” ad essere concepiti per funzionare su qualsiasi supporto, come gli smartphone. Curiosa invece risulta la prescrizione al punto 17.4 perché l’obbligo di specificare i requisiti minimi in materia di hardware, reti informatiche e misure di sicurezza, compreso l’accesso non autorizzato, potrebbe scontrarsi con l’onere più perentorio espresso all’Allegato II riguardante la documentazione tecnica, dove al punto 6.1, lettera b), quarto trattino, si specifica che la verifica e la convalida del software deve tenere conto di tutte le diverse configurazioni hardware e sistemi operativi identificati nelle informazioni fornite dal fabbricante. In pratica, da un lato si lascia margine definendo solo un limite inferiore mentre dall’altro si obbliga a tenere in conto tutto.

Detta questione apre un argomento abbastanza rilevante per i software, soprattutto quelli moderni che vengono già (almeno) concepiti per funzionare in qualsiasi sistema informatico: la restrizione o la libertà di essere usati su sistemi non ampiamente testati in anticipo.

Infatti, se esiste una caratteristica distintiva dei software rispetto a tutti gli altri prodotti di uso e consumo è proprio la capacità di doversi adattare a qualsiasi variegata impostazione di sistema, e sappiamo che cambiamenti di sistema sono piuttosto frequenti nella pratica comune. L’intero impianto normativo attuale, così come quello previsto dal nuovo Regolamento, è fortemente conservativo in termini di rischi a carico dell’utilizzatore o paziente.

Nei fatti, l’approccio comune più seguito dai fabbricanti di software dispositivi medici è sempre stato quello di evitare contaminazioni, cambiamenti, interferenze, libertà di scelta. Supportato e vincolato dalle prescrizioni della 13485, 62304 e 60601-1, il fabbricante diligente e cauto ha sempre preferito la strada sicura optando per l’uso fortemente vincolato a particolari sistemi con particolari configurazioni.

Il risultato oggi è abbastanza evidente in ambiente clinico, dove l’interoperabilità e la compatibilità di dispositivi medici diversi, appartenenti a fabbricanti diversi, è di molto inferiore e limitata rispetto agli ambienti di massa. Rispetto a questo argomento il nuovo Regolamento non solo non è risolutivo ma aggrava la situazione, introducendo espressamente le definizioni di compatibilità e interoperabilità che si ritrovano come Requisiti Generali di Prestazioni e Sicurezza al punto 14.5. Il nuovo Regolamento non andrà nella direzione dell’integrabilità dei sistemi.

A differenza della vecchia Direttiva, il nuovo Regolamento presenta (Allegato VIII) la regola 11 appositamente introdotta per i software. Essa è abbastanza generale in termini di situazioni prevedibili che sarà capace di assorbire il più delle possibilità concrete e proprio per questo, aumenterà mediamente la classe di rischio di un software.

In ultimo, è interessante notare che la verifica e convalida del software sono presenti nelle caratteristiche del dossier da presentare allo sperimentatore nel contesto di un’indagine clinica (Allegato XV, punto 2.3).

In conclusione, il nuovo Regolamento affronta più estesamente l’argomento software, correggendo molti aspetti dell’attuale Direttiva, ma non risolve uno dei problemi principali: le aspettative di integrazione fra dispositivi diversi, che da più parti (operatori in ambito medico) viene invocata. Forse una risposta potrà arrivare da norme armonizzate o specifiche comuni, ma dato l’aspetto fortemente vincolante per un progettista, potrebbe rimanere solo utopia (leggasi misure di sicurezza informatica come protezione contro accessi non autorizzati).

Scritto da: Amilcare Iacomino