Digital Med

Software in sanità e MDR: il nuovo quadro normativo

Gli ultimi due anni hanno visto crescere in maniera esponenziale i software utilizzati in area sanitaria: quelli all'interno degli ospedali, ed altresì i c.d. software stand alone (come le APP). Dal 26 maggio 2021 a tali software deve essere applicato il nuovo Reg. Ue 2017/45 (c.d. Medical device regulation - MDR), che introduce importanti novità in materia.

Gli ultimi due anni hanno visto crescere in maniera esponenziale i software utilizzati in area sanitaria: quelli all’interno degli ospedali, ed altresì i c.d. software stand alone (come le APP).

Dal 26 maggio 2021 a tali software deve essere applicato il nuovo Reg. Ue 2017/45 (c.d. Medical device regulation – MDR), che introduce importanti novità in materia.

I punti cardine da analizzare sono due:

  • stabilire quando un software/una App diventano dispositivo medico o accessorio, rientrando quindi nella disciplina di cui al MDR
  • nel caso in cui software/app rientri nella nozione di medical device, stabilire quale classe di rischio si debba applicare alla luce della nuova disciplina e quindi applicare le relative prescrizioni del MDR

La qualificazione giuridica del software 
I nuovi orizzonti aperti in materia di software con il nuovo MDR erano già stati anticipati dalla sentenza della Corte di Giustizia Comunità Europee 7 dicembre 2017 - C 329/16.

La sentenza ha deciso infatti su una controversia promossa dalla associazione francese Sniterm (imprese tecnologia medicale) nel corso della quale si chiedeva 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 stesso non risulta impiegato “nel” o “sul” corpo umano.

La Corte, partendo dal Considerando 6 della dir 2007/47, ha dichiarato 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 qualificare 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 agiscano 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 ampliamento giurisprudenziale è stato poi oggi ripreso e rinforzato nel nuovo MDR, che al considerando 19 così stabilisce “È necessario precisare che il software specificamente destinato dal fabbricante a essere impiegato per una o più delle destinazioni d’uso mediche indicate nella definizione di dispositivo medico si considera un dispositivo medico, mentre il software destinato a finalità generali, anche se utilizzato in un contesto sanitario, o il software per fini associati allo stile di vita e al benessere non è un dispositivo medico. La qualifica di software, sia come dispositivo sia come accessorio, è indipendente dall’ubicazione del software o dal tipo di interconnessione tra il software e un dispositivo”.

L’art. 2 lett. 2 MDR nella nozione di “accessorio” (art. 2 lett 2 MDR) ricomprende poi tutti i prodotti che “assistono la funzionalità sul piano medico di un DM”: tale ampliamento fa rientrare nell’ambito del MDR molto software che prima esano esclusi.

Per aiutare poi i fabbricanti a capire se un software rientra o meno nella nozione di dm, il Medical Device Coordination Group ha emanato la guida la MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745.

Tale guida 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 controlla direttamente un dispositivo medico (hardware) (ad es. un software per il trattamento radioterapico), fornisce informazioni decisionali mediche immediate (ad es. un software per la misurazione del glucosio nel sangue), o 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” sopra citata – è 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 poi 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)

Classificazione del rischio del software 
Stabilito poi che una software/una App rientra nella disciplina del MDR occorrerà determinarne la classe di rischio, da cui derivano i successivi adempimenti.

Sotto questo profilo, occorre tenere in considerazione le regole di Classificazione contenute nell’Allegato VIII del MDR, nonché la sopra citata MDCG 2019-11 e la recentissima MDCG 2021-24 - Guidance on classification of medical devices.

Vediamo in sintesi tale regole.

In primo luogo l’allegato VII introduce alcune regole generali 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)
Inoltre occorre tenere in considerazione 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).

La regola specifica per i software è poi la Regola 11.

Tale regola 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.

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 nell’Allegato III.

Conclusioni
Non vi dubbio che la disciplina dei software è tra quelle più impattanti del Mdr.

La velocissima crescita della digitalizzazione in sanità dovuta al Covid ha poi accelerato un processo che, in condizioni di normalità, avrebbe avuto sì un suo sviluppo, ma forse non così incalzante.

È quindi uno dei settori che richiede oggi maggior attenzione e competenza.