Spending review e mercati: prezzi, tempi di pagamento, impatto

Transcript

Spending review e mercati: prezzi, tempi di pagamento, impatto
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
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
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
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:
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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”
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
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
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
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
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
le aziende che realizzano (progettano,
NUOVE
producono,installano e commercializzano)
• controlli
VERSIONI
dispositivi medici oltre alla norma ISO
si devono attenere anche alla norma
• test finali di qualità NEL 2016! 9001
13485. Tale normativa ha la medesima
• documentazione
struttura della ISO 9001 (contenuti), ma
alcuni requisiti specifici (es.
• responsabilità della gestione include
sterilizzazione, commercializzazione ,
tracciabilità, immagazzinamento, gestione
• gestione delle risorse
eventi avversi, sorveglianza post-vendita,
blocco e richiamo dal mercato dei DM ).
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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à.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Rapporto Direttive EU-Norme tecniche
ISO/TR 80002-1:2009 Medical device software –
Guidance on the application of ISO 14971 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 14971 insieme allo standard IEC 62304
(di cui dopo). Il rapporto delinea l’approccio proattivo,
anziché reattivo, da tenere nello sviluppare un software
a scopi medici.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Rapporto Direttive EU-Norme tecniche
EN 60601-1 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
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
NORME TECNICHE INTERNAZIONALI
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
ISO TR 14969:2004 Medical devices – Quality management systems – Guidance on the
application of ISO 13485:2003
ARGOMENTO
SLIDE
ISO 14971
(2007): applicazione
della valutazione del rischio ai dispositivi medici
IEC 62304, Ed. 1: Medical device software – Software life cycle processes, computer software
IEC 62366 Medical devices – Application of usability engineering to medical devices (2007)
IEC 62304 (2006) – processi relativi al ciclo di vita per lo sviluppo di software per dispositivi medici
IEC 60601-1:2005, Medical electrical equipment – Part 1: General requirements for basic safety and essential performance
IEC 80000‐1 (2009) ‐ applicazione del risk management alle reti it che includono dispositivi medici – parte 1: ruoli,
responsabilità e attività
IEC 80001 Application of risk management for IT-networks incorporating medical devices
IEC TR 80002 Medical device software – Guidance on the application of ISO 14971 to medical device software
ISO/IEC 90003:2004 Software engineering – Guidelines for the application of ISO 9001:2000 to computer software
ISO/IEC 27799 sulla tematica della sicurezza informatica in sanità Information security
management in health using ISO/IEC 27002
ISO/IEC 27000, Information security management systems
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
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 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)
3)
4)
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.
 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
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.
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 ).
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
2.
3.
4.
Sistemi di gestione dati amministrativi dei pazienti (calendario o la fatturazione)
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)
Sistemi di memorizzazione dati dei pazienti, senza elaborazione dei dati
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.
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
software 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 del software
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 62-237 gestione software nel contesto sanitario – (slides 39,40,41,42,43)
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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).
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
2.
3.
•
•
Il software accessorio di un DM, è considerato un DM a tutti gli effetti
Il software destinato a far funzionare un DM o ad influenzarne l'uso rientra
automaticamente nella stessa classe del dm
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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)
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 80002-1: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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 13485 è 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 2.7.1- 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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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à
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 60601-1 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 14971 e dell’allegato per gli IVD.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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)
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 62304
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 62304 nello sviluppo del
proprio software.
Nella classe A, soli pochi paragrafi,
Nella classe B, come si può facilmente
immaginare, una via di mezzo.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Redazione del fascicolo tecnico

Applicazione del Sistema Qualità
 La ISO 13485 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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
2.
3.
una valutazione critica dei risultati delle specifiche indagini cliniche condotte
sul dispositivo in esame
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)
l’analisi critica combinata dei dati clinici ottenuti dalla letteratura scientifica e
dalle indagini cliniche condotte.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 62366 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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 80001-1)
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Le indagini cliniche per il software



Descrivere la gestione del rischio del software, tra cui:
o
o
o
o
il processo di gestione del rischio che includa le voci software identificazione delle sequenze causali
di eventi che comprendono i difetti del software
se le misure di controllo dei rischi hardware sono utilizzate per prevenire le conseguenze dei difetti
del software
se il processo di sviluppo software è usato come misura di controllo del rischio
se la verifica o la validazione del software sono utilizzate come misura di controllo del rischio
Descrivere l’interfaccia-uomo, tra cui:
o
o
o
o
Le interfacce utente che il software presenta (destinate a paziente, tecnico ospedaliero, medico,
ecc.)
la popolazione bersaglio per ogni tipo di interfaccia utente (ad esempio età, esperienza, lingua, ecc.)
fornendo l’eventuale documentazione relativa
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
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
o
o
protezione da modifiche accidentali o non autorizzate
individuazione dei soggetti che hanno la facoltà di apportare modifiche software durante la
sperimentazione clinica
misure che sono in atto
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Dati del settore
•
•
•
•
•
•
La Commissione nel 2014 ha
lanciato una consultazione
pubblica su ‘Green Paper on
mobile Health’
Ad oggi sono 100.000 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
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
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Scenari futuri – mobile applications (Apps)
1.
2.
3.
4.
5.
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
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
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”
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
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)
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
2.
3.
4.
5.
6.
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
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
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
Una volta classificata la app, il fabbricante deve verificare la rispondenza ai
requisiti essenziali delle Direttive, applicando le norme tecniche armonizzate
pertinenti
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
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
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 sul 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
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
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 .
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
Back-up slides
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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 80001-1, Application of risk management for IT-networks incorporating medical
devices (norma non armonizzata)
IEC TR 80002-1 Medical device software – Guidance on the application of ISO 14971 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 60601-1-4:1996 + A1:1999, Medical electrical
EN IEC 60601-1-6, 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)
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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.
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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
Applicazione delle Direttive e delle norme tecniche per il processo di certificazione del software
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