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 Vincenza Ricciardi Area Regulatory Affairs Milano, 16 febbraio 2016

3 Agenda 1. Premessa 2. Definizioni 3. Quadro regolatorio 4. Rapporto Direttive EU-Norme tecniche 5. Classificazione del Software 6. Step pratici per la classificazione 7. Redazione del fascicolo tecnico (QMS+RISK MGMT) 8. Indagini Cliniche 9. Apps 10. Nuovo Regolamento

4 Premessa il 7% dei richiami dal mercato di DM è attribuibile a difetti del software. Basta questa affermazione per spiegare l importanza che va assumendo il software nelle applicazioni mediche. In questa presentazione ci occuperemo di illustrare la normativa inerente la convalida del software medicale. Allo stato attuale abbiamo due distinti tipi di software a scopo medico: software parte di un dispositivo medico (indicato come "integrato" - embedded ) software stand-alone, conosciuto anche come dispositivo medico (SAMD) Il Software Stand alone deve ricadere nella relativa definizione ed avere uno scopo medico per essere qualificato come dispositivo medico

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

7 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: software parte di un dispositivo medico (indicato come "integrato" - embedded ) software stand-alone, riconosciuto come dispositivo medico (Software as a Medical Device, o SaMD) 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

8 Definizioni 2 Inoltre il SAMD può: fornire mezzi e suggerimenti per la mitigazione di una malattia fornire informazioni per determinare la compatibilità, la rilevazione, la diagnosi, il monitoraggio o trattamento di stati fisiologici, di stati di salute, di malattie o di malformazioni congenite essere un aiuto nella diagnosi, lo screening, nel monitoraggio, la prognosi, la previsione, la determinazione dello stato fisiologico NOTE: Il SAMD è un dispositivo medico e include anche i diagnostici-ivd Il SAMD è in grado di funzionare su piattaforme informatiche per uso generale (scopi non medici) "senza essere parte di" si intende che per il SAMD non è necessario essere parte dell hardware di un DM per raggiungere il suo scopo medico previsto Il software non è SAMD se il suo scopo è unicamente quello di operare l hardware di un DM Il SAMD può essere utilizzato in combinazione (es. come modulo) con altri prodotti, compresi DM Il SAMD può interfacciarsi con altri DM, compreso l hardware dei DM o altri SAMD, così come software di uso generale Le Applicazioni mobili (Apps) che soddisfano le definizioni di cui sopra sono considerate SAMD a tutti gli effetti

10 Quadro Regolatorio 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 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. 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

11 Quadro Regolatorio La Direttiva 2007/47/CE: Modifiche Dir. 93/42/CEE - Art. 1, Par.2, lettera a): dispositivo medico : qualunque strumento, apparecchio, impianto, software, sostanza o altro prodotto, utilizzato da solo o in combinazione, compreso il software destinato dal fabbricante ad essere impiegato specificamente con finalità diagnostiche e/o terapeutiche e necessario al corretto funzionamento del dispositivo, destinato dal fabbricante ad essere impiegato sull uomo a fini di: diagnosi, prevenzione, controllo, terapia o attenuazione di una malattia diagnosi, controllo, terapia, attenuazione o compensazione di una ferita o di handicap studio, sostituzione o modifica dell anatomia o di un processo fisiologico; intervento sul concepimento la cui azione principale voluta nel o sul corpo umano NON sia conseguita con mezzi farmacologici né immunologici né mediante metabolismo, ma la cui funzione possa essere assistita da questi mezzi

12 Quadro Regolatorio Nel caso invece del software senza finalità mediche: o o o non rientra nella fattispecie di dispositivo medico non è applicabile la normativa sui dispositivi medici 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 applicazione della Direttiva sulla privacy

13 Quadro Regolatorio Un DM per essere legalmente immesso nel mercato europeo deve possedere la Certificazione di Conformità (marchio CE) La direttiva 2007/47/EC modifica la 90/385 e la 93/42 e introduce la nozione di software (cd. stand-alone o indipendente) nella definizione di dispositivo medico La Direttiva 2007/47/EC specifica che il software indipendente, quando inteso dal fabbricante per essere impiegato per una o più finalità mediche stabilite nella definizione di DM, è un dispositivo medico Un possibile percorso decisionale per stabilire se un prodotto software, e quindi una app per la salute, ricada nella definizione di DM è riportato nella MEDDEV 2.1/6:2012. Un caso particolare è rappresentato da prodotti software destinati ad essere utilizzati nel contesto dei dispositivi medici impiantabili attivi, nel qual caso rientrano nell ambito di pertinenza della Direttiva 90/385/EC

14 Quadro Regolatorio Inoltre, sono strumenti di grande utilità: Linea Guida sulla classificazione del software stand.alone: MEDDEV 2.1/6 Raccomandazione NB-MED/2.2/Rec4 Rev.5 per i Software & MD stilata dal NB-MED associazione organismi notificati europei Lista delle standard armonizzate sotto le direttive di riferimento per DM/IVD/AIMD I documenti dell IMDRF: Software as a Medical Device (SaMD): Key definitions Software as a Medical Device (SaMD): Application of Quality Management System "Software as a Medical Device": Possible Framework for Risk Categorization and Corresponding Considerations

16 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

17 Rapporto Direttive EU-Norme tecniche Seguire alla lettera le disposizioni degli standard armonizzati è il modo più facile per dimostrare la conformità del proprio prodotto ai REQUISITI ESSENZIALI posti dalle direttive. Si ricorda che la norma tecnica per essere armonizzata deve avere specifico mandato della Commissione Europea ed essere successivamente pubblicato sulla GUCE. Per capire se uno standard sia stato armonizzato o meno occorre studiarne il contenuto: tipicamente l introduzione menziona tale fatto che viene ripetuto anche nell Allegato Z, il quale paragona in forma grafica i requisiti dello standard a quelli essenziali delle direttive applicabili. Gli Standard sono importanti in quanto le Direttive Europee ne richiamano l applicazione per la presunzione di conformità ai requisiti essenziali. Gli Standard sono divisi in norme orizzontali quando si applicano ad aree generiche di DM e verticali quando dettano specifiche tecniche per tipi individuali di dispositivi

