Una breve guida sui criteri e le modalità con cui certificare un software come dispositivo medico.
I produttori di software ad uso medico devono attenersi al nuovo regolamento dispositivi medici 2017/745 (MDR), che prevede uno specifico iter di certificazione a seconda della classe di dispositivo medico in cui ricade. Secondo il nuovo MDR infatti, per dispositivo medico si intende qualsiasi strumento, apparecchiatura, software o altro, destinato dal fabbricante a essere impiegato sull’uomo […] per una determinata destinazione d’uso medica. Tra queste rientrano la diagnosi, la prevenzione, il monitoraggio, lo studio, la terapia ecc.
Facciamo un passo indietro. La prima domanda che un fabbricante di un software medicale dovrebbe porsi prima di poter ottenere il marchio CE e di immettere sul mercato il proprio prodotto è: il mio software è un dispositivo medico? È questo infatti l’aspetto cruciale da chiarire, il punto di partenza del processo di certificazione di un software ad uso medico. Per rispondere a questa domanda ci viene in aiuto una guida sulla qualificazione e classificazione dei software come dispositivi medici ai sensi del nuovo MDR, pubblicata dal gruppo di coordinamento dei dispositivi medici della Commissione Europea (MDCG), scaricabile all’indirizzo: https://ec.europa.eu/docsroom/documents/37581. Essa va in pratica a sostituire le vecchie linee guida della Commissione Europea MEDDEV 2.1/6 (Medical Devices: Guidance document. Qualification and classification of stand-alone software) relative alla Direttiva 93/42.
È fondamentale che il produttore del software definisca preventivamente la finalità d’uso dello stesso e il meccanismo d’azione, per capire se il prodotto rientri nella definizione di dispositivo medico secondo MDR. Solo in questo modo è possibile qualificare il prodotto come dispositivo medico e successivamente effettuare una corretta classificazione.
Quando un software è un dispositivo medico?
Per quanto concerne la qualificazione, rispetto alle precedenti linee guida MEDDEV, la nuova guida non apporta sostanziali modifiche. Essa sottolinea che non tutti i software utilizzati in ambito sanitario sono qualificati come dispositivi medici. Ad esempio, software che svolgono attività di ricerca semplice dei dati, memorizzazione, archiviazione, compressione e decompressione o recupero di informazioni non si qualificano come dispositivi medici (ad es. funzioni di libreria, cartelle cliniche elettroniche).
Al contrario un software con funzione di elaborazione, analisi, creazione o modifica di informazioni mediche, può essere considerato un dispositivo medico se la creazione o la modifica di tali informazioni è giustificata da uno scopo medico. Uno strumento molto utile in questa fase è lo schema decisionale riportato nella guida. Rispondendo a delle semplici domande, sulla base delle funzionalità e destinazione d’uso del software, il produttore è in grado inquadrare o meno il software come dispositivo medico.
A ciò si aggiunge anche il “Manual on borderline and classification in the Community regulatory framework for medical devices” della Commissione Europea, che riporta un elenco di esempi dei cosiddetti dispositivi borderline. Si definiscono dispositivi borderline quei prodotti per i quali non è facile stabilire con chiarezza l’appartenenza ad un determinato settore e per i quali quindi è difficile definire quale sia la normativa di riferimento da applicare. Il documento, sempre aggiornato, costituisce un riferimento importante per stabilire se un prodotto rientra nella definizione di dispositivo medico. In caso di dubbio saranno le Autorità competenti a decidere la collocazione caso per caso dei prodotti borderline.
È possibile la certificazione per singoli moduli?
Esiste la possibilità che alcuni software possano essere suddivisi in una serie di applicazioni, ciascuna correlata ad un modulo. Questa esigenza nasce dal fatto che alcuni di questi moduli hanno uno scopo medico e altri no. Tali moduli possono essere destinati a coprire molte esigenze, tra queste:
- raccogliere e conservare i dati amministrativi dei pazienti
- archiviare la storia medica dei pazienti
- fatturazione e altre funzioni contabili
- fornire un collegamento ai sistemi di prescrizione dei farmaci
Un esempio può essere quello delle cartelle cliniche elettroniche, destinate ad archiviare tutti i tipi di documenti e dati relativi ad un determinato paziente. Le cartelle cliniche elettroniche non devono essere qualificate come dispositivi medici. Una cartella clinica elettronica infatti, che sostituisce semplicemente la cartella clinica cartacea di un paziente non soddisfa la definizione di dispositivo medico.
Ciò solleva il seguente quesito: nel caso in cui non tutte le applicazioni abbiano uno scopo medico, l’intero prodotto deve essere marcato CE? La risposta è no. È obbligo del fabbricante identificare i diversi moduli per individuare quali tra essi sono qualificabili come dispositivi medici. Solo questi ultimi devono recare la marcatura CE ed essere conformi al MDR.
In figura uno schema che riassume gli step principali della qualificazione di un software.
In quale classe ricade il mio software?
Un altro aspetto delicato quando si ha a che fare con i software riguarda i criteri di collocazione del software/dispositivo nell’appropriata classe di rischio. Il nuovo regolamento mantiene la suddivisione in quattro classi di rischio (I, IIa, IIb e III), ma ha apportato importanti modifiche e aggiunte. Ciò comporta quindi per alcuni dispositivi una possibile ri-classificazione (per la maggior parte in classi di rischio superiori). È il caso della Regola 11 (Allegato VIII – MDR) appositamente introdotta per i software, riguardante i software per decisioni con finalità diagnostiche o terapeutiche o software per il monitoraggio dei processi fisiologici. Essa inciderà notevolmente sulla classificazione del software. Fino ad ora infatti, la maggior parte dei software rientrano nella Classe I, a causa dei limiti della Direttiva 93/42 che aveva trattato l’argomento software solo in maniera marginale. In essa e nelle successive modifiche veniva stabilito che il software deve essere considerato come un dispositivo medico attivo. Veniva inoltre resa necessaria la convalida del software secondo lo stato dell’arte, tenendo conto dei 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 nel senso più ampio del termine: le casistiche particolari riguardanti prodotti immateriali (come è poi un software in fin dei conti) non vengono menzionate.
La nuova regola 11 prevede requisiti molto più stringenti, che con molta probabilità comporteranno il passaggio di molti software a classi di rischio superiore. Questo implicherà il coinvolgimento di un Organismo Notificato e un iter diverso per la procedura di valutazione della conformità, che impatterà fortemente sui produttori di software (e sul settore in genere) in termini di budget e pianificazione temporale.
Qual è l’iter da seguire per la valutazione della conformità?
Una volta classificato il software è possibile effettuare la procedura per la valutazione della conformità, che poi porterà all’ottenimento del marchio CE. Le azioni e la documentazione cambiano in base alla classe del dispositivo medico. Si va dalla semplice dichiarazione di conformità ad opera del fabbricante stesso per i dispositivi di classe I, a valutazioni più complesse da parte di Organismi Notificati (come esame di tipo, valutazione del sistema di qualità ecc.) per dispositivi di classe superiore.
In tabella le procedure da effettuare per la valutazione della conformità a seconda della classe del dispositivo, evidenziando la necessità o meno dell’intervento di un organismo notificato. Per ulteriori dettagli si rimanda al testo del regolamento (Allegati da IX a XI).
Cosa succede se modifico il software?
I produttori dovranno prestare attenzione al potenziale impatto che eventuali modifiche alla funzione, alla destinazione d’uso, alla progettazione e alle caratteristiche di produzione possa avere sulla qualifica del software come dispositivo medico e sulla sua classificazione. Infatti, una modifica o l’aggiunta di funzionalità al software può comportare la qualificazione come dispositivo medico che prima non era considerato tale, o una revisione della sua classificazione. Ugualmente, un modulo che viene aggiunto al software potrebbe essere qualificato come dispositivo medico da solo.
Un ulteriore problema è relativo al passaggio dalla direttiva al nuovo regolamento. L’articolo 120, paragrafo 3 del MDR consente anche ai dispositivi che hanno acquisito la certificazione CE prima del 26 maggio 2021 secondo la direttiva 93/42/CEE, di essere immessi sul mercato fino al 26 maggio 2025 a patto che non vengano apportate modifiche significative al design o allo scopo previsto del dispositivo dopo il 26 maggio 2021. Se il fabbricante desidera effettuare una «modifica significativa della progettazione o della destinazione d’uso» ciò impedirebbe al fabbricante di continuare a commercializzare il dispositivo ai sensi della direttiva.
Quando la modifica può influire sul progetto o sulla destinazione d’uso del dispositivo, la rilevanza di tale modifica deve essere valutata caso per caso. Nella guida MDCG 2020-3 vengono riportati diagrammi di flusso utili alla comprensione delle modifiche significative.
Cosa si intende per modifiche significative?
- Un nuovo o importante cambiamento del sistema operativo o di qualsiasi componente
- Una nuova architettura o struttura di database, una modifica di un algoritmo
- Si introduce un algoritmo a circuito chiuso come input al sistema
- Nuova funzionalità diagnostica o terapeutica, o nuovo canale di interoperabilità
- Nuova interfaccia utente o presentazione dei dati [1]
Sono invece considerati non significativi i seguenti cambiamenti:
- I cambiamenti amministrativi delle organizzazioni (cambiamenti di nome, indirizzo o forma giuridica del produttore o cambiamenti del rappresentante autorizzato)
- Tutte le modifiche che non hanno un impatto sulla progettazione o sulla destinazione d’uso del dispositivo (trasferimento o aggiunta di nuovi siti di produzione, modifiche del sistema di gestione della qualità a condizione che siano mantenute le condizioni per le quali è stata concessa la certificazione di valutazione della conformità)
Infine, cambiamenti minori senza impatto per la diagnosi o per il trattamento fornito possono includere:
- La correzione di un errore che non rappresenta un rischio per la sicurezza (bug fixes)
- Miglioramento della sicurezza informatica
- Modifiche atte a migliorare l’aspetto dell’interfaccia utente (che può includere nuove lingue, layout o grafica) senza cambiamenti nelle prestazioni
- Efficienza operativa
In ogni caso il fabbricante deve giustificare la decisione di apportare determinate modifiche considerate non significative. Tale giustificazione deve essere documentata e resa disponibile quando richiesto.
Ha collaborato Fabrizio Battaglia
[1] La presentazione dei dati è diversa dall’aspetto dell’interfaccia utente. Essa è collegata a dati medici che vengono rappresentati in un nuovo formato o con una nuova dimensione o unità di misura.