L applicazione delle Direttive e delle norme tecniche vigenti per il processo di certificazione del software

Transcript

1

2 L applicazione delle Direttive e delle norme tecniche vigenti per il processo di certificazione del software Ferdinando Capece Minutolo Vincenza Ricciardi Area Regulatory Affairs Life Tech Forum Genova, 07 marzo 2016

3 Agenda 1. Premessa 2. Definizioni 3. Quadro regolatorio 4. Rapporto Direttive EU-Norme tecniche 5. Classificazione del Software 6. Apps 7. Nuovo Regolamento 8. Conclusioni

4 Premessa Il Software sta diventando sempre più importante e PERVASIVO nel settore sanitario. Data la disponibilità di un gran numero di piattaforme tecnologiche (personal computer, smartphone, server di rete, ecc), e di distribuzione (internet, cloud) a) il software creato per scopi medici (software utilizzati per prendere decisioni cliniche) b) il software creato per scopi non medici (per es. funzionalità amministrative e finanziaria) vengono utilizzati nel settore sanitario. Gli attuali quadri regolatori trattano i rischi per la salute pubblica del software quando incorporato in un dispositivo medico tradizionale Tuttavia, l'attuale applicazione della normativa e dei controlli non sempre affronta i particolari rischi per la salute pubblica derivanti da SAMD o garantisce un adeguato equilibrio tra la tutela del paziente/consumatore e la promozione della salute pubblica, agevolando l'innovazione.

5 Definizioni o Le Autorità Competenti Nazionali e l International Medical Device Regulators Forum (IMDRF) hanno individuato il software come un settore sempre più cruciale per lo sviluppo di prodotti sanitari e hanno riconosciuto distinti tipi di software a scopo medico: q software parte di un dispositivo medico (indicato come "integrato" - embedded ) q software stand-alone, riconosciuto come dispositivo medico (Software as a Medical Device, o SaMD) v La distinzione principale tra i due è che il SaMD non è incorporato in un dispositivo medico al momento della sua immissione sul mercato ma può completare la sua destinazione d uso e non necessita dell hardware, ovvero il componente fisico di una periferica o di una apparecchiatura elettronica, di un dispositivo medico. Software as a Medical Device (SaMD)WG: Key Definitions, IMDRF SaMD, 9 December 2013, IMDRF/SaMD WG/N10FINAL:2013

6 Quadro Regolatorio v Direttiva 2007/47/CEE ha modificato la definizione del termine "dispositivo medico" utilizzato nelle direttive 90/385 / CEE e 93/42 / CEE inserendo anche il software v Il software Stand alone che NON soddisfa la definizione di un DM o di un dispositivo IVD ma è destinato dal fabbricante ad essere un accessorio di un DM o un dispositivo IVD, rientra rispettivamente nell'ambito di applicazione della direttiva 93/42 o della direttiva 98/79. v Il recital 6 della direttiva 2007/47 stabilisce che è necessario chiarire che il software a sé stante, quando specificamente destinato dal fabbricante ad essere impiegato per una o più delle finalità mediche stabilite nella definizione di DM, è un dispositivo medico

7 Quadro Regolatorio Nel caso invece del software senza finalità mediche: o non rientra nella fattispecie di dispositivo medico o non è applicabile la normativa sui dispositivi medici o ricade nel quadro più generale della direttiva sui diritti dei consumatori (2011/83/UE, Decreto Legislativo 21 febbraio 2014, n. 21, che modifica il codice del consumo, Decreto legislativo 6 settembre 2005, n. 206). occorre sempre ricordare l applicazionedella Direttiva sulla privacy

8 Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software Rapporto Direttive EU-Norme tecniche 2 standard di importanza fondamentale per MD ISO13485 QMS ISO14971 RISK MGMT applicate a tutti i dispositivi Standard dedicate al SFW : 1. IEC sul software lifecycle 2. IEC Medical electrical equipment - Part 1: General requirements for basic safety and essential performance 3. IEC Application of usability engineering to medical devices

9 Rapporto Direttive EU-Norme tecniche EN 62304: 2007 Medical device software Software life cycle processes è diretta sia ai fabbricanti che agli utilizzatori e introduce un approccio sistematico per la progettazione e il mantenimento del software durante tutto il suo ciclo di vita. Non tratta la validazione e l immissione del software a scopi medicali (di cui si occuperà la 82304) Development Activities (Incluso Risk MGMT) 1. Software developmentplanning 2. Software requirements analysis 3. Software ARCHITECTURAL design 4. Software detailed design 5. Software Unit implementation and Verification 6. Software testing 7. Software release Maintenance Activities 1. Establish Software maintenance plan 2. Problem and modification analysis 3. Software ARCHITECTURAL design 4. Software detailed design 5. Software Unit Implementation and Verification 6. Software Testing 7. Release Software Configuration Management process e Software problem resolution process