18 Rapporto Direttive EU-Norme tecniche ISO 13485:2012 Medical devices Quality management systems Requirements for regulatory purposes. Lo standard specifica i requisiti per la gestione del Sistema qualità dove l azienda deve dimostrare l abilità di fornire dispositivi medici e i relativi servizi in modo da soddisfare in maniera continuativa la domanda e i requisiti regolatori applicabili. Lo standard tratta: processi di fabbricazione progettazione controlli test finali di qualità documentazione responsabilità della gestione gestione delle risorse NUOVE VERSIONI NEL 2016! le aziende che realizzano (progettano, producono,installano e commercializzano) dispositivi medici oltre alla norma ISO 9001 si devono attenere anche alla norma Tale normativa ha la medesima struttura della ISO 9001 (contenuti), ma include alcuni requisiti specifici (es. sterilizzazione, commercializzazione, tracciabilità, immagazzinamento, gestione eventi avversi, sorveglianza post-vendita, blocco e richiamo dal mercato dei DM ).

19 Rapporto Direttive EU-Norme tecniche ISO 14971: 2012 MD Application of risk management to medical devices per I fabbricanti di DM che devono dimostrare la loro conformità ai requisiti essenziali della Direttiva 93/42/EEC. Lo standard descrive i processi per la gestione e la mitigazione dei rischi associati allo sviluppo e al monitoraggio di un dispositivo medico. è uno strumento fondamentale per il fabbricante per analizzare, valutare ogni rischio collegato al prodotto, mitigare e monitorare l efficacia delle misure tese a ridurre l impatto di un determinato rischio. La decisione di utilizzare un determinato dispositivo medico presa dall operatore sanitario deve implicare la valutazione dei rischi, così come riportati dal fabbricante nelle IFU, e il loro raffronto con i supposti vantaggi derivanti dall utilizzo di un certo dispositivo per una certa terapia. I requisiti descritti si applicano a tutte le fasi del ciclo di vita del DM e possono essere integrati nel Sistema di gestione della qualità.

20 Rapporto Direttive EU-Norme tecniche ISO/TR :2009 Medical device software Guidance on the application of ISO to medical device software Si tratta di un rapporto tecnico in materia di gestione del rischio e sviluppo di un software quando quest ultimo è parte di un dispositivo medico e descrive come applicare l ISO insieme allo standard IEC (di cui dopo). Il rapporto delinea l approccio proattivo, anziché reattivo, da tenere nello sviluppare un software a scopi medici.

21 Rapporto Direttive EU-Norme tecniche EN Medical electrical equipment Part 1: General requirements for basic safety and essential performance Tra gli standard più importanti per i dispositivi medici attivi, contiene requisiti sulla sicurezza elettrica e meccanica, IFU con specifico riferimento al paziente EN 62366:2008 Medical devices Application of usability engineering to medical devices descrive il processo che il fabbricante deve seguire nell analizzare, specificare, verificare e validare la fruibilità rigorosamente legata all utilizzo sicuro di un dm al fine di valutare e mitigare i possibili rischi connessi ad un uso non corretto

22 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 development planning 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

23 EN Lo scopo di questa norma è di raccomandare un processo per lo sviluppo di software dispositivo medico di alta qualità, in linea con le direttive ed il sistema di qualità nel settore dei dispositivi medici.

24 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

25 ARGOMENTO SLIDE NORME TECNICHE INTERNAZIONALI ISO TR 14969:2004 Medical devices Quality management systems Guidance on the application of ISO 13485:2003 ISO (2007): applicazione della valutazione del rischio ai dispositivi medici IEC 62304, Ed. 1: Medical device software Software life cycle processes, computer software IEC Medical devices Application of usability engineering to medical devices (2007) IEC (2006) processi relativi al ciclo di vita per lo sviluppo di software per dispositivi medici IEC :2005, Medical electrical equipment Part 1: General requirements for basic safety and essential performance IEC (2009) applicazione del risk management alle reti it che includono dispositivi medici parte 1: ruoli, responsabilità e attività IEC Application of risk management for IT-networks incorporating medical devices IEC TR Medical device software Guidance on the application of ISO to medical device software ISO/IEC 90003:2004 Software engineering Guidelines for the application of ISO 9001:2000 to computer software ISO/IEC sulla tematica della sicurezza informatica in sanità Information security management in health using ISO/IEC ISO/IEC 27000, Information security management systems

27 Cosa si intende per classificazione del Software a) Determinare la destinazione d uso (è un dispositivo medico oppure no?) b) Classe di rischio(a-b-c)vs(aimd/md/mda/ivd) c) Contesto Paese

28 Classificazione SAMD il software stand-alone deve avere uno scopo medico per essere qualificato come un dm. Inoltre, occorre notare fin da subito che la destinazione d uso come descritta dal fabbricante è rilevante ai fini della sua qualificazione e classificazione a prescindere dalla sua denominazione. Il discrimine fondamentale per qualificare il proprio software come DM è fornito dal dettato dell art.1 della direttiva 93/42, il quale stabilisce che qualora un software: 1) permetta di effettuare una diagnosi, 2) elaborare dati a fini medici, quindi per riassumere, fornisca elementi che possano indurre l operatore sanitario ad effettuare una diagnosi errata e, conseguentemente, arrecare un danno al paziente, si è in presenza di un dispositivo medico. Il software stand-alone che non rientra nella definizione di DM o IVD ma che è destinato secondo il fabbricante ad esserne un accessorio ricade nello scopo delle già richiamate Direttive e segue la classificazione del DM principale.

