App per la salute: nuove regole di classificazione come dispositivi medici

Search by...
Search
Questo articolo è stato pubblicato il 5 Febbraio 2020 su AgendaDigitale.eu, all’interno della nostra rubrica Legal Health.

Nell’ottobre 2019, il gruppo di coordinamento dei dispositivi medici della Commissione europea (MDCG) ha pubblicato una nuova guida sulla qualificazione e classificazione dei software come dispositivi medici ai sensi dei nuovi regolamenti sui dispositivi medici e sui dispositivi diagnostici in vitro (la “Guida“).

Dal momento che il nuovo quadro normativo assegna tendenzialmente a tali software una classe di rischio più elevata rispetto a quella attuale, come meglio spiegato di seguito, la Guida intende fornire alcuni chiarimenti ed esempi concreti per supportare gli operatori nell’interpretazione delle nuove regole.

La guida su software come dispositivi medici

La Guida mira a fornire chiarimenti ai produttori di software ad uso medico in merito a

  • questioni di qualificazione (ossia quando un software è considerato dispositivo medico);
  • in caso di software considerato dispositivo, questioni di classificazione, ossia la sua collocazione nell’appropriata classe di rischio.

Per quanto riguarda le regole di qualificazione di un software come dispositivo medico, al contrario che per le questioni relative alla classificazione dei software, non vi sono cambiamenti significativi rispetto all’attuale quadro normativo in cui, in assenza di criteri ad hoc stabiliti dalle direttive europee, il principale riferimento per gli operatori è rappresentato dalle linee guida della Commissione europea MEDDEV 2.1/6 (Medical Devices: Guidance document. Qualification and Classification of stand-alone software).

Considerata la velocità con cui la tecnologia si sta evolvendo, l’elenco degli esempi forniti dalla Guida è in costante aggiornamento. Analogamente, anche il “Manual on borderline and classification in the Community regulatory framework for medical devices” della Commissione Europea è attualmente oggetto di revisione per adattarlo ai nuovi regolamenti e al rapido progresso tecnologico, seppure gli esempi da esso forniti potranno continuare ad essere un utile riferimento per gli operatori, anche nel nuovo quadro normativo.

Software come dispositivi medici ai sensi del nuovo Regolamento

Secondo le nuove regole di classificazione previste dal regolamento europeo sui dispositivi medici (Regolamento) e in particolare la Regola 11, i software destinati a fornire informazioni utilizzate per prendere decisioni con scopi diagnostici o terapeutici oppure a monitorare i processi fisiologici sono generalmente collocati nella Classe IIa, che corrisponde a un livello di rischio intermedio (la scala è da I a III e comprende IIa e IIb). Laddove, invece, le decisioni da prendere con l’ausilio di un software possano in astratto impattare sulla vita dell’utilizzatore o causare un grave o irreversibile deterioramento del suo stato di salute, la classe di riferimento diventa più elevata (IIb o III).

Pertanto, in base al Regolamento, la maggior parte dei software probabilmente rientrerà nella classe IIa o superiore. Si tratta di una prima modifica molto significativa rispetto al precedente quadro normativo. Infatti, secondo le norme attualmente applicabili, come interpretate anche dalle linee guida MEDDEV 2.1/6, la maggior parte dei software è classificata come a basso rischio e rientra nella Classe I.

La differenza è sostanziale in quanto, mentre per i dispositivi di Classe I la valutazione dell’idoneità alla commercializzazione si svolge, in linea di massima, sotto la responsabilità esclusiva dei fabbricanti che, ai fini dell’apposizione della marcatura CE, redigono una dichiarazione di conformità, per i dispositivi di classi più elevate, il processo di marcatura CE richiede la certificazione da parte di un organismo notificato ed è quindi più lungo ed oneroso.

Quando un software è un dispositivo medico

La Guida non apporta alcuna modifica sostanziale ai criteri da utilizzare per valutare se un software debba o meno essere qualificato come dispositivo medico (ad esempio, la Guida include lo stesso albero decisionale delle linee guida MEDDEV 2.1/6).

