Avv. Silvia Stefanelli
Studio Legale Stefanelli&Stefanelli, Bologna-Milano-Roma
Tendenze Nuove, Numero 2 – 2021; 10-14: DOI: 10.32032/TENDENZENUOVE20210202.PDF
Che il mondo delle App in area sanitaria sia in piena esplosione è un fatto ormai noto: non vi è ricerca che non evidenzi dati in questa direzione.
Un po’ meno noto – anzi direi decisamente più complesso – è capire quando una App è dispositivo medico oppure rimanga App di area wellness. Tale profilo risulta a volte complesso non solo per il paziente o altri soggetti quali distributori e/o operatori sanitari che non sanno bene dove andare a cercare con esattezza questa informazione, ma altresì per il fabbricante della App che si trova oggi a dover decidere la quali cazione giuridica del proprio software, decidendo poi – di conseguenza – quale disciplina giuridica applicare.
Infatti se si tratta di una App di wellness si applicherà la generale dir 2001/95/CEE sulla sicurezza generale dei prodotti; se invece la App, per le funzionalità specifiche che presenta, rientra nella nozione giuridica di dispositivo medico dovrà trovare oggi applicazione il nuovo Reg. Ue 2017/745 in materia di dispositivi medici (c.d. MDR – Medical Device Regulation), divenuto pienamente efficace il 26 maggio 2021.
Trattandosi quindi di una disciplina “nuova” (peraltro piuttosto complessa), la sua interpretazione ed applicazione presenta ancora qualche profilo di incertezza, dovuto anche alla dif coltà “intrinseca” di combinare la lettura giuridica con la realtà tecnico-informatica (ove il giurista deve parlare la lingua dell’ingegnere e quest’ultimo imparare e muoversi nei meandri del diritto).
A ciò si aggiunga che il nuovo MDR ha modificato, allargandola, la nozione di Software As Medical Device (c.d. SAMD): quindi molti software che in vigenza della precedente disciplina (Direttiva 93/42/CEE) non erano SAMD, oggi lo sono diventati.
Da ultimo l’MDR ha fortemente alzato il livello di analisi e di adempimenti circa la valutazione clinica dei dispositivi in genere (e quindi anche del SAMD), coinvolgendo non solo i profili di sicurezza del dispositivo ma altresì quelli di ef cacia clinica.
In sostanza chi si trovi a voler sviluppare una App in area sanitaria dovrà
• capire in primo luogo se tale App deve essere certificata CE come dispositivo medico oppure se può restare al mondo del wellness;
• ove poi il software, per le sue funzionalità, debba farsi rientrare nella nozione di DM, occorrerà redigere idoneo business plan economico che tenga conto degli step per il raggiungimento della marcatura CE e del successivo mercato di riferimento;
• ed infine, ove si decida di procedere, occorrerà implementare competenze umane, tecniche, organizzative e gestionali idonee per arrivare alla marcatura CE nel rispetto di tutto l’MDR.
Questi step sono indispensabili per poter arrivare all’obiettivo.
Purtroppo oggi non basta più avere una buona idea, un ottimo team di ingegneri o dei clinici entusiasti: questo è solo il punto di partenza, non quello di arrivo.
A valle però si avrà una App che potrà effettivamente svolgere un ruolo in ambito clinico, tranquillizzando anche quei sanitari che manifestano ancor oggi il proprio scetticismo circa la “sicurezza” e, soprattutto, l“efficacia clinica” dei Software As Medical Device.
Ora, tralasciando in questa sede la questione della rimborsabilità economica di tali App da parte del sistema pubblico (tema che richiederebbe un approfondimento a sé stante), obiettivo di questo articolo è solo quello di dare un contributo, di natura prettamente giuridica, per rispondere alla prima domanda: quando una App (o un software) deve essere qualificata come dispositivo medico?
Sia permesso a tal fine un brevissimo excursus storico giuridico (anche perché se non si conosce la storia non si può capire il presente).
Il dispositivo medico nasce, da un punto di vista strettamente giuridico, nel 1993 con la Direttiva 93/42/CEE. Nella prima versione della direttiva il software non era neppure citato come dispositivo medico (DM) a sé stante (poteva ovviamente essere parte di DM più complesso – il c.d. software embedded).
Nel 2007 invece con la Dir 2007/47 (di modifica della dir 93/42/ CEE) il software entra nella nozione di DM: da quel momento in poi anche il software “stand alone” se svolge le funzioni tipiche di un DM può/deve essere qualificato come dispositivo medico. A tale apertura hanno poi fatto seguito documenti interpretativi comunitari, quali la MEDDEV 2.1/6 – Guidance document Medical Devices – Scope, field of application, definition – Qualification and Classification of stand alone software.
Nel 2017 poi, a pochi mesi dalla pubblicazione in Gazzetta Ufficiale del Reg. Ue 2017/745 è stata pubblicata la sentenza della Corte di Giustizia Comunità Europee 7 dicembre 2017 – C 329/16.
Il caso è questo: l’associazione francese Sniterm (imprese tecnologia medicale) chiedeva (nel corso di una causa) alla Corte di Giustizia di valutare se il software che presenti “una funzionalità che consenta l’utilizzo dei dati personali di un paziente al fine di aiutare il suo medico nella predisposizione della sua prescrizione, in particolare rilevando le controindicazioni, le interazioni con altri medicinali e le posologie eccessive” debba o meno essere considerato dispositivo medico, tenuto conto in particolare che lo stepso non risulta impiegato “nel” o “sul” corpo umano.
La Corte, partendo dal Considerando 6 della dir 2007/47, dichiarava che il software può essere dispositivo medico anche senza impiego “sull’uomo”: secondo i Giudici della Corte quindi “il legislatore dell’Unione ha inteso concentrarsi, per quali care un software come dispositivo medico, sullo scopo del suo utilizzo e non sul modo in cui può concretizzarsi l’effetto che è in grado di produrre sul o nel corpo umano”: di conseguenza “ai fini della qualificazione di dispositivo medico, il fatto che un software agisca direttamente o non agisca direttamente sul corpo umano, non è rilevante, essendo invece fondamentale che la finalità indicata dal fabbricante sia una di quelle previste per la definizione stessa di dispositivo”.
Tale sentenza apre oggi la strada ad una interpretazione molto ampia – molto più ampia di prima – alla qualificazione giuridica di Software As Medical Device.
In altre parole attrae nell’ambito applicativo del MDR non solo i software che agiscono direttamente sul paziente, ma anche tutti quelli (molto più numerosi) che forniscono dati ed informazioni al medico (e/o oggi anche al paziente stesso) in grado di “influenzare” le valutazioni cliniche relative al paziente stesso.
Chiarito tale ampio criterio interpretativo stabilito dalla Corte di Giustizia, vediamo ora la nozione di dispositivo medico ed i casi di conseguente applicazione nell’ipotesi di App.
L’art. 2 lett. 1 stabilisce che rientra nella nozione di DM
qualunque strumento, apparecchio, apparecchiatura, software, impianto, reagente, materiale o altro articolo, destinato dal fabbricante a essere impiegato sull’uomo, da solo o in combinazione, per una o più delle seguenti destinazioni d’uso mediche specifiche:
• diagnosi, prevenzione, monitoraggio, previsione, prognosi, trattamento o attenuazione di malattie;
• diagnosi, monitoraggio, trattamento, attenuazione o compensazione di una lesione o di una disabilità:
• studio, sostituzione o modifica dell’anatomia oppure di un processo o stato fisiologico oO patologico.
Ora, dato atto che il software (composto di algoritmi) è “a set of instructions that processes input data and creates output data” – (MDCG 2019- 11), è del tutto chiaro che la qualificazione come dispositivo medico (o meno) dipende dalla “destinazione d’uso” che il fabbricante determina per il suo software.
La destinazione d’uso, a sua volta, è “l’utilizzo al quale è destinato un dispositivo secondo le indicazioni fornite dal fabbricante sull’etichetta, nelle istruzioni per l’uso o nel materiale o nelle dichiarazioni di promozione o vendita e come specificato dal fabbricante nella valutazione clinica (art. 2 lett. 12 MDR).
In sostanza la qualificazione di DM dipende da “cosa fa” il software (cioè quale tipologia di elaborazione effettua sui dati in ingresso rispetto ai dati in uscita), ma ancor di più dalla destinazione d’uso che il fabbricante determina per il software stesso, la quale emerge dalla documentazione che accompagna il software (informazioni d’uso) ma altresì dal materiale promozionale, dal sito web, dalle dichiarazioni in sede di presentazione del dispositivo.
Ricapitolando, dunque, se le funzionalità del software sono tali da fornire informazioni che il fabbricante dichiara possano essere utilizzate per fare una “diagnosi”, oppure svolgere una attività di “prevenzione”, oppure “monitoraggio” ecc. in relazione ad un soggetto affetto da una malattia, il software sarà un dispositivo medico.
Al contrario, ove il software non sia in grado di svolgere tali funzioni o comunque non sia destinato dal fabbricante a svolgerle, non entrerà nel mondo dei DM.
Proviamo a fare un esempio, magari po’ borderline, giusto per cercare di chiarire.
Immaginiamo di progettare e sviluppare una chatbot che fornisca indicazioni nell’ambito di un flusso conversazionale a soggetti che hanno o possono avere problemi di natura psicologica.
Qui non vi è dubbio che il processo informatico è chiaro: il paziente inserisce informazioni in ingresso, l’algoritmo elabora tali informazioni, cui esita la risposta del chatbot indirizzata al paziente stesso.
Ora questo è il tipico caso in cui, a seconda della destinazione d’uso del dispositivo e quindi della tipologia di risposta che il fabbricante decide (è in grado) di fornire, la App può o meno essere classificata come dispositivo medico.
Se la App infatti si rivolge a soggetti sani (nel senso che l’interlocutore del chatbot è persona sana che magari vuole solo monitorare il suo equilibrio mentale) e fornisce risposte che attengo solo all’aumento del benessere (indicazioni su stile di vita, suggerimenti sull’alimentazione o sull’utilizzo del proprio tempo ecc..) la App potrà non essere classificata come DM. In questo caso appare poi fortemente opportuno dare indicazioni precise sull’interlocutore a cui si rivolge la App attraverso le indicazioni per l’uso, il sito web o le altre forme promozionali che si decidono di implementare.
Ove invece la App si rivolga a soggetti che presentano patologie di natura psicologica – o che solo pensano di avere tale patologia e che quindi stanno cercando una soluzione a problemi veri o presunti – e altresì le risposte fornite (anche per i termini utilizzati quali “depressione”, “disturbo mentale”, “ansia”, ecc) attengono a suggerimenti di natura clinica o comunque suggerimenti in grado di in uenzare il paziente nei suoi comportamenti e/o nella valutazione del suo stato di salute, la App sarà sicuramente un dispositivo medico in quanto svolgerà (o comunque si presenta come in grado di svolgere) una funzione di “monitoraggio” o “attenuazione” di una situazione di malattia.
Chiaro che in questo ultimo caso, data la qualificazione giuridica come SAMD, la App dovrà seguire tutto l’iter di certificazione CE previsto dall’MDR (oggi per i software piuttosto lungo e complesso) che passa attraverso l’analisi del funzionamento dell’algoritmo, la sua efficacia sotto il profilo clinico (art. 61 MDR) ed il rispetto dei pertinenti Requisiti Generali di Sicurezza e Prestazione (Allegato I).