29 Classificazione SAMD 1. Il software esegue un azione sui dati diversa da archiviazione, immagazzinamento o semplice ricerca? Se il software esegue un azione limitata all archiviazione, immagazzinamento, semplice ricerca NON È UN DM. 2. L azione del software porta benefici al paziente? Se la risposta è negativa (es. si tratta di un software utilizzato per fini statistici) allora NON È UN DM. Se la risposta è positiva (es. un software che monitora determinati parametri del paziente al fine di supportarne e influenzarne la terapia) allora È UN DM. 3. L azione del software include uno degli scopi tipici di un DM? Se la risposta è positiva, allora il software è un DM. Tuttavia, se il fabbricante ha aggiunto anche solo una finalità non medicale (ad es. la gestione degli stipendi del personale) allora NON È UN DM. I software stand-alone che pilotano un altro DM o ne influenzano l uso ricadono automaticamente nella stessa classe del dispositivo che gestiscono

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

31 Regola 9 Tutti i dispositivi attivi terapeutici destinati a rilasciare o a scambiare energia rientrano nella classe IIa a meno che le loro caratteristiche siano tali da permettere loro di rilasciare energia al corpo umano o scambiare energia con il corpo umano in forma potenzialmente pericolosa, tenuto conto della natura, della densità e della parte in cui è applicata l'energia, nel qual caso essi rientrano nella classe IIb. Tutti i dispositivi attivi destinati a controllare o a sorvegliare le prestazioni di dispositivi attivi terapeutici appartenenti alla classe IIb, o destinati ad influenzare direttamente la prestazione di tali dispositivi, rientrano nella classe IIb. Regola 10 I dispositivi attivi destinati alla diagnosi rientrano nella classe IIa se: - 1)sono destinati a rilasciare energia che sarà assorbita dal corpo umano, ad esclusione dei dispositivi utilizzati per illuminare il corpo del paziente nello spettro visibile; 2) sono destinati a visualizzare in vivo la distribuzione di radio farmaci in vivo; - 3) sono destinati a consentire una diagnosi diretta o un controllo dei processi fisiologici vitali, a meno che siano specificamente destinati a controllare i parametri fisiologici vitali, ove la natura delle variazioni è tale da poter creare un pericolo immediato per il paziente, per esempio le variazioni delle funzioni cardiache, della respirazione o dell'attività del sistema nervoso centrale, nel qual caso essi rientrano nella classe IIb. I dispositivi attivi destinati ad emettere radiazioni ionizzanti e destinati alla diagnosi, alla radioterapia o alla radiologia d'intervento, compresi i dispositivi che li controllano o che influenzano direttamente la loro prestazione, rientrano nella classe IIb. Regola 11 Tutti i dispositivi attivi destinati a somministrare e/o a sottrarre medicinali, liquidi corporei o altre sostanze dal corpo rientrano nella classe IIa, a meno che ciò sia effettuato in una forma: - potenzialmente pericolosa, tenuto conto della natura delle sostanze in questione, della parte del corpo interessata e del modo di applicazione, nel qual caso essi rientrano nella classe IIb. Regola 12 Tutti gli altri dispositivi attivi rientrano nella classe I.

32 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 ).

33 Classificazione SAMD Il Software qualificato come DM segue esattamente lo stesso percorso degli altri dispositivi Determinare la classe di appartenenza del dispositivo Scegliere la procedura CE di certificazione da applicare Redigere la Dichiarazione di Conformità (DoC) Fondamentali : o Le Direttive di riferimento MD 93/42 - IVD 98/79 - AIMD 90/385 e la 2007/47 emendamenti o Linee Guida MEDDEV 2.4/1 rev.9 classificazione MD e MEDDEV 2.1/6 (qualification and classification of stand alone software) o Raccomandazione NB-MED/2.2/Rec4 Revision 5, Software and Medical Devices o La lista degli standard armonizzati con le Direttive

34 Step per la certificazione La prima domanda da porsi è se il software sia un dispositivo medico o meno Tenuto conto della destinazione d'uso (scopi diagnostici o di terapia), la Linea Guida MEDDEV 2.1/6 riporta 2 schemi decisionali di supporto per qualificare il software come DM o IVD La guida contiene anche un elenco completo di esempi nell'allegato 1, con i tipi di software che si qualificano o meno come dispositivi medici. Software che NON sono dispositivi medici: 1. Sistemi di gestione dati amministrativi dei pazienti (calendario o la fatturazione) 2. Sistemi di gestione delle prescrizioni (eccetto se riguardano il calcolo della dose di farmaco utilizzando i dati del paziente come il peso o l indice di massa corporea che sono DM) 3. Sistemi di memorizzazione dati dei pazienti, senza elaborazione dei dati 4. Radiological Information System (RIS). ATTENZIONE: questi tipi di software non sono qualificati come DM in UE ma possono qualificarsi come DM in altre regioni del mondo, soprattutto negli Stati Uniti.

35 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

36 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 software come dispositivo medico-diagnostico in vitro

37 Classificazione SAMD Per qualificare e classificare correttamente il software è necessario prendere in considerazione 5 fattori 1.Destinazione d uso 2.Contesto di destinazione 3.Uso effettivo 4.Contesto d uso 5.Possibili effetti sulla salute e/o sulla sicurezza Fonte: guida tecnica CEI gestione software nel contesto sanitario (slides 39,40,41,42,43)

