Quali profili giuridici occorre tenere in considerazione?
La progettazione, lo sviluppo e la commercializzazione di una Digital Therepeutic vede coinvolti (quasi sempre) più soggetti: una società committente (solitamente azienda Pharma o medical device) ed una software house che realizza il DTx.

Si tratta di un progetto complesso che va valutato nei suoi diversi aspetti, se possibile sin dall’inizio dei lavori, per non dover poi modificare adempimenti e responsabilità in corso d’opera.

Ma quali sono con esattezza gli specifici profilo giuridici da tenere in considerazione e, presumibilmente, da disciplinare all’interno di un contratto tra le parti?
Vediamoli insieme

Qualificazione giuridica della DTx come medical device
Le Digital Therapeutics sono App qualificate giuridicamente come dispositivi medici: quindi la loro progettazione e immissione sul mercato è disciplinata oggi dal Reg. Ue 2017/745 (c.d. MDR) che prevede l’apposizione della marcatura CE prima dell’immissione sul mercato.
Si tratta di una disciplina piuttosto complessa e di recente applicazione, tenuto conto che il MDR è  divenuto pienamente efficacie a maggio 2021: pertanto i temi interpretativi aperti sono ancora molti e piuttosto articolati.

E’ del tutto evidente, quindi, che la software house che progetta e realizza il DTx dovrà avere piena conoscenza del MDR ed essere in grado di tenerne in considerazione tutta la disciplina.

In particolare, ai fini della apposizione della marcatura CE, la progettazione del DTx dovrà rispettare  tutti i pertinenti  Requisiti Generali di Sicurezza e Prestazione (c.d. RGSP) di cui Allegato I del MDR: sotto questo profilo avranno particolare rilevanza oltre ai requisiti di sicurezza dati e di cybersecurity (Allegato I punto 17), anche i requisiti di “usabilità” della app (Allegato I punto 14.6) che mirano a valutare i rischi  da caratteristiche ergonomiche inadeguate (allegato I punto 14.2) allo scopo di  eliminare o ridurre i rischi connessi agli errori d’uso (paragrafo 3 c):  e’ innegabile infatti che la DTx è utilizzata direttamente dal paziente e che quindi la sua  efficacia clinica non può prescindere da una facile e corretta utilizzazione della app stessa.

Il rispetto poi degli RGSP deve essere poi provata attraverso specifici test di sicurezza e clinici, la creazione di un fascicolo tecnico (allegato II MDR) e la redazione di una Valutazione Clinica (art. 61 MDR) basata su dati clinici (art. 2 lett. 48); nello specifico tali dati clinici possono essere tratti dalla letteratura scientifica o, in carenza, da indagini cliniche appositamente svolte: tenuto conto che i DTx rappresentano una nuova frontiera del software è del tutto presumibile che sarà necessario svolgere apposite indagini cliniche e che quindi le parti dovranno stabile chi assumere il ruolo di Sponsor dell’indagine clinica e valutarne i relativi costi.

Ulteriore elemento su cui appare opportuno un confronto tra committente e fornitore sono i ruoli soggettivi ex MDR che la parti andranno ad assumere ai fini della commercializzazione.

Il MDR infatti stabilisce che il soggetto che si qualifica sul mercato come Fabbricante (indipendentemente dalla circostanza che abbia realizzato personalmente o meno il dm – art. 2 lett. 30 MDR) assume la responsabilità giuridica della compliance del  dispositivo al MDR stesso (art. 10), svolgendo altresì tutti i compiti previsti dopo l’immissione sul mercato che ricomprendono non solo la manutenzione e gli eventuali upgrade, ma altresì  la sorveglianza post commercializzazione (art. 83 MDR), comprensiva del  post marketing follow up (allegato XIV parte B) nonchè la vigilanza sul dm (art. 92 MDR).

Sarà quindi opportuno che la parti – pur in carenza oggi di un quadro normativo sui rimborsi di tale tipologia di software – valutino insieme chi assumerà il ruolo di Fabbricante e chi (nel caso) quello di distributore (art. 14 MDR).  

