Dispositivi medici, data protection, e cybercrime: le tre sfide del nuovo software

Non vi è dubbio che i software incorporati nei DM o i software stand-alone qualificati come DM sono tra i prodotti che, più di altri, subiranno l’impatto del nuovo Mdr. Non solo infatti – come già visto nell’articolo “App e telemedicina, i profili giuridici con il nuovo Mdr” – molti software che oggi non sono DM dovranno rientrano nella nuova disciplina, ma anche tanti di quelli che già oggi ne sono sottoposti dovranno cambiare classe di rischio (aumentandola).

Grandi sfide future

Ma la sfida per i software è, oggi, molto più ampia. Da sempre infatti gli obiettivi generali a cui i DM devono rispondere sono ’“efficacia delle prestazioni” e la “sicurezza del dm”, tenuto conto del rapporto rischi/benefici. Aspetti ripresi e ribaditi al punto 1 dell’allegato I del Mdr che così stabilisce: “I dispositivi forniscono le prestazioni previste dal loro fabbricante e sono progettati e fabbricati in modo che, in normali condizioni d’uso, siano adatti alla loro destinazione d’uso.

Essi sono sicuri ed efficaci e non compromettono lo stato clinico o la sicurezza dei pazienti, né la sicurezza e la salute degli utilizzatori ed eventualmente di altre persone, fermo restando che gli eventuali rischi associabili al loro utilizzo sono accettabili, considerati i benefici apportati al paziente, e compatibili con un elevato livello di protezione della salute e della sicurezza, tenendo conto dello stato dell’arte generalmente riconosciuto”.
Per i software che rientrano nella nozione di dm, questi due obiettivi acquistano poi oggi una ampiezza molto diversa: sicurezza ed efficacia devono infatti intersecarsi con il tema della cybersicurezza e della sicurezza dei dati. Partiamo dal primo.

La sicurezza nel mondo cibernetico

Negli ultimi anni infatti l’aumento della capacità di elaborazione, diffusione/dispersione dei software, sostenute dalla disponibilità di reti di trasmissione (internet e mobile) sempre più performanti, hanno portato alla definizione di “cyberspazio” inteso come il perimetro virtuale nel quale si muovono i dati e le informazioni generati da oggetti, persone, sistemi. Ne deriva che oggi tutti i software, facendo parte dello spazio virtuale, possono essere soggetti a violazioni dall’esterno. Ciò rileva fortemente per i dispositivi medici per i quali una violazione dall’esterno non evidenziata o non gestita può compromettere l’efficacia del dm e quindi la sicurezza del paziente. Non vi è dubbio quindi non sia più sufficiente garantire la sicurezza “intrinseca” del software, ma occorre porsi il problema della sicurezza dello stesso in relazione all’ambiente esterno.

Tema internazionale

Poiché poi lo spazio virtuale non ha confini, il tema oggi è certamente non solo nazionale o europeo ma certamente mondiale. Basti ricordare che a settembre 2018 la Fda ha pubblicato le ultime linee guida sul tema titolate “Fda should further integrate its review of cybersecurity into the premarket review process for medical devices” in cui sono stati precisati requisiti aggiuntivi nella fase premarket per aumentare la sicurezza dagli attacchi esterni (si veda l’articolo su AboutPharma del 13 settembre 2018). Protagonisti indiscussi di tale pericolo sono poi le app medicali e gli scambi di dati come emerge con chiarezza nell’articolo “Ecco i maggiori problemi per la sicurezza digitale in ambito sanitario. Protagoniste le applicazioni mHealth e lo scambio di dati dei pazienti” pubblicato su Agenda Digitale a marzo del 2018.

Il nodo privacy

E proprio sui dati si apre un altro scenario, che è quello del Regolamento generale (Ue) 2016/679 (Gdpr). Il software è infatti un DM che (molto spesso) tratta dati personali. Il progettista ed il fabbricante del dm non potranno quindi prescindere dalle prescrizioni del Gdpr. La PA che acquista il software è, infatti, il titolare di uno (o più) trattamenti di dati e deve quindi (a sua volta) rispettare i principi dell’accountability (art. 5 Gdpr). Di conseguenza quando acquista deve oggi acquistare prodotti che gli consentono di garantire tale rispetto.

Conseguentemente chi vende e chi progetta il software dovrà inserire, sin dalla progettazione dei dm, misure di sicurezza di cosiddetta privacy by design in maniera da poter dare assicurazioni all’acquirente (in un frequente squilibrio di conoscenza tra chi produce e chi acquista) che il software acquistato presenta caratteristiche tali da consentire il rispetto del Gdpr. In particolare il software dovrà consentire:

1. L’autenticazione di chi usa il device ed accede ai dati.
2. La protezione dei dati trasmessi/scambiati, (secondo le più recenti evidenze).
3. L’impermeabilità agli vulnerability scanner.
4. La installabilità di antivirus.
5. L’obbligo di misure complementari a carico della struttura organizzativa che li usa.

Elementi questi che, proprio per questo motivo, vengono oggi sempre più richiesti in gara, ove si chiama il fabbricante a dichiarare che il suo software oltre ad essere compliance al Mdr è altresì conforme al Gdpr e al principio della privacy by design e by default.

Il contesto del Mdr

Andando ora a verificare la nuova disciplina, sembra di poter dire che il nuovo Mdr volge lo sguardo agli aspetti sopra evidenziati. In particolare al punto 17 dell’allegato I capo II (titolato Requisiti relativi alla progettazione e fabbricazione) dove si delineano le specifiche per il software. Infatti dopo aver sancito l’obbligo di garantire la riproducibilità, l’affidabilità e le prestazioni in linea con la destinazione d’uso del software (punto 17.1) si stabilisce che “per i dispositivi contenenti un software o per i software che costituiscono dispositivi a sé stanti, il software è sviluppato e fabbricato conformemente allo stato dell’arte, tenendo conto dei principi del ciclo di vita dello sviluppo, della gestione del rischio, compresa la sicurezza delle informazioni, della verifica e della convalida (punto 17.2)”.

Ai punti successivi si allarga al campo stabilendo che “i software di cui al presente punto destinati a essere usati in combinazione con piattaforme di calcolo mobili sono progettati e fabbricati tenendo conto delle peculiarità della piattaforma mobile (ad esempio dimensioni e grado di contrasto dello schermo) e di fattori esterni connessi al loro uso (variazioni ambientali relative al livello di luce o di rumore (punto 17.3)”.

Mdr e Gdpr vanno di pari passo

Ancor più specificamente poi al punto 17.4 si chiede al fabbricante di ragionare sul luogo all’interno del quale il software andrà ad operare, dando altresì indicazione all’utilizzatore (struttura sanitaria) circa le caratteristiche che deve presentare il contesto nel quale il software si inserisce in maniera tale da poterne conservare la sicurezza. E infatti il punto 17.4 stabilisce che “i fabbricanti indicano requisiti minimi in materia di hardware, caratteristiche delle reti informatiche e misure di sicurezza informatica, compresa la protezione contro l’accesso non autorizzato, necessari per far funzionare il software come previsto”. I temi da leggere e studiare, quindi, non solo solo quelli del nuovo Mdr ma occorre alzare gli occhi e guardare oltre, verso le tematiche del Gdpr e quelle ancor più sfidanti del cybercrime.