38 Classificazione SAMD 1. Destinazione d uso informazioni rese disponibili dal Fabbricante per identificare lo scopo del prodotto. Per i DM, ed altre tipologie di prodotti, il Fabbricante ha l obbligo di indicare la destinazione d uso. Per altri prodotti, se il Fabbricante non dichiara informazioni in merito, la destinazione d uso può essere desunta dalle informazioni globali/ descrittive fornite dal Fabbricante. Al fine di una corretta qualificazione del software, è importante capire dalla destinazione d uso (o dalle informazioni globali/descrittive fornite dal Fabbricante) se un prodotto abbia: o uno scopo sanitario indicato o uno scopo generico, o o uno scopo che escluda esplicitamente l'utilizzo ai fini sanitari. Per ottenere le informazioni necessarie l azienda sanitaria deve fare riferimento alle norme che obbligano i fornitori a dare sistemi opportunamente documentati (es. UNI EN ISO 12967).

39 Classificazione SAMD 2.Contesto di destinazione E stabilito dal Fabbricante, che dichiara se il suo prodotto è destinato ad un ambiente particolare (industriale, sanitario, domestico...). In molti casi il contesto di destinazione non è specificato ma si evince dall insieme delle informazioni fornite dal Fabbricante, a partire dallo scopo. Può essere anche specificato in negativo, dichiarando che il prodotto non è destinato a particolari contesti di destinazione.

40 Classificazione SAMD 3.Uso effettivo L'uso effettivo di un software dipende: dal contesto d uso in cui viene inserito, dal modo di utilizzazione scelto dal suo utilizzatore e dalle sue caratteristiche (o capacità). Il concetto di uso effettivo fa quindi riferimento all'uso reale che verrà fatto del software nella specifica organizzazione, indipendentemente dalla eventuale destinazione d'uso o dalle istruzioni fornite dal fabbricante. La corretta individuazione dell uso effettivo, da parte della AzSan, pone in risalto quali siano i possibili effetti sulla salute, gli eventuali rischi da tenere in considerazione e le relative normative applicabili. La valutazione dell uso effettivo deve comprendere una analisi mirata a stabilire se il software possa o meno avere scopi sanitari a causa dell uso che ne viene fatto (indipendentemente, cioè, dalle eventuali dichiarazioni del fabbricante). Nel caso di DM il rispetto della destinazione d uso è imprescindibile.

41 Classificazione SAMD 4.Contesto d uso Come per l'uso effettivo, il contesto d'uso fa riferimento al contesto di utilizzo del prodotto, piuttosto che alla situazione ipotizzata dal fabbricante (contesto di destinazione). Va quindi individuato, assieme all'uso, dall azienda sanitaria che valuterà, ad esempio, se il prodotto sarà utilizzato in un contesto sanitario o no.

42 Classificazione SAMD 5.Possibili effetti sulla salute e/o sulla sicurezza Anche questo fattore deve essere valutato dall azienda sanitaria. E' probabilmente il fattore che richiede un maggiore impegno nella sua determinazione: va valutato, sulla base dei quattro fattori precedentemente elencati, se un prodotto (utilizzato nello specifico contesto d'uso, nello scenario di uso delineato dall utente) possa avere la capacità di influire, in modo diretto o indiretto, sulla salute o sulla sicurezza degli individui. Vanno tenuti in considerazione tutti i possibili effetti sulla salute, sia voluti che non voluti. Nota: è rilevante notare che: i primi due fattori (Destinazione d uso e Contesto di destinazione) possono essere definiti solo dal FABBRICANTE e quindi l azienda sanitaria non dovrà fare altro che prenderne nota (nel caso di DM sussiste l obbligo per il fabbricante). Gli ultimi tre fattori, invece, possono essere definiti solo dall ON. Una volta identificati e documentati questi fattori sarà possibile qualificare il software.

43 Casi Borderline Tuttavia, può sempre risultare difficile qualificare un software come DM. Esistono i Borderline, di solito riguardano software stand-alone, come SFW che possono essere utilizzati contemporaneamente anche con finalità generiche di benessere oltre a finalità diagnostiche. Anche in questo caso la qualifica di DM deriva dalla destinazione d uso che si attribuirà al proprio prodotto. Ad esempio: La destinazione d uso di una app riporta il registrare e calcolare dati statistici su ciò che l'utente assume e le relative quantità di carboidrati, grassi, etc, è per scopi di benessere generale, non è un dispositivo medico! La destinazione d'uso potrebbe riportare che l app registra e calcola statistiche su ciò che l'utente mangia e le quantità di carboidrati, grassi assunte per la gestione del diabete. La gestione del diabete si configura come un aiuto per il trattamento di una malattia = è un dispositivo medico.

44 Dispositivi medici e destinazione d uso Il fabbricante stabilisce la destinazione d uso Lo stesso software può essere qualificato come un DM o meno, a seconda della decisione del fabbricante 1. Il software accessorio di un DM, è considerato un DM a tutti gli effetti 2. Il software destinato a far funzionare un DM o ad influenzarne l'uso rientra automaticamente nella stessa classe del dm 3. Qualificare un software come un DM può essere un compito difficile, con conseguenze ONEROSE in termini di tempo, denaro e di responsabilità Ci sono casi in cui il fabbricante non può restringere la destinazione d'uso indicata per evitare il campo di applicazione della direttiva dei dispositivi medici. Si prenda ad es. un fabbricante che vende software con una destinazione d uso che riporta benessere generale ma promuove il software per scopi diagnostici o terapeutici o per l'uso in combinazione con un DM in modo tale che esso possa essere visto come un accessorio del DM. Si tratterà di un DM per il suo utilizzo reale, anche se non lo è nella destinazione di uso indicata.

45 Determinare la classe del software I DM sono raggruppati, in funzione della loro complessità e del potenziale rischio per il paziente, in 4 classi: I, IIa, IIb, III La classificazione si attua tenendo conto dell invasività del dispositivo, della sua dipendenza da una fonte di energia (dispositivo attivo) e della durata del tempo di contatto in merito a: la destinazione d uso indicata dal fabbricante le regole di classificazione (Allegato IX Dlgs97/46) Allegato IX, sez.1.4 Il software indipendente (stand-alone) è considerato un dispositivo medico attivo ( regole 9-12 Allegato IX)

