Maggio 2021, cosa fare con software medicali da immettere in commercio o già installati

Articolo pubblicato su Aboutpharma.com


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.

Software marcato Ce ex Mdd

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.

La deroga condizionata

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.

Il “cambiamento significativo”

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

• viene introdotto un nuovo sistema operativo oppure il sistema operativo precedente subisce un cambiamento importante (in inglese major) oppure viene cambiato un componente considerato importante
• viene introdotta una nuova architettura del software o del data base oppure quando tali elementi subiscono una modifica
• l’algoritmo di funzionamento del software viene cambiato
• l’attività dell’utente viene sostituita da un algoritmo a circuito chiuso
• viene introdotta una nuova indicazione terapeutica
• viene inserita una nuova rete per l’interoperabilità
• viene inserita una nuova interfaccia per l’utente o una nuova modalità di presentazione dei dati: nello specifico si spiega che per “nuova presentazione dei dati” deve intendersi una modifica che attiene ai dati sanitari i quali vengono presentati in un nuovo formato o in una nuova dimensione o nuova unità di misura

Sono invece considerate modifiche minori – quindi non “significative” e non impattanti sulla marcatura – quelle relative a

• modifica solo della grafica dell’interfaccia utente (comprese l’inserimento di nuove lingue)
• correzione di un errore nel software che non impatta sulla sicurezza
• aggiornamenti di sicurezza del software.

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.

Possibili sanzioni

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.

Il cambiamento significativo per una struttura ospedaliera

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à.

Responsabilità contrattuale ed erariale

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.

Concorso di responsabilità

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.

Software non marcato Ce

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.