I dati per creare una DTx.
Un elemento spesso sottovalutato  è la necessità di poter accedere a dati sanitari per poter creare la DTx e poi successivamente testarla.

Tale elemento è invece di assoluta rilevanza, tenuto conto che dati acquisiti in maniera illegittima potrebbero inficiare l’intero lavoro di sviluppo della App (art. 2 -diecies Codice Privacy).

Sotto questo profilo, si evidenzia che nella fase iniziale di progettazione molto spesso vengono utilizzati dati tratti da data base nazionali, europei o internazionali.
In questo caso occorre prestare particolare attenzione ai contenuti della licenza d’uso che consente di “usare” i dati.

In conformità alla normativa comunitaria (Direttiva 96/9/CE) infatti, l'autore del database ha il diritto esclusivo di riprodurre, distribuire, tradurre o adattare l'opera, nonché di vietare l'estrazione e il riutilizzo della totalità o di una parte sostanziale del database. Pertanto, i dati presenti nei database possono essere concessi in licenza dall'autore, con specifiche indicazioni sulle modalità e le finalità di utilizzo dei dati, la condivisione consentita o vietata, i soggetti autorizzati ad accedere e le eventuali sanzioni in caso di violazione.

Sotto questo profilo è molto comune che l'accesso ai database avvenga attraverso licenze concesse gratuitamente solo per fini di ricerca scientifica, escludendo quindi l'uso commerciale. Nel caso in cui si desideri utilizzare i dati presenti in un database concesso in licenza per scopi commerciali (come nel caso dello sviluppo di una DTx che verrà poi immessa sul mercato) , è necessario verificare che la licenza consenta l'utilizzo dei dati per scopi di lucro, inclusi l'addestramento e la validazione di algoritmi: se ciò non è previsto dalla licenza, occorre tentare di negoziare specifiche licenze di utilizzo con il titolare del database al fine di poter includere i risultati ottenuti nel software destinato alla commercializzazione.

Ulteriore opzione è quella di utilizzare dati tratti da Registri pubblici (occorre verificare se tali dati sono condivisibili sotto il profilo della protezione del dato) oppure banche dati Open (e qui occorrerà capire se  la licenza s’uso del dato consente di utilizzarlo per scopo profit) oppure ancora Real World Date (dove però al momento è chiesta da parte delle strutture sanitarie l’applicazione dell’art. 110 Codice Privacy, molto stringente.

Infine è anche possibile oggi, in forza del DM 30 novembre 2021 che consente la cessione dal dato da parte di ospedali che li abbiano raccolti nell’ambito di uno studio no profit, alla condizione che ci sia una corretta valorizzazione economica della cessione.

Infine la validazione finale del DTx avverrà, nella maggioranza dei casi, attraverso indagini cliniche (cui già sopra accennato), in ragione del fatto che la prova del beneficio clinico del DTx ai fini della apposizione della marcatura CE dovrà essere data attraverso l’utilizzo reale sul paziente.

In questo caso di dovrà seguire la disciplina degli art. 62 e seg. del MDR.

Protezione dei dati 
E’ poi del tutto pacifico che una APP utilizzata dai pazienti tratta i dati degli stessi ai sensi del Reg. Ue 2016/679 (c.d. GDPR).

Sotto questo profilo occorrerà tenere in considerazione vari aspetti.

Il primo è senza dubbio quello della sicurezza della APP, già sopra accennato nell’ambito del RGSP di cui all’Allegato I del MDR: nello specifico poi i profili di Cybersecurity sono specificamente approfonditi per i software medicali in una linea guida comunitaria del Medical Device Coordination Group, la MDCG 2019-16 Guidance on Cybersecurity on medical device.

Il secondo profilo richiede, per certi versi, una visione più ampia.

Occorrerà infatti tenere in considerazione - già dalla fase di progettazione - che la DTx diventerà parte di un processo clinico gestito dalla struttura sanitaria e dai suoi medici: occorrerà pertanto rispettare i principi di privacy by design e by default di cui all’art. 25 del GDPR, immaginando l’intero processo clinico.

In altre parole, le scelte progettuali del software dovranno tenere in considerazione che la tecnologia sarà parte della cura medica e che il titolare del trattamento dei dati per diagnosi e cura sarà la struttura sanitaria che ha in carico il paziente: ne deriva non solo che occorrerà immaginare una interfaccia della APP ideona al rilascio della informativa ex art. 13 GDPR o all’eventuale raccolta di eventuali consensi quali basi giuridiche ad hoc, ma anche che per tali tipologia di APP sarà opportuno redigere un documento ad hoc contenente l’analisi del rischio sul trattamento dei dati e sulle misure di protezione implementate da consegnare alla struttura sanitaria titolare dei dati del paziente per metterla nella condizione di svolgere la Valutazione d’Impatto ex art. 35 GDPR.

Non è un obbligo, ma certamente di una soluzione molto utile e molto gradita alle strutture sanitarie.

La tutela autoriale e brevettuale della DTx.
La DTx può essere poi un bene suscettibile di tutela per la sua innovatività.

Sotto questo profilo, secondo la normativa italiana, la tutale della proprietà intellettuale  può essere ottenuta attraverso il diritto d'autore o la tutela brevettuale.

La tutela del diritto d'autore
In base alla legge 633/1941 sul diritto d'autore, i "programmi per elaboratore" sono considerati opere letterarie.

L'autore del programma (quindi la software house) è titolare di diritti morali (che non possono essere ceduti e comprendono il diritto alla paternità dell'opera) e diritti patrimoniali, che possono invece essere trasferiti e consentono altresì lo sfruttamento economico dell'opera.

