ARCHIVIO NEWS

Nel settore dei dispositivi medici, progettare un prodotto significa gestire contemporaneamente requisiti, software, hardware, rischi, verifiche e documentazione e man mano che aumenta la componente software dei dispositivi, aumenta anche la quantità di informazioni che devono rimanere coerenti e tracciabili.

Per chi lavora ogni giorno su questi processi, il problema non è solo avere gli strumenti giusti ma riuscire a tenere insieme tutte le informazioni. Un requisito cambia e quel cambiamento può avere un impatto sull’architettura, sul software, sui test e sulla gestione del rischio ma se ogni informazione vive in un sistema diverso e le relazioni vengono ricostruite manualmente, capire cosa deve essere aggiornato diventa un lavoro lungo e, soprattutto, più esposto agli errori.

Questi sono i principali motivi per cui il Digital Thread sta assumendo un ruolo sempre più importante nella trasformazione digitale del settore MedTech.

IEC 62304 e ISO 14971: il software e il rischio devono dialogare

Due riferimenti sono particolarmente importanti quando si parla di sviluppo di dispositivi medici con una componente software significativa: IEC 62304 e ISO 14971.

• La IEC 62304 definisce il framework per i processi del ciclo di vita del software medicale, dalla pianificazione allo sviluppo, fino alla manutenzione.
• La ISO 14971 riguarda invece la gestione del rischio dei dispositivi medici e accompagna il prodotto lungo il suo intero ciclo di vita.

Nella pratica, questi processi sono strettamente interconnessi e un requisito software può essere associato a uno specifico rischio, che a sua volta richiede l’introduzione di una misura di controllo. Questa misura dovrà poi essere implementata e verificata attraverso appositi test, mantenendo traccia del legame tra ogni elemento lungo l’intero ciclo di sviluppo.

A questo punto la domanda che sorge spontanea è: riusciamo a dimostrare questa relazione in modo rapido e affidabile?

Quando la tracciabilità diventa un problema

Il problema spesso non è la mancanza di informazioni, ma il fatto che siano distribuite tra strumenti diversi: fogli di calcolo, documenti, repository e piattaforme che non sempre dialogano tra loro e la difficoltà emerge soprattutto quando qualcosa cambia.

Quando un requisito viene modificato bisogna capire quali componenti sono coinvolti, quali dipendenze verificare, quali test ripetere e quale documentazione aggiornare: il Software Architect guarda all’architettura, il System Engineer alle relazioni tra requisiti e componenti, il Compliance Manager alle evidenze necessarie per dimostrare che il processo resta sotto controllo e quando queste informazioni sono distribuite in sistemi separati, gran parte del lavoro consiste nel ricostruire manualmente i collegamenti.

È proprio qui che la trasformazione digitale può portare un vantaggio concreto: non eliminando la documentazione richiesta dalla compliance, ma facendo in modo che sia più semplice produrla, aggiornarla e verificarla durante tutto il ciclo di vita del prodotto.

Il Digital Thread collega ciò che oggi è separato

Il concetto di Digital Thread parte da un’idea piuttosto semplice: mantenere un collegamento tra le informazioni che vengono generate nelle diverse fasi del ciclo di vita del prodotto.

Nel caso di un dispositivo medicale, possiamo pensare a una catena di questo tipo:

Requisiti → Architettura → Software → Risk Management → Test → Evidenze di verifica

L’obiettivo non è necessariamente utilizzare un unico strumento per tutto, è fare in modo che gli strumenti utilizzati possano mantenere le relazioni tra i diversi artefatti.

Un ecosistema che integra CAD, PLM e ALM, ad esempio, permette di collegare la progettazione del prodotto alla gestione del ciclo di vita e allo sviluppo software e questo approccio può essere esteso anche alle informazioni provenienti dal service, creando una continuità che va dalla progettazione all’utilizzo del prodotto sul campo.

Questo è il principio alla base di un Unified Digital Thread.

Cosa cambia per Software Architect, System Engineers e Compliance Manager?

Il vantaggio non è soltanto una maggiore automazione:

• Per un Software Architect, avere requisiti, architettura e dipendenze collegati significa poter valutare meglio l’impatto delle modifiche e mantenere sotto controllo l’evoluzione del software.
• Per un System Engineer, significa poter seguire più facilmente le relazioni tra requisiti di sistema, componenti, verifiche e vincoli.
• Per un Compliance Manager, significa avere una visione più chiara delle evidenze disponibili e della loro relazione con requisiti e rischi.

In tutti e tre i casi, il punto di partenza è lo stesso: il dato deve mantenere il proprio contesto durante tutto il lifecycle.

Dalla compliance come obbligo alla compliance come parte del processo

Quando la tracciabilità è incorporata nei processi e negli strumenti utilizzati quotidianamente dai team, può diventare parte naturale dello sviluppo e non rischia di essere vista come un’attività aggiuntiva.

L’obiettivo della digitalizzazione non dovrebbe essere creare altra documentazione, ma fare in modo che le evidenze necessarie alla compliance siano generate e collegate mentre il prodotto viene sviluppato, in questo modo IEC 62304 e ISO 14971 non vengono percepite come due ulteriori livelli di burocrazia, ma come elementi che possono essere integrati nel processo di engineering.

Una trasformazione digitale che parte dai processi

Per questo, prima di scegliere una nuova piattaforma, vale la pena guardare ai processi per porsi le giuste domande:

• Dove si perde tempo?
• Dove vengono duplicate le informazioni?
• Quali relazioni vengono ricostruite manualmente?
• (ma soprattutto) Cosa succede quando cambia un requisito o viene identificato un nuovo rischio?

Con queste domande un’organizzazione è in grado di capire quanto sia realmente pronta a costruire un Digital Thread.

Nel settore del MedTech, la trasformazione digitale non consiste semplicemente nel portare più attività sul digitale, ma creare continuità tra le informazioni che già esistono, dalla progettazione alla gestione del rischio, dallo sviluppo software alla verifica.

Quando un requisito cambia, sapere subito cosa cambia insieme a lui non è soltanto una questione di efficienza, è una questione di controllo del prodotto, del processo e del rischio.