10 EN Lo scopo di questa norma è di raccomandare un processo per lo sviluppo di software dispositivo medico dialta qualità, in linea con le direttive ed ilsistema diqualità nel settore dei dispositivi medici.

11 Rapporto Direttive EU-Norme tecniche La IEC definisce 3 classi per i software in base alla loro sicurezza: Classe A: Nessuna lesione o danno alla salute Classe B: Lesioni non gravi Classe C: Morte o lesioni gravi

12 Il mio software è un md? 1) Il primo passo è confermare che il tuo prodotto sia legalmente classificable come Software as a Medical Device (SaMD) o Il prodotto dovrà riportare il fine medico nella destinazione d uso (come da Direttive) *la MEDDEV 2.1/6. è lo strumento idoneo da seguire 2) Il software stand-alone che ha uno scopo medico è considerato un DM attivo 3) La classificazione dipende dal rischio che l utilizzo del software comporta per il paziente e l utilizzatore 4) Per classificare il proprio software si dovranno tenere in considerazione le regole 9, 10, 11 e 12 dell Allegato IX, 93/42 e la sezione 2.3 Allegato IX: Il software destinato a far funzionare un dispositivo o ad influenzarne l'uso rientra automaticamente nella stessa classe del dispositivo. v Stesso discorso per AIMD/IVD: il software stand alone viene classificato secondo la stessa classe di rischio di un AIMD/IVD o di un loro accessorio posto che rispondano ai requisiti delle relative Direttive Dispositivo medico attivo: dipendente, per il suo funzionamento, da una fonte di energia elettrica o di altro tipo di energia, diversa da quella generata direttamente dal corpo umano o dalla gravità e che agisce convertendo tale energia

13 Alcuni esempi Regola 9: Software contenuto in uno stimolatore muscolare, un incubatore, un laser. Software collegato attraverso la rete ad un dispositivo terapeutico. Ad esempio: apparecchiature fisioterapiche per monitoraggio a distanza, sistema di pianificazione di radioterapia usata per calcolare la dose di radiazioni ionizzanti da somministrare al paziente, pianificazione dosaggio dell'insulina tramite software stand-alone Regola 10:Software contenuto in qualsiasi scanner (ultrasuoni, raggi X, risonanza magnetica), un termometro elettronico Software collegato attraverso la rete (cablata o wireless) ad un DM diagnostico. Ad es.: Archiviazioni Immagini e Sistema di comunicazione Software stand alone di elaborazione Dati dei pazienti per consentire diagnostica diretta. Ad es.: un app utilizzata per calcolare i dati diagnostici. Regola 11: Software incluso in pompe di infusione, ventilatori, nebulizzatori, pompe di aspirazione, apparecchiature per dialisi, Software collegato attraverso la rete (cablata o wireless) ad un dispositivo di somministrazione di un farmaco Regola 12: Tutto il resto Software utilizzato per letto d'ospedale Software utilizzato per monitorare o controllare un dispositivo di classe I Software stand alone per l'elaborazione dei dati per la diagnosi. Ad esempio: un app utilizzata per calcolare un valore. Tutti i software che non rientrano nelle regole 9,10,11 rientrano nella regola 12 ( rischio minore ).

14 1.se SAMD è un programma per computer in ambito medicale, allora può essere un DM. Se il software non è un programma per computer medicale, non è un DM. 2.se il software è integrato in un DM, piuttosto che SAMD, deve essere considerato come parte di questo DM in un processo di certificazione di tale DM. 3.se il software non esegue un'azione sui dati o esegue un'azione limitata allo stoccaggio, l'archiviazione, la comunicazione, semplice ricerca non è un DM. 4.se il fabbricante intende il software da utilizzare per uno degli scopi di cui all'articolo 1 (2) bis della direttiva 93/42, il software deve essere qualificato come un DM. Meddev 2.1/6 flow chart per procedere alla classificazione del software come dispositivo medico

15 1. se le informazioni fornite dal software si basano solo su dati ottenuti da dispositivi IVD, il software è un IVD o un suo accessorio. 2. Se i dati sono ottenuti da entrambi dispositivi IVD e da dispositivi medici e sono analizzati insieme allo scopo di fornire informazioni secondo la definizione di un DM -IVD, questo software è un dispositivo IVD (ad es. valutazione del rischio di trisomia 21- sindrome Down). 3. se le informazioni fornite dal software si basano su dati ottenuti da dispositivi medici, il software è un DM. Meddev 2.1/6 flow chart per procedere alla classificazione del softw come dispositivo medico-diagnostico in vitro

