La maggior parte dei produttori di dispositivi medici dispongono di Applicazioni Software che sono ancora commercializzate, che funzionano bene e non hanno creato grossi problemi, ma che non sono state progettate sulla base di uno standard riconosciuto, ad esempio la norma IEC 62304
Può capitare però che si debba prendere la decisione di allineare tali applicazioni legacy a quanto richiesto dalla IEC 62304 ad esempio perché si vuole progettare una nuova versione della Applicazione, o integrare quel software in un nuovo dispositivo medico, oppure semplicemente perché tale allineamento è stato richiesto da un cliente importante o da un ente regolatorio.
La IEC 62304 nel suo documento di Aggiornamento del 2015 propone un percorso di allineamento che si declina in 4 fasi :
- Raccogliere ed analizzare ogni informazioni di ritorno, incluse quelle relative alla produzione, riguardanti incidenti o problemi sia all’interno del fabbricante che da parte dell’utente
- Valutare i potenziali rischi collegati all’utilizzo di tali Prodotti Software
- Effettuare una Gap Analysis fra lo stato di tali prodotti è la conformità necessaria
- Pianificare le modifiche necessarie per rendere tali tipologie di software conformi allo standard IEC 62304
Le attività da svolgere per ottenere la necessaria conformità sono in funzione di alcuni criteri quali ad esempio la tipologia della Applicazione oppure la dimensione dei cambiamenti che vanno effettuati alla Applicazione Legacy.
Per quanto riguarda la Tipologia dell’Applicazione le modalità di allineamento potrebbero essere diverse se siamo di fronte ad un Dispositivo Medico commercializzabile, oppure quello attuale non è a tutti gli effetti un Dispositivo Medico, oppure é solo un Prototipo ecc.
Se l’applicazione software non è considerato un Dispositivo medico però ad esempio deve essere integrata in un Sistema Software medicale, allora deve essere trattato come un SOUP e cioè vanno applicati tutti quei requisiti della IEC 62304 che riguardano questa tipologia di applicazioni.
SOUP (Software of Unknown Provenance) viene definito come: elemento software precedentemente sviluppato e comunemente disponibile, che non è stato realizzato allo scopo di essere incorporato in un Dispositivo Medico o software precedentemente sviluppato per il quale non siano disponibili le informazioni adeguate ai processi di sviluppo.
La norma IEC 62304 richiede determinate precauzioni sull’utilizzo del software SOUP
Se tale applicazione è invece di tipo prototipale, cioè ad esempio progettata da team di ricerca e sviluppo senza tener conto, per il suo sviluppo, di Sistemi per la qualità e di normative, allora non è necessario effettuare alcuna normalizzazione fino a quando non ci sia l’intenzione di immetterla sul mercato singolarmente o integrata in un Dispositivo Medico.
Nel caso invece di un classico Dispositivo Software Legacy, il criterio per determinare le attività di trasformazione progettuale è in genere funzione della dimensione delle modifiche che vanno introdotte
1 ° caso: il software legacy non deve essere modificato
In questo caso il software va trattato come una SOUP
Quindi le attività da effettuare sono da focalizzate soprattutto sulla valutazione del rischio. Per cui è necessario:
- Identificare i requisiti funzionali e tecnici gestiti dalla legacy
- Fare un’analisi dei rischi che coinvolga:
- i requisiti funzionali
- l’eventuale integrazione della Applicazione Legacy in un dispositivo medico sia hardware sia software
- le eventuali Non Conformità già evidenziate nella Applicazione Legacy
Il problema però può nascere allorquando, a fronte dell’analisi dei rischi, si voglia implementare, all’interno del Dispositivo Medico, delle azioni di mitigazione per la riduzione di alcuni rischi .
Se tali azioni non coinvolgono l’Applicazione Legacy allora la situazione da affrontare è abbastanza semplice.
Però non sempre questo è fattibile in quanto ci possiamo trovare di fronte ad un software legacy Stand Alone oppure é molto più semplice inserire tali azioni all’interno della Applicazione Legacy .
Questo però porta al fatto che, avendo introdotto delle modifiche significative, il software Legacy non può essere trattato come una SOUP, e quindi si dovrebbe applicare un certo ciclo di sviluppo e di re-ingegnerizzazione
Inoltre bisogna mettere anche in evidenza che la soluzione SOUP è certamente conveniente in una fase iniziale, però potrebbe esserlo meno se l’Applicazione legacy rientra in una famiglia di dispositivi medici: in questo caso il problema potrebbe ripresentarsi o con una versione successiva del dispositivo o con un altro dispositivo appartenente alla stessa famiglia di prodotti
2 ° caso: il software legacy è leggermente modificato
Questo è un caso molto borderline anche perché é necessario in primo luogo stabilire cosa si intende per modifiche limitate tenendo presente di seguire la buona norma che consiglia che, se il numero di modifiche da applicare é significativo ( in genere superiore al 20% ) allora è meglio che l‘Applicazione Software sia ristrutturata.
Teniamo inoltre presente che il concetto di modifica limitata non riguarda solo aspetti quantitativi ma anche qualitativi : ad esempio se le funzionalità, su cui si deve mettere mano, influiscono sulla Safety o sulla Security, rendono tali modifiche importanti anche se ridotte. Questo lo si può ovviamente sapere attraverso un’accurata Risk Analysis prima di affrontare i cambiamenti.
Pertanto, a fronte di questo tipo di upgrade ridotto, l’approccio che va seguito è quello di effettuare le modifiche necessarie e poi trattare l’Applicazione come Soup
Nel caso vengano introdotte nuove funzioni o nel caso vengano modificate significativamente funzioni già presenti nella Applicazione Software, allora l’iter di allineamento potrebbe comportare:
- Fare un’analisi dei rischi delle parti da modificare
- Progettare le modifiche e le azioni di mitigazione (se presenti)
- Implementare le modifiche
- Testare il software legacy modificato
- Trattare l’Applicazione come una SOUP
3 ° caso: il software legacy è profondamente cambiato
Questo caso si verifica quando è necessario ristrutturare l’architettura software dell’Applicazione esistente oppure aggiungere un nuovo grande insieme di funzioni al Software legacy
Per questa tipologia di Applicazioni è ovviamente obbligatorio un Ciclo di progetto e di sviluppo come quello da applicare ad un prodotto nuovo
4 ° caso: Porting del software legacy su una nuova piattaforma
La nuova piattaforma può essere un nuovo hardware (nuovo microcontrollore) o un nuovo software (nuovo sistema operativo, nuove librerie) o entrambi
Nel caso le modifiche apportate al software siano solo di tipo tecnico ( le interfacce sono progettate per funzionare con la nuova piattaforma ed il codice viene corretto e ricompilato sulla nuova piattaforma ) ma non di tipo funzionale (nessuna funzione esistente viene modificata e nessuna nuova funzione viene aggiunta ) la tipologia di intervento può essere assimilabile a quella del caso 2°.
L’unica significativa modifica del processo di allineamento potrebbe essere quella relativa all’entità dei test che dovrebbero essere più approfonditi ( in alcuni casi di tipo White Box) relativamente alle interfacce, per dimostrare che il software installato sulla nuova piattaforma funziona come prima
La classe di Sicurezza di un prodotto Legacy
Infine andiamo ad evidenziare un altro aspetto importante che riguarda il fatto che l’allineamento di una Applicazione Legacy allo standard IEC 62304 comporta l’assegnazione di una classe di Sicurezza a tale applicazione.
Ricordiamo che le classi di sicurezza individuate dalla IEC 62304 sono 3 e sono basate sulla Gravità del danno arrecato all’utilizzatore o al paziente o a persone che stanno nei pressi del dispositivo medico quando questo viene utilizzato. Le tre classi sono:
- CLASSE A nessuna lesione o danno per la salute
- CLASSE B possibile una lesione non Grave
- CLASSE C possibile morte o lesione Grave
Nel caso di Applicazioni software che necessitano di una completa revisione (tipo 3) è chiaro che le modalità di classificazione sono le stesse che vengono utilizzate per un qualunque prodotto nuovo.
Mentre per quanto riguarda le Applicazioni che hanno subito modifiche limitate o addirittura nessuna variazione la classificazione si basa su una dettagliata analisi dei rischi incentrata sugli aspetti della Sicurezza degli utenti e dei pazienti tenendo conto anche del contesto operativo in cui i software legacy dovranno essere utilizzati.
Commenti recenti