47 Redazione del fascicolo tecnico Cosa è il fascicolo tecnico? Il fascicolo tecnico è la summa dei documenti del dispositivo per dimostrare la conformità di quest ultimo con i requisiti delle direttive Compilare il fascicolo tecnico è un obbligo fondamentale nel processo di marcatura CE e include informazioni dettagliate su: la progettazione (design,sviluppo,materiale) la funzione la composizione l'utilizzo la valutazione clinica del dispositivo medico Ne descrive tutti i dettagli costruttivi ed i dati di verifica e validazione, a prova della conformità del prodotto alla direttiva

48 Redazione del fascicolo tecnico un fascicolo tecnico si compone di: 1.La descrizione del DM. Questa sezione include il progetto, le caratteristiche, le prestazioni, immagini rappresentative, la destinazione, popolazione di pazienti, le condizioni di salute, accessori, breve storia del mercato, la classificazione (vedi allegato IX, 93/42) nonché il percorso di valutazione della conformità. È inoltre possibile aggiungere i dati sui materiali del dispositivo 2.La conformità ai requisiti essenziali: la lista di controllo dei requisiti essenziali deve essere riprodotta testualmente dalla direttiva e presentata come una tabella denominata Requisiti Essenziali, standard applicabili, dimostrazione della conformità, e conservazione fisica della documentazione 3.Valutazione del rischio (risk assessment): in cui si riportano le conclusioni e i risultati delle attività di valutazione del rischio, operazione per la quale occorre riferirsi alla EN ISO 14971: 2012 ed al IEC/TR :2009. Il documento di valutazione dei rischi deve essere incluso come allegato. La valutazione del rischio del dispositivo deve comprendere la valutazione della costruzione, i materiali utilizzati, analisi di biocompatibilità, rischio d'infezione o di cross-infection, ed anche i potenziali rischi durante l'uso

49 Redazione del fascicolo tecnico un fascicolo tecnico si compone di (2): 4. Aspetti relativi alla produzione: diagramma di flusso e la descrizione del metodo di fabbricazione che includa fasi di audit e di monitoraggio preventivo, le condizioni di fabbricazione, le certificazioni del sistema di qualità in possesso del costruttore o di eventuali subappaltatori, il controllo dell'etichettatura e della tracciabilità 5. Sistema Qualità: l'azienda produttrice, nel suo complesso, deve essere conforme ai requisiti di qualità espressi nella MDD. La conformità alla norma ISO è il modo di dimostrare l'adempimento a quanto richiesto dagli allegati 6. Sintesi della relazione della valutazione clinica (Clinical Evaluation Report), obbligatoria per tutte le classi di prodotto, come stabilito dalla Direttiva 2007/47. Vedi anche MEDDEV rev.3 in materia di Clinical Evaluation 7. Etichettatura: progetto di etichettatura del dispositivo, simbolo marcatura CE con il numero di identificazione dell ON. L'uso di simboli, in particolare quelli descritti all'interno EN 980 ( in progress new rule) 8. Dichiarazione di conformità, rilasciata dal fabbricante

50 Redazione del fascicolo tecnico Inoltre occorre: stabilire un sistema di tracciabilità i produttori devono mettere in atto un sistema interno di tracciabilità stabilire un sistema di monitoraggio i produttori devono mettere in atto un sistema di sorveglianza sui dispositivi, una volta immessi sul mercato, per valutare le prestazioni del prodotto della fase post-vendita stabilire un sistema di monitoraggio degli incidenti se un incidente od un quasi-incidente vede coinvolto il dispositivo, il produttore è obbligato a notificarlo alle autorità registrare il dispositivo presso le autorità competenti se richiesto dalle leggi locali tenere la documentazione per 5 anni dichiarazione di conformità, documentazione tecnica, i report ed i certificati degli ON devono essere tenuti per almeno 5 anni dopo la cessata produzione del dispositivo

51 Redazione del fascicolo tecnico Esempio di indice di Fascicolo Tecnico: organizzazione del documento generalità sull'azienda localizzazione delle attività, lavorazioni esterne classificazione dei dispositivi ciclo produttivo informazioni all'utilizzatore norme applicabili requisiti essenziali e analisi dei rischi glossario aziendale dichiarazione di conformità manuale della qualità

52

53 Redazione del fascicolo tecnico Rischi diretti e indiretti Conseguenza di un malfunzionamento Può non avvenire istantaneamente, ma come una serie di azioni a causa di problemi Molte volte la sicurezza del paziente o delle informazioni sono gestiste in maniera separata. Questo non è sempre del tutto corretto e può dar luogo ad una serie di problemi o perdita o il ritardo di informazioni o Minor precisione può significare distorsione, errore di calcolo o mix-up di informazioni. o Il requisito di riservatezza comporta la protezione contro divulgazione di info sensibili Lo standard IEC per la compatibilità elettromagnetica dei dispositivi elettromedicali riporta la classificazione del rischio basata sul tempo intercorso tra l insorgere del pericolo e il danno effettivamente riportato dal paziente. Più questo è corto, più alto sarà il rischio. Più lungo sarà il tempo tra i due eventi, più risulterà possibile prevenire qualsiasi danno per il paziente. Invece, qualora il rischio sia correlato a information failure, ossia errore nell elaborazione e la trasmissione di informazioni, errore tipico dei dispositivi diagnostici, si dovrà fare riferimento ai criteri della ISO e dell allegato per gli IVD.