Occorrerà quindi che le parti stabiliscano sin dall’inizio del progetto se la proprietà del software rimarrà in capo alla software house oppure se verrà trasferita al committente, disciplinando nel contratto sia le modalità di trasferimento del codice sorgente sia la cessione dei diritti patrimoniali di sfruttamento dell’opera.

La tutela brevettuale
La tutela brevettuale presenta profili molto interessanti.

Secondo l'articolo 45, comma 2, lettera b) del nostro Codice della proprietà industriale italiano, infatti, i programmi per elaboratore non sono considerati invenzioni e non possono essere brevettati.

Tuttavia, l'Ufficio Europeo Brevetti (EPO) ha recentemente aggiornato le sue linee guida per includere una sezione specifica sulla brevettabilità delle invenzioni che coinvolgono l'IA, definite anche come "computer-implemented inventions" (CII): tale linea guida precisa che affinchè un software possa essere brevettabile, deve essere incorporato in un'invenzione che soddisfi i seguenti requisiti:

• novità: l'invenzione deve essere inedita, ovvero non deve essere già parte dello stato dell'arte.
• originalità: l'invenzione deve essere originale e non facilmente deducibile rispetto a ciò che è già di pubblico dominio.
• applicazione industriale: l'invenzione deve avere uno scopo industriale, non solo commerciale.

Inoltre, affinché l'IA possa essere brevettabile, deve presentare un carattere tecnico contribuendo a fornire una soluzione a un problema tecnico. Inoltre, devono essere soddisfatti i requisiti di chiarezza, concisione e sufficiente descrizione, in modo che un esperto del settore sia in grado di attuare l'invenzione leggendo la domanda di brevetto.

L'interpretazione della Convenzione europea sui brevetti consente quindi all'EPO di autorizzare la brevettabilità di tecnologie basate sull'intelligenza artificiale in vari settori tecnologici come dispositivi medici, settore automobilistico, media e comunicazione, e altri. Il titolare del brevetto avrà diritti di proprietà industriale sull'invenzione per un periodo di 20 anni dalla data di deposito dell'invenzione.

Tale apertura dell’EPO riguarda i programmi per elaboratore in quanto tali, con una specifica attenzione agli algoritmi di  AI, e potrebbe senza dubbio coinvolgere anche le DTx che per la loro funzione specifica potranno (facilmente) presentare software che rispettino i requisiti di brevettabilità,  anche qualificabili come Intelligenze artificiali ai sensi del futuro Regolamento sulla AI.

Anche tale possibile profilo dovrà essere valutato dalle parti, nei suoi aspetti di natura contrattuale ed economica.