La certificazione del software ad uso medico

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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Agenda
1.
2.
3.
4.
5.
6.
7.
8.
Premessa
Definizioni
Quadro regolatorio
Rapporto Direttive EU-Norme tecniche
Classificazione del Software
Apps
Nuovo Regolamento
Conclusioni
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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”
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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’applicazione della Direttiva sulla privacy
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 62304 sul software lifecycle
2. IEC 60601-1 Medical electrical
equipment - Part 1: General
requirements for basic safety and
essential performance
3. IEC 62366 Application of usability
engineering to medical devices
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
EN 62304
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Rapporto Direttive EU-Norme tecniche
La IEC 62304 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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
2)
3)
4)
Il prodotto dovrà riportare il fine medico nella destinazione d’uso (come da Direttive) *la MEDDEV 2.1/6. è lo strumento
idoneo da seguire
Il software stand-alone che ha uno scopo medico è considerato un DM attivo
La classificazione dipende dal rischio che l’utilizzo del software comporta per il
paziente e l’utilizzatore
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 ).
Meddev 2.1/6 – flow chart per procedere alla classificazione del
software come dispositivo medico
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 softw
come dispositivo medico-diagnostico in vitro
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.
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
100.000 le App mediche
già disponibili sul
mercato a disposizione di
500 milioni di potenziali
utenti
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
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
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
GRAZIE PER L’ATTENZIONE
[email protected]
[email protected]
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.