54 Esempio Questo esempio dimostra che nello stabilire la classe occorre considerare con estrema attenzione la destinazione d uso e la relazione rischi/benefic i che deriva dall utilizzo di un certo DM Esempio: se consideriamo un termometro per misurare la temperatura corporea con un software al suo interno, quali fattori dobbiamo valutare per definire il nostro prodotto in classe A, B o classe C? Qualora il termometro riportasse una temperatura sbagliata,potrebbe indurre il medico a prescrivere un farmaco inutile o sbagliato che, nel peggiore dei casi, causi un danno serio del paziente (Classe C) Nel caso in cui il valore errato riportato dal termometro induca il medico a prescrivere un farmaco non pericoloso, il software sarebbe da classificarsi come classe B Se il valore errato elaborato dal software non porta a nessuna conseguenza, se non la ripetizione del trattamento con altro DM non sarà possibile configurare alcun danno (Classe A)

55 Redazione del fascicolo tecnico NELLO STABILIRE LA CLASSE OCCORRE CONSIDERARE CON ESTREMA ATTENZIONE LA DESTINAZIONE D USO E LA RELAZIONE RISCHI/BENEFICI CHE DERIVA DALL UTILIZZO DI UN CERTO DM. L aspetto sicuramente più complicato risiede nella mancanza di corrispondenza tra le classi dei DM e le classi dei software, ben potendo configurarsi un software di Classe A in classe III secondo le direttive. Tuttavia, nella maggioranza dei casi, un software a basso rischio sarà incluso nella classe di rischio più bassa. Classificare in maniera incorretta il proprio software può portare ad un sovraccarico di lavoro molte volte non necessario che non comporterà una maggiore qualità e affidabilità del proprio software. La classe di un software ha ripercussioni sulla progettazione. Infatti, i requisiti della riferiscono che: Classe A: poca documentazione della progettazione, pochi test effettuati Classe B: documentazione della progettazione e test Classe C: documentazione estensiva sulla fase di progettazione e vari test Nella classe C, dovranno essere applicati tutti i paragrafi della IEC nello sviluppo del proprio software. Nella classe A, soli pochi paragrafi, Nella classe B, come si può facilmente immaginare, una via di mezzo.

56 Redazione del fascicolo tecnico Applicazione del Sistema Qualità La ISO risulta troppo generica per tenere in considerazione le specificità del software a scopo medico IEC 62304, è applicabile sia al software indipendente sia al software incorporato in un DM Per ottenere la certificazione secondo lo standard IEC 62304, le aziende devono essere in possesso del certificato valido ai sensi della norma ISO 13485, sottoponendosi all audit della documentazione del Sistema di Gestione Qualità e della documentazione del ciclo di vita specifico del prodotto in conformità allo standard IEC 62304

58 Le indagini cliniche per il software PER OTTENERE LA MARCATURA CE DA PARTE DI UN ON, IL FABBRICANTE DEVE DIMOSTRARE CHE IL PROPRIO DISPOSITIVO SIA CONFORME AI REQUISITI PREVISTI DI SICUREZZA E DI PRESTAZIONE IN CONFORMITÀ ALLE NORME TECNICHE SPECIFICHE (ISO 14155) la conferma dei requisiti clinici previsti per i dispositivi nelle loro normali condizioni di utilizzo la valutazione degli effetti collaterali l'accettabilità del rapporto rischi/benefici Una corretta procedura di valutazione clinica deve comprendere: 1. una valutazione critica dei risultati delle specifiche indagini cliniche condotte sul dispositivo in esame 2. una valutazione critica della letteratura scientifica disponibile sui temi della sicurezza, delle prestazioni, delle caratteristiche di progettazione e della destinazione del DM (quando è dimostrata l'equivalenza tra il DM cui si riferiscono i dati e il dispositivo di cui si vogliono dimostrare le caratteristiche e quando i dati dimostrano adeguatamente la conformità ai requisiti essenziali pertinenti) 3. l analisi critica combinata dei dati clinici ottenuti dalla letteratura scientifica e dalle indagini cliniche condotte.

59 Le indagini cliniche per il software SCOPO: ottenere la marcatura CE per commercializzare un DM (si parla infatti di fase pre-marcatura CE). la valutazione clinica è un processo continuo lungo tutto il ciclo di vita di un dispositivo Da un punto di vista operativo, le indagini cliniche devono basarsi su una serie di domande cui rispondere tramite il processo di gestione del rischio e di analisi di usabilità del fabbricante (Usability Engineering Process) come specificato dalla ISO IEC e confrontato con i requisiti essenziali delle direttive. La valutazione clinica deve trovare il proprio fondamento in dati clinici rilevanti, dedotti da esperienze precedenti, da documentazione scientifica o attendibile per gli stessi dispositivi o simili che possono confermare tali prestazioni

60 Le indagini cliniche per il software Tuttavia, nel caso tali informazioni non fossero disponibili, il fabbricante dovrà svolgere proprie indagini cliniche riportando, specificamente per i software, le seguenti informazioni: Pertinente descrizione dello scopo dell'indagine clinica nei casi in cui: o l indagine sia destinata a valutare l idoneità allo scopo clinico di qualsiasi parte del software, fornendo inoltre indicazioni in merito a come ciò sarà fatto o eventuali specifici protocolli siano volti a valutare il funzionamento del software nel contesto clinico Descrizione degli standard utilizzati nello sviluppo del software (es. IEC/EN 62304, IEC 80002, IEC ) Descrizione della funzione del software, in particolare se: o il funzionamento normale, l'impostazione iniziale, la manutenzione, la taratura, la regolazione o il controllo del dispositivo medico dipendono dal software o il funzionamento del dispositivo medico dipende dall'esecuzione del software, anche se per un tempo limitato o qualsiasi parte del software del dispositivo medico può essere eseguito in modo indipendente su hardware non collegato direttamente al dispositivo medico Descrizione degli aspetti del software in funzione della sicurezza, in particolare: o se la prestazione essenziale dipende dal software (prestazione essenziale è la prestazione la cui assenza sarebbe una minaccia di danno al paziente)se misure di controllo del rischio dipendono dal software o quali possibilità ci sono per un intervento consapevole da parte del personale clinico o del paziente per evitare danni in caso di guasto del software

