Senza dubbio l’impatto dell’Mdr sui software medicali è di estrema rilevanza, non solo in fase di progettazione e classificazione del Dm (si veda il nostro precedente articolo La qualificazione e la classificazione dei software medicali), ma anche in fase di immissione in commercio e/o utilizzazione da parte degli operatori sanitari e conseguente responsabilità. I dubbi si pongono in relazione ai software marcati Ce ex Dir. 93/42/Cee (Mdd) e altresì ai software che risultano già installati ma che non sono marcati né Mdd né Mdr. Vediamo i possibili scenari.
Il primo dubbio è questo: cosa succede se un Software As Medical Device (Samd) non riesce ad ottenere la marcatura ex Mdr prima del 26 maggio 2021? Come noto, l’art. 120 MDR comma 3 (come modificato dal Reg. Ue 2020/561) stabilisce che i Dm di Classe I ex Mdd che salgono di Classe ex Mdr (ed è proprio il caso tipico dei Samd che con l’Mdr per lo più aumentano di Classe) possono essere immessi sul mercato fino al 26 maggio 2024 con marcatura ex Mdd ove la Dichiarazione di conformità sia stata emessa prima del 26 maggio 2021. In altre parole: il fabbricante di Samd che emette la Dichiarazione di conformità ex Mdd prima del 26 maggio 2021 può immettere sul mercato il software fino al 26 maggio 2024.
Tenuto poi conto che l’immissione sul mercato è la “prima messa a disposizione” (art. 2 lett. 28) e che “la messa a disposizione” è la “fornitura di un dispositivo … per la distribuzione, il consumo o l’uso…”(art. 2 lett. 27) sembra potersi affermare che, per quanto riguarda un software, l’immissione sul mercato potrà farsi coincidere (nella maggioranza dei casi) con la firma del contratto di licenza d’uso del software stesso, che quindi potrà avvenire fino a maggio 2024.
Tale deroga (che in effetti sembra dare una boccata di ossigeno al settore) è però condizionata.
La stesso art. 120 stabilisce infatti che si può usufruire di tale periodo transitorio a condizione che “non vi siano cambiamenti significativi nella progettazione e nella destinazione d’uso” del dm. Cosa significa nel caso di un software? Sul punto è intervenuto un documento specifico del Medical Device Coordination Group titolato Mdcg 2020-3 Guidance on significant changes regarding the transitional provision under Article 120 of the Mdr with regard to devices covered by certificates according to Mdd or Aimdd.
Tale documento contiene una analisi puntuale di cosa deve intendersi per “cambiamento significativo”, illustrando in particolare l’ipotesi dei cambiamenti nel caso del software.
Più esattamente un intervento – pensiamo ad un upgrade del software – deve considerarsi “significativo” quando
Sono invece considerate modifiche minori – quindi non “significative” e non impattanti sulla marcatura – quelle relative a
In sostanza si ha un “cambiamento significativo” quando si interviene sulle prestazioni originali del software, sull’uso previsto per lo stesso e sul sistema di interpretazione dei dati: tali cambiamenti possono poi avvenire a livello di algoritmo, di data base, di piattaforma operativa, di canali di interoperabilità.
In questo caso, non potrà beneficiarsi del periodo di tolleranza di cui all’articolo 120 Mdr: dunque il software non potrà continuare ad essere marcato Ce ex Mmm, ma dovrà essere ricertificato ex Mdr.
Seppure oggi non sia ancora stato emanato il decreto relativo alle sanzioni per la violazione del Mdr (che dovrebbe essere inviato in Commissione Ue dal nostro governo entro il 25 febbraio 2021 ex art. 113), non vi sono dubbi che il fabbricante che apporterà un “cambiamento significativo” al software ex Mdd senza apporre la nuova marcatura Ce ex Mdr sarà passibile di sanzione.
Più delicata, invece, la posizione della struttura ospedaliera che utilizza un software ex Mdd che subisce un cambiamento significativo: pensiamo, ad esempio, all’ipotesi di un upgrade del software che inserisce una nuova funzionalità terapeutica del software stesso o anche solo l’ “ampliamento” di una funzionalità precedente, oppure una nuova modalità di lettura dei dati sanitari.
Possono configurarsi in questo caso profili di responsabilità in capo alla struttura? Tralasciando al momento possibili profili sanzionatori (che come sopra riportato non sono ancora noti), ciò non toglie che siano comunque già da ora configurabili ulteriori possibili profili di responsabilità.
La prima ipotesi è senza dubbio quella della responsabilità contrattuale, collegata al possibile danno che il paziente subisce a seguito di un errore derivante dal non corretto funzionamento del software o da una non corretta lettura da parte del medico dei dati di output del software stesso.
In questo caso il paziente potrà senza dubbio chiedere il risarcimento alla struttura sanitaria ex l. n. 24/2017 (c.d. legge Gelli sulla responsabilità sanitaria) e certamente la struttura potrà rivalersi nei confronti del fabbricante del software.
Con una differenza sostanziale però: ove la struttura sanitaria sia consapevole di usare un software marcato Ce ex Mdd e non abbia prestato la dovuta attenzione ai “cambiamenti significativi” di cui poteva ben rendersi conto (ad esempio un ampliamento delle funzioni terapeutiche) il suo profilo di concorso nel risarcimento del danno al paziente sarà molto più alto. Ove viceversa la struttura sanitaria non fosse in grado di cogliere il “cambiamento significativo”, il risarcimento potrà essere addebitato solo (o per la maggior parte) al fabbricante.
Nell’ipotesi poi di concorso di responsabilità della struttura sanitaria, si potrà aprire l’ulteriore profilo di possibile responsabilità erariale in capo al soggetto (il medico, l’ingegnare clinico, il responsabile Ict) che era nelle condizioni di capire (in base alle proprie competenze professionali) che il software aveva subito un “cambiamento significativo” e non ha segnalato la necessità di intervenire per utilizzare un software correttamente marcato.
Da ultimo potrebbe poi configurarsi una responsabilità per violazione del Gdpr. Si tratta chiaramente di un profilo parallelo e che corre su binari diversi da quello della marcatura Ce e della responsabilità sanitaria: è innegabile però che in un software medicale i profili di sicurezza ed efficacia clinica del Dm sono (quasi sempre) strettamente ed intrinsecamente collegati al tema del trattamento dei dati.
Considerazioni in parte analoghe posso essere svolte per tutti quei software che sono già in uso presso le strutture sanitarie e che non sono marcati Ce perché non rientranti all’epoca dell’immissione sul mercato nella nozione di medical device ai sensi dell’Mdd.
Come approfondito infatti nel nostro precedente articolo, l’ampliamento della nozione di “accessorio di dispositivo medico” operata dall’Mdr farà rientrare sotto la disciplina del Regolamento anche tutti quei software che svolgono funzione di ausilio all’attività medica.
Quindi è assolutamente possibile che esistano software – già installati e già funzionanti – che legittimamente non presentano alcuna marcatura Ce (in quanto al momento dell’installazione non rientravano nella nozione giuridica di Dm ai sensi dell’Mdd), ma che dovrebbe invece essere marcati ove immessi sul mercato in vigenza del Mdr.
In relazione a tali software non vi è dubbio che – da un punto di vista strettamente giuridico – l’ospedale possa continuare a usare il prodotto.
Avendo però presente due profili di assoluto rilievo. Il primo è che l’ospedale sta utilizzando un software non marcato Ce che, ove immesso in commercio dopo il 26 maggio 2021, dovrebbe invece vantare idonea marcatura ex Mdr: ciò senza dubbio alza il livello di responsabilità della struttura in caso di danno in capo al paziente.
Il secondo attiene poi ai successivi cambiamenti del software: seppure infatti la disciplina non regoli la casistica di software non marcato, a parere di chi scrive possono trovare legittima applicazione in via analogica gli stessi criteri elencati nella Mdcg 3-2020.
In altre parole, ove dovesse intervenire sul software non marcato un cambiamento considerato “significativo” secondo la Mdcg sopra riportata, il fabbricante dovrebbe marcarlo Ce (almeno ex Mdd prima del 26 maggio 2021, senza dubbio ex Mdr dopo tale data). In tal caso, la struttura sanitaria, in via prudenziale, dovrebbe alzare molto il livello di attenzione sui propri software, richiedendo direttamente tale marcatura ai fabbricanti dei propri software.