A questo proposito, la Guida sottolinea che non tutti i software utilizzati nell’assistenza sanitaria sono qualificabili come dispositivi medici. Ad esempio, software che svolgono attività di semplice ricerca o recupero di informazioni non si qualificano come dispositivi medici (ad es. funzioni di libreria). Al contrario, il software destinato a elaborare, analizzare o modificare informazioni sanitarie può essere qualificato come dispositivo medico se la creazione o la modifica di tali informazioni è giustificata da uno specifico intento medico. Infatti, la finalità impressa dal produttore del software è essenziale per qualificarlo e classificarlo come dispositivo medico.

In particolare, come già illustrato nelle linee guida MEDDEV 2.1/6, per qualificare un software come dispositivo medico è necessario che lo stesso:

  • sia un programma informatico (e non un semplice documento digitale);
  • svolga una funzione diversa e ulteriore rispetto alla mera conservazione o trasmissione o ricerca di dati;
  • operi a beneficio di specifici pazienti;
  • svolga una delle funzioni incluse nella definizione di dispositivo medico (vale a dire diagnosi, prevenzione, controllo o terapia; studio, sostituzione o modifica dell’anatomia o di un processo fisiologico; intervento sul concepimento).

La Guida specifica inoltre che i criteri ivi riportati si applicano anche alle applicazioni (app), sia che siano istallate su un telefono cellulare, su un cloud o su altre piattaforme.

A questi criteri si aggiunge il principio stabilito dalla Corte di Giustizia che, con decisione del 7 dicembre 2017 (C.329/16), ha stabilito che è irrilevante, ai fini della qualificazione come dispositivi medici, il fatto che i software agiscano direttamente sul o nel corpo umano, essendo invece decisivo che essi siano stati destinati dal fabbricante ad essere impiegati per una o più delle finalità mediche rientranti nella definizione di dispositivo medico. Dunque anche un software che lavora unicamente sui dati dei pazienti allo scopo di fornire una diagnosi o una terapia può comunque essere qualificato come dispositivo medico anche se non prevede alcun contatto con il corpo umano.

Chiarimenti sui criteri di classificazione dei software/dispositivi

Se, dunque, sui criteri di qualificazione di un software come dispositivo medico non si hanno sostanziali novità nel nuovo quadro normativo, è sui criteri di collocazione di un software/dispositivo nell’appropriata classe di rischio che si evidenziano i principali cambiamenti apportati dal Regolamento e, quindi, il contributo più significativo della Guida.

Ad esempio, la Guida fornisce alcuni chiarimenti significativi sull’interpretazione delle Regola di classificazione 3.3 e 11 del Regolamento, fornendo esempi concreti.

In particolare, rispetto alla Regola 3.3 che stabilisce che il software destinato a far funzionare un dispositivo o a influenzarne l’uso rientra nella stessa classe del dispositivo, la Guida chiarisce che questa regola dovrebbe essere considerata come un orientamento per stabilire la classe minima in cui può essere collocato un software immesso sul mercato in combinazione con un dispositivo medico (hardware). Se però quel software/dispositivo persegue anche una finalità medica sua propria, allora deve avere una sua classificazione, che può anche essere più elevata (ma mai inferiore) rispetto a quella del dispositivo medico hardware.

Ciò è coerente con la Regola 3.5, che stabilisce l’importante principio generale secondo il quale, se più regole di classificazione si applicano allo stesso dispositivo in base alla sua destinazione d’uso, si applicherà la regola che porta alla classificazione più elevata.

Inoltre, la Guida contiene alcune considerazioni sull’immissione sul mercato del software e sulla sua valutazione di conformità. In particolare, stabilisce che un software/dispositivo può essere immesso sul mercato o messo in servizio a sé stante (ad es. una app), oppure come componente / parte integrante di un dispositivo (ad es. software che fa parte di un dispositivo hardware portatile destinato allo svolgimento di un test per determinare concentrazione di glucosio nel sangue). Nel primo caso, sarà soggetto ad un processo di valutazione autonomo; nel secondo caso, invece, il software/dispositivo dovrà essere valutato con la procedura applicabile al dispositivo nel suo insieme.

