La qualificazione e la classificazione dei software come dispositivi medici

Articolo pubblicato su Aboutpharma.com

Non vi è dubbio che la crescita dell’utilizzo delle tecnologie in sanità sia ormai uno degli argomenti di cui quotidianamente ormai si legge.  L’emergenza sanitaria di questa primavera e l’attuale crescita dei casi degli ultimi giorni, spinge infatti in maniera importante l’intero sistema verso una digitalizzazione che va dalla telemedicina, ai software di Ai che assistono i pazienti o agevolano l’attività diagnostica dei medici fino allo sviluppo delle Digital therapeutics.

La nozione di accessorio

Non vi è dubbio, poi, che molte di queste tecnologie sono (o dovranno) essere qualificate come dispositivi medici ai sensi del nuovo Mdr che ha ridisegnato (allargandola) la nozione di “accessorio” di dispositivo medico, facendo  rientrare sotto il cappello legislativo del Regolamento anche molti dei software che fino ad ora non erano considerati Dm (sul tema si legga  il nostro precedente articolo App e telemedicina, i profili giuridici con il nuovo regolamento Mdr ). Appare quindi di estrema importanza chiarire gli aspetti relativi al software as medical device (Samd) non solo lato regolatorio (in applicazione del Mdr) ma altresì sotto il profilo  giuridico in senso lato.

Questo articolo vuole dunque essere il primo di una serie di approfondimenti che affronteranno, in generale, le problematiche connesse alla progettazione, commercializzazione ed utilizzazione da parte delle strutture sanitarie e medici di Samd, analizzando quindi non solo la disciplina dell’Mdr, ma anche i profili più strettamente giuridici (quali, solo a titolo di esempio,  la sicurezza dei dati nei dm, i contratti di licenza, la responsabilità dell’utilizzatore, gli acquisti di software medicalo dopo maggio 2021 ecc.).

La classificazione del software

Il primo approfondimento riguarda ovviamente  la valutazione circa quali software dovranno essere considerati Dm (qualificazione giuridica) e, nel caso, a quale classe di rischio dovrà appartenere il Dm stesso (classificazione del software).

Sotto questi profili, infatti, l’Mdr introduce modifiche rilevanti, la cui portata innovativa è ben sottolineata dal Medical Device Coordination Group – e in particolare lo specifico sottogruppo New Technology – che nell’ottobre 2019 ha emanato la MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – Mdr and Regulation (Eu) 2017/746 – Ivdr. Obiettivo primario della Guida è – appunto – aiutare i fabbricanti ad individuare quando un software da loro prodotto debba essere immesso sul mercato o messo in servizio nel rispetto del Regolamento 745/2017 (qualificazione) e, altresì (2) a determinarne l’esatta categoria di rischio (classificazione).

Qualificazione giuridica: quando un software deve essere considerato dispositivo medico

Il Mdcg 2019-11 afferma in primo luogo che un software –  sia esso software stand-alone software o embedded (ovverosia incorporato in altro dispositivo medico) – diventa dispositivo medico quando ha uno “scopo medico”.

Tale scopo deve emerge ovviamente dalle funzionalità concrete del software, che rappresentano la sua destinazione d’uso del dm (art. 2 lett. 12 Mdr) e che devono essere chiaramente indicate nelle Informazioni del fabbricante (Allegato I punto 23.1 lett. a).

Nella sua operatività fattuale poi il software può avere scopo medico quando

1. controlla direttamente un dispositivo medico (hardware) (ad es. un software per il trattamento radioterapico),
2. fornisce informazioni decisionali mediche immediate (ad es. un software per la misurazione del glucosio nel sangue), o
3. fornisce supporto agli operatori sanitari (ad es. un software di interpretazione Ecg sulla base del quale il medico decide diagnosi e terapia).

La funzione di supporto agli operatori sanitari (punto 3) –  introdotta dall’ampliamento della nozione di “accessorio di dm” ai sensi dell’art. 2 lett. 2, secondo cpv. Mdr – è senza dubbio quella che maggiormente dilata l’ambito di applicazione dell’Mdr e quella che crea maggiori problemi interpretativi ed applicativi.

Sul punto infatti la Guida precisa che se in generale i software di “ricerca semplice” utilizzati in ambito sanitario (ad es. funzioni di ricerca bibliografica) non sono qualificati come dm, ove tale “ricerca” abbia come obiettivo quello elaborare i dati per supportare una decisone medica, il software dovrà farsi rientrare nella definizione di dm o di “accessorio di dm”.