16 Applicazione delle Direttive e delle norme tecniche per il processo di certificazione Scenari futuri mobile applications (Apps) un giro di affari di affari stimato nel 2018 in 6.9 miliardi di dollari, cioè quanto già l intero settore delle tecnologie mediche è in grado di produrre ogni anno Il termine "app" indica un'applicazione software per dispositivi smartphone, palmari e tablet. Una app è tipicamente sviluppata attraverso piattaforme per lo più open source, e può essere caricata in un sito web anche senza una procedura di approvazione Crescita globale del mercato delle apps per medici e pazienti collegate all utilizzo di smartphone posseduti da quasi metà della popolazione globale Apps effetto dirompente sul mondo della sanità, consentendo ai medici di effettuare diagnosi e seguire i pazienti a distanza/accedere a informazioni vitali da qualsiasi luogo e in qualsiasi momento strumento di fortissima proliferazione e diffusione stime del Ministero della Salute attestano a quasi le App mediche già disponibili sul mercato a disposizione di 500 milioni di potenziali utenti

17 Prospettive del software nel nuovo Regolamento europeo l Unione Europea, sta rivedendo l intero assetto regolatorio dei DM i considerando iniziali, sono in linea con le definizioni dell IMDRF: o software stand-alone, quando specificamente destinato dal fabbricante per una o più delle finalità mediche stabilite nella definizione di dispositivo medico, è qualificato come un dispositivo medico o il software per usi generali, anche quando viene utilizzato in un contesto sanitario, o il software destinato alla cura del proprio benessere non è un dispositivo medico è stata eliminata dal testo l inclusione dei software tra i dispositivi medici attivi Per quanto attiene ai requisiti generali di sicurezza, l Allegato I raccomanda che i dispositivi siano progettati e costruiti in modo tale da eliminare o ridurre il più possibile il rischio associato ad una possibile interazione negativa tra il software e all'ambiente in cui opera e interagisce Per i dispositivi che incorporano un software o per il software stand-alone, il software deve essere sviluppato e prodotto secondo lo stato dell'arte, tenendo conto dei principi del ciclo di vita dello sviluppo, la gestione dei rischi, tra cui la sicurezza delle informazioni, la verifica e la convalida Inoltre, viene richiesto, tra i Pre-clinical and clinical data, la verifica e la validazione del software (la quale descrive la progettazione del software e il processo di sviluppo e le prove di validazione del software, come utilizzato nel dispositivo finito

18 Prospettive del software nel nuovo Regolamento L Allegato VII, Classificazione, alla sezione II specifica che: Se il software stand-alone è il software che aziona un dispositivo o ne influenza l'uso, rientra automaticamente nella stessa classe del dispositivo Se il software stand-alone invece è indipendente, verrà classificato come a sé stante. solo la Regola 1 dell Allegato VII si applica al software infatti, l esclusione del software dai dispositivi medici attivi, di fatto, limita l applicabilità delle varie regole di classificazione esigenza di aggiungere una regola specifica sul software in seno all Allegato VII sulla base del documento dell IMDRF risk categorisation for Software as a Medical Device maggiore allineamento con i documenti dell IMDRF Si rimanda alla risoluzione dell iter negoziale per avere maggiori certezze sulla futura regolamentazione del software

19 Conclusioni Ø La rapida evoluzione e disponibilità sul mercato, dei software nell ambito sanitario mostra evidenti potenzialità per quanto attiene ad una migliore allocazione delle risorse e all incremento della qualità delle terapie somministrate Ø Tuttavia, occorre tener presente il duplice rischio che può derivare sia per il sistema sanitario, compromettendo la gestione delle sue strutture stesse, sia per i pazienti e la loro salute Ø Nell attuale contesto normativo europeo, e quindi nazionale, sono già presenti gli strumenti normativi per una gestione ottimale del software come dispositivo medico sotto molti dei suoi punti di vista più critici Ø Lo sviluppo dell ehealth in generale si presenta come un fenomeno altamente complesso che richiede agli stakeholder la produzione di documenti esplicativi e interpretativi che aiutino a fare chiarezza e a utilizzare al meglio la normativa già esistente

20 GRAZIE PER L ATTENZIONE ricciardi@assobiomedica.it capece@assobiomedica.it Tutti gli atti citati nella presentazione potrebbero non riguardare alcuni casi particolari. In tale circostanza occorrerà contattare un Organismo Notificato o l'autorità competente per valutare lo status del software.