Tuttavia, la Guida non fornisce alcun chiarimento sul significato di “immissione sul mercato”, aspetto che sarebbe stato particolarmente utile specificare, alla luce le diverse modalità di commercializzazione di un software rispetto alla generalità dei dispositivi medici “fisici”.

Possibile approccio modulare

La Guida sottolinea che alcuni software/dispositivi possono essere suddivisi in vari moduli. Alcuni di questi moduli hanno uno scopo medico, altri no. Tali moduli possono essere intesi a coprire molte esigenze, ad esempio per raccogliere e conservare i dati amministrativi dei pazienti, per archiviare la storia medica dei pazienti o per la fatturazione e altre funzioni contabili. Ciò solleva il problema se l’intero prodotto può essere marcato CE quando non tutte le applicazioni hanno uno scopo medico.

In questo caso, la Guida chiarisce che è obbligo del produttore identificare i confini e le interfacce dei diversi moduli per individuare quali tra essi sono qualificabili come dispositivi medici. Solo questi ultimi devono essere conformi ai regolamenti sui dispositivi medici e devono recare la marcatura CE. I moduli non medici non sono invece soggetti ai requisiti per i dispositivi medici e non devono recare la marcatura CE.

Una classificazione mutevole

Infine, la Guida ricorda ai produttori che dovranno valutare il potenziale impatto di eventuali modifiche alla funzione, alla destinazione d’uso, alla progettazione essenziale e alle caratteristiche di produzione sulla qualifica del software come dispositivo medico e sulla sua classificazione (inclusa la classificazione della combinazione di un software/dispositivo con un altro dispositivo medico).

Infatti, una modifica o l’aggiunta di funzionalità a un software può comportare la qualificazione come dispositivo medico o una revisione della sua classificazione. Allo stesso modo, un modulo che viene aggiunto al software potrebbe essere qualificato come dispositivo medico da solo.

Recenti sviluppi

Il 17 dicembre, il Parlamento europeo ha approvato una rettifica del Regolamento (di cui si attende la pubblicazione sulla Gazzetta Ufficiale dell’UE), che aggiunge alcuni dispositivi classificati in Classe I ai sensi della precedente normativa tra quelli che possono beneficiare del periodo transitorio di non applicazione del Regolamento.

Pertanto, i produttori di questi dispositivi di Classe I possono continuare a immettere i propri dispositivi sul mercato ai sensi della precedente normativa fino al maggio 2024 ed essi possono restare a disposizione degli utenti finali fino al maggio 2025, purché: (i) la relativa dichiarazione di conformità sia stata redatta dai produttori prima del 26 maggio 2020 e (ii) non vi siano cambiamenti significativi nella progettazione e nella destinazione d’uso del dispositivo.

Ai sensi del testo originale del Regolamento, i dispositivi di Classe I, immessi sul mercato ai sensi della precedente normativa senza il coinvolgimento di un organismo notificato, dovevano conformarsi alle disposizioni del Regolamento entro il 26 maggio 2020, non potendo beneficiare delle disposizioni transitorie che consentono ai dispositivi certificati da organismi notificati di poter continuare ad essere immessi sul mercato ai sensi della precedente normativa anche oltre al maggio 2020.

Questa è sicuramente una buona notizia per i produttori di software che erano qualificati come dispositivi medici di Classe I ai sensi delle direttive europee, che potranno continuare a essere immessi sul mercato per altri 4 anni e avranno quindi più tempo a disposizione per adeguarsi ai nuovi oneri derivanti dalla più rigida classificazione prevista dal Regolamento. Tuttavia, ci sono ancora aspetti di queste disposizioni di rettifica che devono essere chiariti. Ad esempio, non è chiaro cosa si intenda per “cambiamenti significativi nella progettazione e nella destinazione d’uso del dispositivo” e chi verificherà o monitorerà se un determinato cambiamento sia o meno significativo, tale da compromettere la possibilità del dispositivo di continuare a beneficiare del periodo transitorio.

Article filed under: AgendaDigitale, Life Sciences
Back
Follow us on