Introducendo alcuni esempi,  si afferma che il software di “ricerca di immagini che supportano un’ipotesi clinica relativa alla diagnosi o all’evoluzione della terapia” oppure il “software che amplifica localmente il contrasto della scoperta su una visualizzazione dell’immagine in modo che serva da supporto decisionale o suggerisca un’azione da intraprendere da parte del medico” deve farsi rientrare nella nozione di dm (o meglio di “accessorio di dm”)  proprio in ragione delle funzione di supporto medico alla decisone del sanitario.

La linea di demarcazione tra dm e non dm appare quindi  molto labile ed un ruolo cardine sotto questo profilo sarà giocato dalla destinazione d’uso assegnata dal fabbricante, dalla indicazione d’uso (Allegato I punto 23) e dalle dichiarazioni nel materiale  ai sensi dell’art. 7 Mdr.

Ulteriori esempi (oltre a quelli contenuti nell’Allegato I della  Mdcg 2029-11) possono essere poi rinvenuti nel “Manual on borderline and classification in the Cummunity Regulatory Framework for medical devices” (versione 1.22 del 2019).

Regole per la classificazione

I profili poi della determinazione della classe di rischio del Samd ai sensi dell’Mdr sono anch’essi piuttosto dirompenti. Mentre oggi infatti (in vigenza della dir 93/42/Cee) la maggior parte dei dm rientrano in Classe I  (quindi senza la necessità dell’intervento del Nb), con Mdr moltissimi software dovranno entrare in Classi di rischio superiori (quindi con il coinvolgimento dei Nb: peraltro ad oggi dal sito NANDO risulta che sono solo 17 i Nb accreditati ex Mdr).

Più esattamente poi le regole di Classificazione sono contenute nell’Allegato VII. In primo luogo vengono introdotte  alcune regole che devono orientare la classificazione del software:

• Il software destinato a far funzionare un dispositivo o a influenzarne l’uso rientra nella stessa classe del dispositivo. Se il software non è connesso con nessun altro dispositivo, è classificato separatamente. (Allegato VIII punto 3.3)
• Se il dispositivo non è destinato a essere utilizzato esclusivamente o principalmente in una determinata parte del corpo, è considerato e classificato in base all’utilizzo più critico specificato (Allegato VIII punto 3.4)
• Se diverse regole o, nell’ambito della stessa regola, più sottoregole si applicano allo stesso dispositivo in base alla sua destinazione d’uso, si applicano la regola e sottoregola più rigorose che comportano la classificazione più elevata (Allegato VIII punto 3.5)

Per quanto riguarda poi la classificazione, rilevano le Regole dalla 9 alla 13 che si applicano a tutti i dispositivi attivi, tra cui rientrano tutti i software (ai sensi dell’art. 2 lett. 4), e in particolare la regola 11 che valorizza l’importanza – e vorrei dire il “peso sanitario” – dell’informazione fornita dal software al medico che deve assumere la decisione finale a fini diagnostici o terapeutici.

Sotto una schematizzazione della regola che ne permette una migliore comprensione:

Dall’analisi dei contenuti della regola appare chiaro che la determinazione della Classe di rischio discende proprio dal “livello di impatto” che l’informazione fornita dal software può avere sulla salute del paziente, in combinazione con la situazione di patologia nella quale si trova il paziente stesso. In sostanza la Regole 11 lavora sul “rischio di danno ai pazienti”.

Allo scopo poi di fornire criteri sul livello di rischio, in ossequio al Considerando 5 che valorizza le Guida Internazionali, la Mdcg 2019-11 richiama la  divisione per classi di rischio operata dal Imdrf: “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Consideration” del 2014, inserendo proprio la tabella del Imdrf (che sotto si riporta) nell’Allegato III (si precisa ched la Tabella non tiene conto dei software dm di classe I)

Conclusioni

Una considerazione finale. Senza dubbio la disciplina dei software è tra quelle più impattanti del Mdr. E senza dubbio la velocissima crescita della digitalizzazione in sanità dovuta al Covid ha accelerato un processo che, in condizioni di normalità, avrebbe avuto sì un suo sviluppo, ma non così incalzante. È quindi uno dei settori che richiede maggior attenzione e competenza.