61 Le indagini cliniche per il software Descrivere la gestione del rischio del software, tra cui: o il processo di gestione del rischio che includa le voci software identificazione delle sequenze causali di eventi che comprendono i difetti del software o se le misure di controllo dei rischi hardware sono utilizzate per prevenire le conseguenze dei difetti del software o se il processo di sviluppo software è usato come misura di controllo del rischio o se la verifica o la validazione del software sono utilizzate come misura di controllo del rischio Descrivere l interfaccia-uomo, tra cui: o Le interfacce utente che il software presenta (destinate a paziente, tecnico ospedaliero, medico, ecc.) o la popolazione bersaglio per ogni tipo di interfaccia utente (ad esempio età, esperienza, lingua, ecc.) fornendo l eventuale documentazione relativa o le prove che sono state fatte prima delle indagini cliniche per valutare l'efficacia delle interfacce utente per ogni popolazione bersaglio, o come questa sarà valutata nello studio o le misure utilizzate per garantire che solo le persone idonee abbiano accesso ai diversi tipi di interfaccia del software Descrivere in che modo il software è protetto, tra cui: o protezione da modifiche accidentali o non autorizzate o individuazione dei soggetti che hanno la facoltà di apportare modifiche software durante la sperimentazione clinica o misure che sono in atto

63 Dati del settore La Commissione nel 2014 ha lanciato una consultazione pubblica su Green Paper on mobile Health Ad oggi sono le apps censite on-line sulle varie piattaforme (itunes, GooglePlay) Il valore di mercato stimato è di 17,6mld Il numero di potenziali utenti raggiungerà la metà della popolazione mondiale 3,4 mld di persone Più di 150 paesi devono sviluppare un quadro regolatorio relativo International Medical Device Regulators Forum (IMDRF) che comprende USA, EU, Canada, Giappone, Australia e Brasile si occupano di armonizzare la materia Fonte: A Digital Agenda for Europe

64 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

65 Scenari futuri mobile applications (Apps) Se una app è un DM, il fabbricante o utilizzatore deve assicurare il rispetto delle leggi per non mettere a rischio la salute degli utilizzatori. Le questioni relative al rischio per la salute dei pazienti derivante dalle app medicali possono quindi essere correttamente affrontate e risolte applicando la regolamentazione dei dispositivi medici alle app medicali Nel qualificare le App il punto di partenza sarà sempre lo stesso evidenziato per il software l art.1 delle due principali direttive europee (90/385(EEC e 93/42/EEC) definisce cosa sia un DM e menziona espressamente il software tra i vari strumenti, apparecchi utilizzati da soli o in combinazione con finalità diagnostico/terapeutiche una app, in quanto associata ad un software con finalità mediche, rientra a sua volta nella definizione di dispositivo medico l FDA ha emanato, nel 2013, di una prima linea guida, aggiornata poi nel 2015, che introduce la definizione di app medicali che rientrano nella definizione di dispositivo medico o sono un accessorio di un dispositivo medico o trasformano una piattaforma mobile in un dispositivo medico

66 Scenari futuri mobile applications (Apps) 1. sia in America che in Europa, ciò che rende DM una app è la destinazione d uso la quale ovviamente deve rientrare in quelle definite come finalità mediche 2. Se l App ricade nella definizione di software e di DM dovrà soddisfare le prescrizioni delle direttive sui DM, al pari di altri prodotti medicali 3. L FDA ha infatti ritenuto di regolamentare solo le app che pongono rischi per la salute. Le altre app che pur rientrando nella definizione di dispositivo medico pongono un rischio basso per la salute dei pazienti, rientrano nella classe definita discrezionalità applicativa 4. Il quadro europeo regolatorio di riferimento per le app che ricadono nella definizione di DM è quello definito dalle due direttive sui DM (90/385/EEC e 93/42/EEC) come integrato dalla direttiva 2007/47 5. Nel caso invece un app non abbia finalità mediche, e non rientri quindi nella fattispecie di DM, non è ad essa applicabile la normativa sui DM, e quindi ricade nel quadro più generale della direttiva sui diritti dei consumatori (2011/83/UE, D LGS 21 febbraio 2014, n. 21, che modifica il codice del consumo, D LGS 6 settembre 2005, n. 206)

67 Scenari futuri mobile applications (Apps) Come il fabbricante, lo sviluppatore di una app, con finalità mediche deve definire precisamente la destinazione d uso della app 1. Lo sviluppatore deve stabilire se la destinazione d uso da lui indicata fa ricadere la app nella definizione di dispositivo medico ex 93/42/EEC 2. In caso affermativo, è necessario indentificare chi si assumerà le responsabilità del fabbricante del dispositivo medico ai sensi della Direttiva 93/42/EEC visto che non sempre sviluppatore e fabbricante coincidono 3. Il fabbricante deve classificare il suo prodotto in base alla classe di rischio, seguendo le regole riportate nell allegato IX della Direttiva 93/42/EEC 4. Una volta classificata la app, il fabbricante deve verificare la rispondenza ai requisiti essenziali delle Direttive, applicando le norme tecniche armonizzate pertinenti 5. Per poter apporre il marchio CE, il fabbricante deve applicare una delle procedure per la marcatura CE e, nel caso di app che ricade nella classe di rischio superiore alla classe I, rivolgersi ad un organismo notificato 6. Nel caso in cui la app medicale venga distribuita attraverso gli app stores, i distributori devono stipulare un contratto di distribuzione specifico ad hoc con il fabbricante.

69 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

70 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 sul software

71 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

72 Conclusioni (2) In conclusione, le sfide per il software stand-alone e le sue nuove tecniche di sviluppo software possono essere riassunte brevemente in 6 punti: 1. SaMD, qualificandosi esclusivamente come software nasce come prodotto che può sin dall inizio beneficiare di una distribuzione globale 1. La rapidità di evoluzione attrae nuovi attori dal di fuori del mondo dei DM senza esperienza specifica né la necessaria conoscenza del quadro regolatorio 2. Lo sviluppo di prototipi iterativi consente di condurre le varie fasi del processo di certificazioni in poco tempo (ad es. la valutazione clinica) 3. I prodotti non sono più esclusivamente indirizzati all operatore sanitario ma al consumatore il quale non ha lo stesso livello di conoscenza e di comprensione dell utilizzo come il medico della diagnosi della malattia e della terapia 4. L'uso di SaMD può essere complementare alla somministrazione delle terapie esistenti ma può anche tentare di sostituirle, nel qual caso può risultare meno conveniente continuare a fornire un certo prodotto di consumo per i fornitori di servizi sanitari 5. Posto che la sicurezza del paziente deve essere la massima priorità, si deve considerare che molte soluzioni innovative vengono ideate da PMI, start-up o spin-off universitari: realtà con a disposizione budget limitati. Un processo di certificazione del software troppo complicato ed oneroso rischia di tagliare fuori dal mercato questi potenziali fabbricanti, ponendo un freno all innovazione medica

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

74 Back-up slides

75 Le norme tecniche di rilevanza ISO TS 25238:2007, Health informatics - Classification of safety risks from health software (norma non armonizzata) ISO TR 27809:2007, Health informatics- Measures for ensuring patient safety of health software (norma non armonizzata) ISO/IEC , Application of risk management for IT-networks incorporating medical devices (norma non armonizzata) IEC TR Medical device software Guidance on the application of ISO to medical device software (norma non armonizzata) EN IEC 62304:2006, Medical device software Software life equipment General requirements for safety Collateral standard: Programmable electrical medical systems (norma armonizzata) EN ISO 14971:2012, Medical devices Application of risk management to medical devices (norma armonizzata) cycle processes (norma armonizzata) EN IEC : A1:1999, Medical electrical EN IEC , Medical electrical equipment General requirements for safety Collateral standard: Usability (norma armonizzata) EN IEC 62366:2007, Medical devices Application of usability engineering to medical devices (norma armonizzata)

76 Scenari futuri mobile applications (Apps) a) Ai sensi della direttive sui DM il fabbricante dell app medicale è la persona fisica o giuridica responsabile della progettazione, della fabbricazione, dell'imballaggio e dell'etichettatura di un dispositivo in vista dell'immissione in commercio a proprio nome, indipendentemente dal fatto che queste operazioni siano eseguite da questa stessa persona o da un terzo per suo conto b) Non sempre lo sviluppatore di una app coincide con il fabbricante del DM. Gli sviluppatori di app possono essere realtà aziendali con centinaia di dipendenti così come un singolo programmatore. Un singolo sviluppatore difficilmente riuscirà a soddisfare (e a darne evidenza) tutte le prescrizioni applicabili al suo prodotto. Nel caso in cui lo sviluppatore faccia affidamento su un azienda più grande, diventerà un suo fornitore, mentre quest ultima diventerà il fabbricante del dispositivo medico. c) In tale contesto, gli app store sembrerebbero configurarsi come i distributori delle app/dm ed in quanto tali devono conoscere le regolamentazioni relative ai dispositivi medici per poter comprendere se le app hanno la corretta certificazione Le autorità competenti hanno il mandato europeo per la sorveglianza e la vigilanza post-market. Tuttavia, attualmente molte app medicali pur essendo DM non hanno il marchio CE e quindi sfuggono qualunque tipo di controllo. Tale aspetto è dovuto alle app intese come oggetti «dematerializzati» la cui catena e gli strumenti del controllo tradizionale risultano difficilmente applicabili e poco efficaci. Qualsiasi app medicale immessa in commercio senza marchio CE è in grado di svincolarsi da questo tipo di controllo.

77 Scenari futuri mobile applications (Apps) Occorre ricordare l applicazione della Direttiva sulla privacy, aspetto che con la funzionalità, l usabilità, l appropriatezza, l accuratezza e affidabilità trova adeguata normazione nel mondo dei dispositivi medici ma non sempre al centro del progetto di sviluppo di un app che solitamente coinvolge uno sviluppatore e una piattaforma di diffusione (App store, Google Play) Per essere legalmente immesso nel mercato europeo un dispositivo medico deve possedere il marchio CE, l elemento che certifica che il dispositivo ha seguito un percorso di valutazione prima dell immissione in commercio e soddisfa quindi i requisiti di sicurezza, protezione della salute e dell ambiente Il possibile percorso decisionale per stabilire se un software, e quindi una app per la salute, ricada nella definizione di dispositivo medico è riportato nella MEDDEV 2.1/6:2012 Discorso a parte è il caso di prodotti software destinati ad essere utilizzati nel contesto dei dispositivi medici impiantabili attivi, nel qual caso rientrano nell ambito di pertinenza della Direttiva 90/385/EEC

78 Apps - conclusioni È fondamentale implementare procedure e metodi per identificare le app presenti sul mercato senza marchio CE nel settore «eheatlh» dato che esiste un quadro regolatorio solido (Direttive Europee sui Dispositivi Medici) l elemento di max rischio per la salute utilizzatori è che molti sviluppatori hanno una conoscenza limitata del contesto normativo dei dispositivi medici, delle prescrizioni delle direttive e delle norme armonizzate applicabili Come evidenziato dal Min della Salute, le prospettive regolatorie in Italia sono due: a) una regolamentazione ad hoc sul modello statunitense, b) una regolamentazione integrativa di quella esistente, in particolare della disciplina in materia di dispositivi medici, sul modello britannico e tedesco

Vedere altro