ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA

CAMPUS DI CESENA
SCUOLA DI INGEGNERIA E ARCHITETTURA

CORSO DI LAUREA MAGISTRALE IN INGEGNERIA BIOMEDICA

TITOLO DELLA TESI

VALIDAZIONE DEL SOFTWARE IN AMBITO CLINICO:

IL PROGETTO CHROMO4VIS PER IL TRATTAMENTO DEL
CHERATOCONO

Tesi in

Bioimmagini LM

Relatore Presentata da

Prof. Ing. Cristiana Corsi Lilliu Luigi

Correlatori

Ing. Luca Del Tongo

Dott.ssa Marisa Testa
Ing. Silvia Tamarri

Anno Accademico 2017/2018

2

2
 3

Introduzione
Nel presente lavoro si affronterà il tema del software medicale, che negli ultimi anni, grazie alle
innovazioni tecnologiche, ha avuto un impatto sempre maggiore in termini di impiego terapeutico.
Nella prima parte si introdurrà il concetto di Software Medicale inteso come dispositivo medico e le
sue relative peculiarità. Successivamente si tratterà la validazione del software medicale all’interno
di contesti internazionali come il contesto europeo e degli Stati Uniti d’America, Verranno
approfonditi i concetti di verifica e validazione di un software medicale ed il processo di sviluppo del
software medicale, per garantire una progettazione sicura ed affidabile del software in ambito clinico.
La seconda parte del lavoro va invece ad utilizzare i concetti studiati nella prima parte per applicarli
ad un progetto innovativo. Il progetto Chromo4Vis è un dispositivo progettato per trattare una
patologia degenerativa della cornea, il cheratocono. Dopo una breve introduzione alla patologia, verrà
mostrata la tecnica più efficace per contrastarlo, il cross-linking corneale. Successivamente, verrà
dapprima introdotta la parte HW/SW del dispositivo per poi concentrarsi sulla validazione di un
requisito software, la valutazione della concentrazione della riboflavina durante il trattamento di
cross-linking corneale. Tale valutazione sarà effettuata tramite la creazione di una classe in C# che
conterrà il metodo per il calcolo della concentrazione ed un’altra classe per il test del metodo.
Quest’ultima classe, in particolare, implementerà lo Unit Test necessario a validare il corretto
funzionamento del metodo di calcolo.

3
4

Ringrazio la dott.ssa Testa, l’ing. Del Tongo e

l’ing. Tamarri per avermi permesso di realizzare
questo lavoro di tesi. Ringrazio la mia famiglia
per avermi sostenuto sempre e comunque
durante questo percorso di studi. Ringrazio la
mia fidanzata Francesca per essermi stata vicina
in ogni momento, ringrazio amici e colleghi con
cui ho condiviso questa esperienza

4
 5

Indice

Introduzione ...................................................................................................................................................... 3

Capitolo 1 .......................................................................................................................................................... 7

1.1 I dispositivi medici (DM) ......................................................................................................................... 7

1.2 L’importanza del software nella pratica clinica ................................................................................... 10

1.3 Il software come dispositivo medico (SaMD) ........................................................................................ 17

1.4 Principi di categorizzazione e categorie SaMD .................................................................................... 26

Capitolo 2 ........................................................................................................................................................ 33

2 Il quadro regolatorio in Europa ............................................................................................................... 33

2.1 Lo standard CEI EN 62304:2006 ...................................................................................................... 33

Capitolo 3 ........................................................................................................................................................ 54

3. Quadro regolatorio negli USA ................................................................................................................ 54

3.1 La linea guida di riferimento: “General Principles of Software Validation” .................................. 56

Capitolo 4 ........................................................................................................................................................ 79

4.1 Il progetto Chromo4Vis ......................................................................................................................... 79

4.2 Il Cheratocono ....................................................................................................................................... 79

4.3 Progettazione fisica del dispositivo C4V ............................................................................................... 89

4.4 Lo sviluppo Software presso Visia Imaging ........................................................................................ 100

4.5 Test del Software ................................................................................................................................. 111

4.6 Validazione di un requisito software ................................................................................................... 114

Conclusioni ................................................................................................................................................... 119

5
6

6
 7

Capitolo 1

1.1 I dispositivi medici (DM)

La Direttiva europea 93/42/CEE [1] sui dispositivi medici, definisce come dispositivo medico (DM)
o medical device (MD):

“qualunque strumento, apparecchio, impianto, software, sostanza o altro prodotto, utilizzato da solo
o in combinazione, compreso il software destinato dal fabbricante ad essere impiegato
specificatamente con finalità diagnostiche 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; di diagnosi, prevenzione, controllo, terapia,
attenuazione o compensazione di una ferita o di un handicap, di studio, sostituzione o modifica
dell’anatomia o di un processo fisiologico, di intervento sul concepimento, il quale prodotto non
eserciti l’azione principale, nel o sul corpo umano, cui è destinato, con mezzi farmacologici o
immunologici né mediante processo metabolico ma la cui funzione possa essere coadiuvata da tali
mezzi.”

I dispositivi medici vengono suddivisi, secondo le normative comunitarie, in tre categorie:

1. Dispositivo medico impiantabile attivo: un qualsiasi dispositivo destinato a:

 essere impiantato totalmente nel corpo umano, oppure
 sostituire una superficie epiteliale o la superficie oculare, mediante intervento chirurgico
e a rimanere in tale sede dopo l'intervento
Come dispositivo impiantabile viene considerato anche qualsiasi dispositivo destinato ad
essere introdotto parzialmente nel corpo umano mediante intervento chirurgico e a rimanere
in tale sede dopo l'intervento per un periodo di almeno trenta giorni. In particolare, un
dispositivo medico impiantabile attivo è un dispositivo medico 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.
Un dispositivo medico destinato a trasmettere, senza modificazioni di rilievo, l'energia,
sostanze o altri elementi tra un dispositivo medico e il paziente non è considerato un
dispositivo medico attivo;

2. Dispositivo medico diagnostico in vitro (IVD): un qualsiasi dispositivo composto da un

reagente, da un prodotto reattivo, da uno strumento, da un apparecchio o da un sistema

7
 8

utilizzato da solo o in combinazione, destinato dal fabbricante ad essere impiegato in vitro per
l’esame di campioni provenienti dal corpo umano al fine di fornire informazioni sugli stati
fisiologici o sugli stati sanitari o di malattia o anomalia congenita;

3. Dispositivo medico (in genere): qualunque altro dispositivo medico che non ricade nelle prime
due categorie

I dispositivi medici, in base alla vulnerabilità del corpo umano e tenendo conto dei rischi potenziali
connessi, sono suddivisi dalla Direttiva europea 93/42/CEE [1], nelle seguenti classi di rischio:

 Classe I: dispositivi non sterilizzati/non per misure e sterilizzati/per misure; sono dispositivi
a basso rischio e non invasivi come medicazioni non-sterili per ferite o stetoscopi;

 Classe IIa: sono dispositivi a medio rischio, non invasivi, come tubi tracheali e bisturi;

 Classe IIb: sono dispositivi a medio rischio, spesso chirurgicamente invasivi a lungo termine,
come dispositivi di registrazione di immagini diagnostiche ottenute con raggi X (Tubi
radiogeni, TAC, PET), nonché lenti intraoculari, sacche per il sangue e laser chirurgici;

 Classe III: sono dispositivi a più alto rischio, ed invasivi, tra cui tutti i dispositivi impiantabili
attivi come pacemaker e defibrillatori, ma anche valvole cardiache e stent vascolari.

Le classi elencate in precedenza sono stabilite sulla base della Durata e dell’Invasività.

La Durata può essere:

 Temporanea: destinata ad essere utilizzata di norma per una durata continua inferiore a 60
minuti;

 Breve termine: destinata ad essere utilizzata di norma per una durata continua inferiore a 30
giorni;

 Lungo termine: destinata ad essere utilizzata di norma per una durata continua superiore a 30
giorni;

L’Invasività riguarda invece dispositivi che penetrano parzialmente o interamente nel corpo tramite
un orifizio o una superficie corporea. Con “orifizio del corpo” si intende qualsiasi apertura naturale
del corpo, compresa la superficie esterna del globo oculare, oppure qualsiasi apertura artificiale e

8
 9

permanente. Quando un dispositivo penetra attraverso il corpo, ma non attraverso un determinato

orifizio naturale del corpo, è considerato dispositivo invasivo chirurgico. Un esempio sono i
dispositivi impiantabili attivi. Se invece l’orifizio è naturale, il dispositivo è considerato invasivo.
Quando questa regola non è applicabile, il dispositivo è considerato invasivo.
Nella seguente tabella è riassunta la modalità di classificazione spiegata in precedenza, considerando
sia l’invasività del dispositivo che la durata dell’applicazione del dispositivo medico nel corpo
umano:
Durata Classe Invasività
Temporanea Classe I Sterile/di misura Bassa
Temporanea Classe I non sterile/non Bassa
di misura
Breve termine Classe IIa Media
Lungo termine Classe IIb Medio-Alta
Lungo termine Classe III Alta

Tabella 1: Classificazione dei dispositivi medici in funzione della durata ed invasività

Le regole di classificazione appena elencate servono come guida per poter individuare la classe di
appartenenza del dispositivo. In aggiunta, è bene sottolineare che, se un dispositivo è destinato ad
essere utilizzato in combinazione con un altro dispositivo, le regole di classificazione devono
applicarsi separatamente a ciascun dispositivo.
Compreso questo, qualunque sia la tipologia del dispositivo medico si ha che:

“Il Software destinato a far funzionare un dispositivo o ad influenzarne l’uso rientra

automaticamente nella stessa classe del dispositivo.”

Infine, se un dispositivo non è destinato ad essere utilizzato esclusivamente o principalmente in una

determinata parte del corpo, esso deve essere considerato e classificato in base all’utilizzazione più
critica specificata.
Quanto appena visto vale per l’Unione Europea, mentre per gli Stati Uniti la classificazione risulta
essere più snella e dipende dal grado di controllo richiesto per garantire la sicurezza e/o l’efficacia
del dispositivo medico.

La classificazione dei dispositivi medici negli USA consta, per l’appunto, di sole 3 classi:

 Classe I: all’interno di questa classe rientrano dispositivi medici che possiedono le seguenti
caratteristiche: rischio minimo, dispositivo non-sterile e pratiche di produzione semplici,
comuni. Alcuni esempi di dispositivi che presentano queste caratteristiche sono: abbassalingua,

9
 10

stetoscopi tradizionali, sedia a rotelle, guanti di ispezione, serbatoi di ossigeno terapeutici,

semplici dispositivi per facilitare l‘accesso venoso;

 Classe II: all’interno di questa classe rientrano dispositivi medici che possiedono le seguenti
caratteristiche: rischio moderato, dispositivi che possiedono Software (SW), Firmware (FW) e
dispositivi diagnostici. Alcuni esempi di dispositivi che presentano queste caratteristiche sono:
glucometri digitali, monitor per segnali vitali, strumenti elettrici chirurgici o di misura,
macchine ad ultrasuoni e diagnostiche in vitro;

 Classe III: All’interno di questa classe rientrano dispositivi medici che possiedono le seguenti
caratteristiche: rischio elevato; dispositivi impiantabili (>30 giorni), dispositivi che trasportano
grandi quantità di energia. Alcuni esempi di dispositivi che presentano queste caratteristiche
sono: pacemaker impiantabili, protesi mammarie, protesi d’anca e di ginocchio, ventricoli
artificiali, protesi valvolari cardiache e stent aortici;

Con l’aumentare della classe del dispositivo aumenta contemporaneamente anche il rischio per la
salute del paziente. [1]

1.2 L’importanza del software nella pratica clinica

Ad oggi, il software medicale riveste sempre più un ruolo rilevante nella pratica clinica.
Come per ogni tecnologia che si innova e cambia il suo ruolo nel tempo, anche per il software
medicale, nella pratica clinica, bisogna considerare sia i rischi che i benefici. Lo stato dell’arte della
tecnologia software, da un lato, offre oggi grandi possibilità di applicazione dei software medicali nei
più diversi ambiti clinici. Questo comporta, dall’altro lato, anche rischi derivanti da possibili minacce
informatiche provenienti dalla rete interna, ma anche dall’esterno, soprattutto nelle tecnologie
wireless. In questo capitolo andiamo a delineare alcuni tra i possibili ambiti di applicazione dei
software medicali, cercando di evidenziare i potenziali rischi a fronte, ovviamente, dei benefici
apportati.
I software di apparecchiature di Imaging come TAC1 e RMN2, impiegati normalmente per
l’acquisizione di immagini digitali a scopo diagnostico, giocano un ruolo ancora più importante se
tali apparecchiature vengono impiegate in fase intra-operatoria, ossia per l’esecuzione di interventi

1
La Tomografia Computerizzata detta anche TAC (Tomografia Assiale Computerizzata), è una tecnica diagnostica che fa uso dei raggi X, questi vengono posti in
rotazione attorno alla testa o al corpo del paziente, i raggi X penetrano e vengono catturati da un rivelatore della radiazione, il processo permette di ottenere tante immagini
anatomiche del paziente [2]
2
La Risonanza Magnetica Nucleare detta anche RM (Risonanza Magnetica), è una tecnica diagnostica non invasiva basata sull’analisi di segnali provenienti da nuclei di H
caratterizzati da spin non nulli, soggetti ad intensi campi magnetici posti in condizioni di risonanza, il processo consente di ottenere tante immagini anatomiche ad alata
definizione di sezioni del corpo umano [2]

10
 11

chirurgici guidati dalle immagini, si parla in questo caso di chirurgia software-guided ovvero
chirurgia guidata dal software (Figura 1). Negli ultimi due decenni, infatti, medici e ingegneri hanno
collaborato nello sviluppo e realizzazione di sistemi di Imaging intra-operatorio finalizzati al
perfezionamento degli interventi di neurochirurgia. Ecco perché i maggiori ospedali neurochirurgici
sempre più spesso sono dotati di sale operatorie polifunzionali, ovvero che incorporano scanner RMN
e TAC multistrato, per fornire ai chirurghi immagini ed informazioni in tempo reale durante la
procedura di intervento chirurgico.

Figura 1: neurochirurgia guidata dalle immagini [3]

Perché questa tipologia di informazione sta prendendo sempre più piede? Dai dati raccolti da questi
ospedali si è evidenziato come nel 40% degli interventi il chirurgo abbia modificato l’approccio
operatorio in base alle informazioni aggiuntive acquisite mediante Imaging intraoperatorio.
Prima dello sviluppo di queste tecnologie, le informazioni di questo tipo erano disponibili solamente
dopo il completamento della procedura chirurgica. In molti casi, la RMN intraoperatoria ha permesso
di visualizzare ed identificare residui di tessuto tumorale ed ha permesso quindi una resezione
completa, che altrimenti non sarebbe stata possibile se non sottoponendo il paziente ad un ulteriore
intervento. La tecnologia e l’innovazione permettono oggi di avere sul mercato anche software per la
pianificazione chirurgica 3D, già da tempo impiegati nell’implantologia dentale. In questa branca si
sfruttano software molto evoluti che riescono a manipolare i dati della TAC, trasformandoli in
strutture anatomiche digitali, è possibile quindi eseguire preventivamente l’intervento in modo
virtuale. Nell’implantologia dentale è possibile, inoltre, decidere diametro e lunghezza degli impianti
che supporteranno la protesi fissa, la loro esatta posizione, la qualità e lo stato dell’osso in cui essi
dovranno essere inseriti (Figura 2).

Figura 2: software 3D per la pianificazione di interventi di implantologia dentale [3]

11
 12

Parliamo quindi di un vero e proprio intervento virtuale che permette una pianificazione nei minimi
dettagli di quello che poi sarà l’intervento reale.
L’esecuzione di interventi pianificati attraverso software di ricostruzione 3D permette inoltre di
ottenere risultati post-operatori migliori, quindi una miglior riuscita dell’impianto.
La pianificazione chirurgica mediante software interviene anche in situazioni differenti dalla classica
implantologia, ad esempio, può aiutare l’odontoiatria anche in situazioni di estrazioni molto
complicate di denti, complicate in quanto tali denti sono contigui a strutture anatomiche delicate,
quali nervi o importanti vasi sanguigni.
I software di pianificazione chirurgica oggi trovano sempre più ampia applicazione anche in ambito
ortopedico, per esempio per interventi di endoprotesi d’anca (Figura 3).

Figura 3: pianificazione di endoprotesi d'anca da immagini radiografiche [3]

In questi casi, il software si basa su metodi di pianificazione convenzionali, un tempo eseguiti

manualmente, tramite immagini radiografiche.
In modo rapido e mirato è possibile correggere un’adduzione o abduzione, determinare la
compensazione delle lunghezze delle gambe in sede pre-operatoria e post-operatoria e rappresentarla
nell’immagine.

Un altro esempio è il software in grado di pianificare un’osteotomia correttiva femorale o tibiale con
osteotomie semplici o multiple. Vengono automaticamente rilevate posizioni sbagliate degli assi e
corrette automaticamente o manualmente. Per questa tipologia di interventi componenti idonei per
osteosintesi come chiodi, piastre, viti ecc. possono essere selezionati da una banca dati. Parliamo ora
dei software diagnostici, ovvero quei software impiegati per la creazione di dati o immagini,
analogiche o digitali, mediante i quali il medico fornisce la diagnosi per il paziente.
Il trattamento delle immagini, coniugato a tecniche di riconoscimento automatico, è una disciplina
che ha assunto via via maggiore importanza nei campi più svariati. In particolare, in ambito clinico,
queste metodologie consentono di realizzare sistemi software in grado di riconoscere in maniera
automatica o semiautomatica la presenza di patologie nelle immagini diagnostiche, e possono quindi

12
 13

essere di ausilio per il medico nella usuale pratica clinica o in caso di screening. Una delle metodiche
digitali di diagnostica per immagini più diffuse è sicuramente la TAC, fondamentale per la diagnosi
e ormai largamente diffusa data la sua possibile applicazione in tutti i distretti corporei.
Inoltre, grazie a software dedicati, essa permette l’elaborazione tridimensionale delle immagini
acquisite, ponendosi come metodica ottimale per lo studio anche di complesse strutture anatomiche.
La tomografia computerizzata (Figura 4) risulta essere un esame vantaggioso in quanto, nonostante
sia poco invasivo, è in grado di evidenziare bene i dettagli anatomici, i rapporti tra le strutture
anatomiche, di definire la densità degli organi interni e di stabilire la natura delle lesioni.

Figura 4: Immagine di una scansione TAC del cervello [3]

Ad esempio, la dotazione di software dedicati alla diagnostica delle ischemie cerebrali, esame molto
frequente per una TAC di pronto soccorso, consente al medico radiologo di accertare in brevissimo
tempo se il paziente soffre di deficit vascolari neurologici, responsabili delle ischemie3 (Figura 5).

Figura 5: Immagini di una scansione TC per la diagnostica di ischemie cerebrali [3]

Un’altra tipologia di software sommariamente diffusa sono i software terapeutici.

Essi sono software collegati, attraverso la rete (cablata o wireless), ad un dispositivo terapeutico di

3L’ischemia o ictus ischemico è un tipo di ictus che si verifica quando le arterie cerebrali vengono ostruite dalla graduale formazione di una placca aterosclerotica e/o da un

coagulo di sangue, che si forma sopra la placca arteriosclerotica (ictus trombotico) o che proviene dal cuore o da un altro distretto vascolare (ictus trombo-embolico). Circa
l’80% di tutti gli ictus è ischemico. [4]

13
 14

somministrazione o di sottrazione di un farmaco, liquido corporeo o altre sostanze. Un esempio sono

le macchine per il monitoraggio a distanza, i sistemi di pianificazione di radioterapia usati per
calcolare la dose di radiazione ionizzata da somministrare al paziente, o il dosaggio di insulina. Al
fine di supportare i centri diabetologici nella gestione e consultazione di dati dei pazienti diabetici,
alcune aziende hanno sviluppato negli anni la cartella clinica informatizzata diabetologica, per seguire
il paziente sin dal suo primo accesso al reparto memorizzando nel tempo gli esami di laboratorio,
valutando eventuali complicanze e consigliandoli uno specifico percorso educativo/nutrizionale.
In particolare, esistono numerosi software rivolti alle persone affette da diabete di tipo 1 e 2 e dedicati
alla memorizzazione ed elaborazione dei dati clinici e all’autocontrollo glicemico (Figura 6).

Figura 6: cartella informatizzata diabetologica [3]

Tale servizio promuove una gestione più oculata ed un trattamento meno asincrono rispetto all’attuale
pratica ambulatoriale. Il software infatti raccoglie e mostra, attraverso una specifica interfaccia,
l’evoluzione dell’andamento glicemico nel tempo, permettendo al medico di correggere più
rapidamente il trattamento insulinico prescritto migliorando, in tal senso, anche la programmazione
delle visite di controllo periodiche.
Sono ormai di uso comune e consolidato nella pratica clinica i sistemi di monitoraggio di parametri
fisiologici e vitali dei pazienti. Si tratta, in particolare, di piattaforme hardware e software per il
monitoraggio al posto letto del paziente, ma anche di sistemi wireless che consentono di monitorare,
in pazienti non ospedalizzati, parametri fisiologici quali pressione, temperatura, frequenza cardiaca e
altri. Alcuni software al posto letto, oltre al monitoraggio vero e proprio, offrono anche la possibilità
al medico di interagire con tutte le valutazioni funzionali, di laboratorio e diagnostiche fino alla
gestione della cartella clinica.
Talvolta, quindi, per permettere questa duplice funzionalità, i sistemi di monitoraggio sono costituiti
da due monitor separati, uno per le funzioni di monitoraggio e una per la gestione delle informazioni

14
 15

e dei dati del paziente (Figura 7). In alternativa, esistono anche sistemi che permettono entrambe le
funzionalità sullo stesso monitor. In caso di rilevazione di condizioni cliniche critiche per il paziente,
il sistema di monitoraggio permette l’invio di segnali di allarme alla centrale di monitoraggio,
consentendo così un più pronto intervento ed una migliore assistenza da parte del personale sanitario.
Tali sistemi di monitoraggio sono inoltre collegati alla rete sanitaria aziendale, pertanto si
interfacciano con altri applicativi software impiegati all’interno della struttura sanitaria.

Figura 7: sistema di monitoraggio dei parametri a doppio monitor [3]

È chiaro però che attacchi informatici, virus o altro che dovessero colpire il software del sistema, e
quindi la cartella clinica elettronica, potrebbero minare la sicurezza del paziente. In caso di sistemi di
monitoraggio connessi tramite rete wireless, il rischio di minacce informatiche è ancora più alto, è
quindi necessario per questi software dotarsi di sistemi di sicurezza efficaci e adeguati alla tipologia
di dato che i software stessi gestiscono.

Un ulteriore innovazione tecnologica è data dalla telemedicina la quale eroga dei servizi di assistenza
sanitaria in situazioni in cui il professionista della salute ed il paziente, o due professionisti, non si
trovano nella stessa località. La telemedicina quindi comporta la trasmissione di informazioni e dati
di carattere medico al fine di effettuare prevenzione, diagnosi, trattamento e il successivo controllo
dei pazienti. Con la telemedicina si può parlare addirittura di “ricovero virtuale” in quanto è l’ospedale
che va a domicilio del malato. Il vantaggio è che il paziente può pertanto continuare a svolgere le sue
quotidiane attività anche durante il ricovero, il che minimizza lo spostamento del paziente, il tempo
di attesa, i relativi costi e migliora notevolmente il trasferimento delle informazioni.
Un’ultima tecnologia che ha preso sempre più piede negli ultimi anni riguarda la “mobile health”
(mHealth), tale espressione include tutto un insieme di tecnologie definite “mobili”, ossia che
sfruttano comunicazioni wireless applicate all’ambito medico-sanitario.

15
 16

Si tratta certamente di tecnologie con enormi potenzialità migliorative per la salute pubblica
ed individuale. Tuttavia, a fronte di questi benefici, il comitato nazionale di Bioetica ha evidenziato
alcune problematiche relativamente alla sicurezza ed efficacia, alla dipendenza e vulnerabilità
tecnologica e all’autogestione della salute. Alcuni esempi di applicazioni (App) permettono il
collegamento con dispositivi medici al fine di pilotare il dispositivo stesso o visualizzare, salvare,
analizzare o trasmettere i dati del paziente provenienti dal dispositivo medico. Altre App medicali
invece trasformano smartphone o tablet in dispositivi medici regolati usando funzioni quali
telecamera, flash, accelerometri etc. In particolare, queste tecnologie includono:

 Applicazioni mediche che controllano la frequenza cardiaca e la percentuale di saturazione

dell’emoglobina del sangue tramite un pulsossimetro (Figura 8);

Figura 8: App collegata ad un pulsossimetro [3]

 Dispositivi composti da sonde per ecografia addominali, cardiache, tiroidee e per alcuni esami
prenatali, interfacciabili tramite USB al dispositivo mobile (Figura 9);

Figura 9: App collegata ad una sonda ecografica [3]

 Sensori ECG per smartphone, sfigmomanometri e sistemi di monitoraggio (Figura 10);

16
 17

Figura 10: App collegata a sistemi di monitoraggio di parametri fisiologici [3]

Da quanto sopra enunciato si può dedurre come il software sia ormai un elemento imprescindibile nel
settore sanitario; ovviamente, tanto più è evoluta la tecnologia software, tanto maggiori saranno i
benefici che si riescono ad ottenere, sia in termini di prestazioni cliniche, che in termini di risultati
per il paziente. Tuttavia, con i benefici cresceranno di pari passo anche i rischi per il paziente nel caso
in cui il software sia soggetto a minacce informatiche esterne. [3]

1.3 Il software come dispositivo medico (SaMD)

Le applicazioni del software nella pratica clinica e le conseguenti implicazioni per la sicurezza e
protezione dei dati informatici non possono prescindere da ciò che il legislatore europeo ha
disciplinato in materia di software all’interno delle Direttive sui dispositivi medici e sui dispositivi
medico-diagnostici in vitro. [3]

1.3.1 Definizione di software come dispositivo medico e

classificazione

Il termine “Software as a Medical Device” (SaMD) ovvero Software come Dispositivo Medico, è
definito come: “un software destinato ad essere utilizzato per uno o più scopi medici, ed esegue questi
scopi senza essere parte di un dispositivo medico hardware”.
Inoltre, un SaMD può anche fornire:

 Mezzi e suggerimenti per la mitigazione di una malattia;

 Informazione per determinare la compatibilità, detenzione, diagnosi, monitoraggio o
trattamento di condizioni patologiche, stati di salute, malattia o deformità congenite;
 Aiuto nella diagnosi, screening, monitoraggio, determinazione di predisposizioni, prognosi,
predizione, determinazione di stati psicologici; [5]

17
 18

La definizione di software in ambito medicale è stata ridefinita dalla Direttiva 2007/47/CE [6] di
emendamento alla Direttiva 90/385/CEE sui dispositivi medici impiantabili attivi [7] e alla Direttiva
93/42/CEE sui dispositivi medici [1]. La Direttiva 2007/47/CE ha infatti modificato la definizione di
dispositivo medico contenuta nell’articolo 1 richiamato, come segue:

“dispositivo medico, è un qualunque strumento, apparecchio, impianto, software, sostanza o altro

prodotto, utilizzato da solo o in combinazione, compresi gli accessori tra cui il software destinato
dal fabbricante ad essere impiegato specificatamente con finalità diagnostiche e/o terapeutiche e
necessario al corretto funzionamento del dispositivo stesso, destinato dal fabbricante ad essere
impiegato sull’uomo a fini di:

 Diagnosi, prevenzioni, controllo, trattamento o attenuazione di malattie;

 Diagnosi, controllo, trattamento attenuazione o compensazione di una ferita o di un
handicap;
 Studio, sostituzione o modifica dell’anatomia oppure di un processo fisiologico;
 Controllo del concepimento.

Che non eserciti nel o sul corpo umano l’azione principale cui è destinato con mezzi farmacologici,
immunologici o mediante processi metabolici, ma la funzione possa essere coadiuvata da tali mezzi”.

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
ed hanno riconosciuto due distinte tipologie di software a scopo medico:

1. Software embedded: software che è parte integrante di un dispositivo medico;

2. Software standalone: software riconosciuto come dispositivo medico a sé stante (Software as

a Medical Device, o SaMD);

La distinzione principale tra le due tipologie è che il software embedded o integrato costituisce una
parte del dispositivo medico, mentre il software standalone non è incorporato in un dispositivo
medico al momento della sua immissione sul mercato e non necessita dell’hardware, ovvero il
componente fisico di una periferica o di una apparecchiatura elettronica di un dispositivo medico;
quindi è esso stesso un dispositivo medico. [5]
Secondo la Direttiva 2007/47/CE [6]:

18
 19

“è necessario chiarire che il software a sé stante, quando specificatamente destinato dal fabbricante
ad essere impiegato per una o più delle finalità mediche stabilite nella definizione di DM, è un
dispositivo medico”. [6]

Il software standalone che possiede quindi uno scopo medico è considerato, ai fini della sua
classificazione ai sensi dell’allegato IX della Direttiva 93/42/CEE [1], come dispositivo medico
attivo4, cioè come dispositivo dipendente per il suo funzionamento da una fonte di alimentazione.

Che approccio usare per classificare il software come dispositivo medico (DM)?

Utilizzando il diagramma di flusso seguente (Figura 11), si ha che:

1. Se il 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;

3. Se il software non esegue un'azione sui dati o esegue un'azione limitata allo stoccaggio,
archiviazione, comunicazione o semplice ricerca non è un DM;

4. Se il fabbricante intende il software da utilizzare per uno degli scopi di cui all'Articolo 1 bis
della Direttiva 93/42/CEE [8], il software deve essere qualificato come un DM. [9]

4
non va confuso il DM attivo dal dispositivo impiantabile attivo, quest’ultimo difatti presenta caratteristiche peculiari trattate dalla specifica normativa 90/385/CE. I DM
invece trattati dalla normativa 93/42 /CEE possono essere sia passivi, ad esempio stetoscopi, sia attivi ovvero che necessitano di un’alimentazione elettrica per poter
funzionare, ad esempio i SaMD [1]

19
 20

START

Il software è un
No programma per
computer?

Il software non contiene istruzioni o Si

sottoprogrammi in un particolare
linguaggio di programmazione particolare

No Il software è incorporato in un
dispositivo medico?

SaMD

Il software sta eseguendo

un’azione sui dati diversa da quella che riguarda
No l’archiviazione, la compressione di dati,
comunicazione o semplice ricerca?

Si
È un software Si
che esegue
valutazioni Il comando in esecuzione porterà
statistiche, No qualche beneficio ai singoli pazienti?
studi clinici,
epidemiologici
o registri
Si

L’azione in esecuzione è stata fatta

Non è un No tenendo in conto dell’articolo 1.2 a del
dispositivo medico
MDD?

No
Ad esempio Il
software esegue un
comando
riguardante rimborsi
finanziari, gestione
dello staff, senza fini
medici
È un accessorio di
un dispositivo
medico?
Si
Si
In quanto software, Il software fa parte di un
monitora e segue o dispositivo medico
influenza la performance
di un dispositivo medico

Non è coperto da alcuna direttiva sui dispositivi medici

Coperto dalle direttive sui dispositivi medici

Figura 11: Diagramma di flusso relativo alla classificazione del software come DM [9]

20
 21

Per cui, più in generale:

 Il primo passo è confermare che il prodotto sia effettivamente classificabile come Software as
a Medical Device (SaMD), in conformità con la Direttiva in essere:

o Il prodotto dovrà riportare il fine medico nella destinazione d’uso (come da Direttiva
93/42/CEE, la MEDDEV 2.1/6 [9] è lo strumento idoneo da seguire);
 In seguito, il software standalone che ha uno scopo medico è allora considerato un DM attivo

La Direttiva 2007/47/CE [6] non ha invece emendato la Direttiva 98/79/CE sui dispositivi medico-
diagnostici in vitro [10]. La definizione di dispositivo IVD quindi non include, ad oggi, alcun
riferimento specifico al software. Tuttavia, la MEDDEV 2.1/6 [9], ovvero la linea guida sulla
classificazione del software standalone, specifica che il software standalone, nel momento della sua
immissione in commercio o della sua messa in servizio, può essere qualificato come dispositivo
medico-diagnostico in vitro, a condizione che esso soddisfi la definizione di dispositivo IVD.
Per cui la MEDDEV sopra citata fornisce criteri per qualificare il software come dispositivo medico-
diagnostico in vitro, sulla base delle informazioni fornite dal software stesso. [9]

Che approccio usare per classificare il software come dispositivo medico diagnostico in vitro?

Utilizzando il diagramma di flusso seguente (Figura 12), il quale dice che il software standalone viene
classificato secondo la stessa classe di rischio di un IVD o di un loro accessorio posto che rispondano
ai requisiti delle relative direttive:

 Se le informazioni fornite dal software si basano solo su dati ottenuti da un dispositivo IVD,
il software è un dispositivo IVD e ricade nella disciplina della Direttiva 98/79/CE [10];

 Se le informazioni fornite dal software si basano solo su dati ottenuti da un dispositivo medico,
il software è un dispositivo medico e ricade nella disciplina della Direttiva 93/42/CEE [1];

 Se le informazioni fornite dal software si basano sia su dati ottenuti da un dispositivo medico
che da un dispositivo IVD, il software è un dispositivo IVD e ricade nella disciplina della
Direttiva 98/79/CE. [10] [9]

In particolare, si ha il seguente schema:

21
 22

. Figura 12: flow-chart relativa ad un IVD [9]

Ne segue che, nell’Unione Europea, ogni fabbricante deve assegnare a ciascun software una specifica
classe di sicurezza, simile a quella vista in precedenza sui DM, in relazione ai possibili effetti che
potrebbero nuocere sul paziente. Vi sono tre diverse classi di sicurezza, elencate di seguito:

 Classe A: il software non è suscettibile di produrre alcuna lesione o danno alla salute;
 Classe B: il software è suscettibile di causare lesioni non gravi;
 Classe C: il software è suscettibile di causare morte o lesioni gravi; [11]

Negli Stati Uniti, tuttavia, si utilizza un approccio differente al problema. La documentazione cui fa
capo questo approccio è contenuta nella guida chiamata: “Guidance for the Content of Premarket

22
 23

Submissions for Software Contained in Medical Devices” [12]. Essa fornisce informazioni ai
fabbricanti di dispositivi medici e medici software circa la documentazione da includere all’interno
della commissione pre-market5, dei dispositivi medici software, inclusi i software standalone ed i
dispositivi hardware che incorporano il software.
La politica adottata dalla guida si basa su un principio denominato “The Least Burdensome
Approach” che sta per “approccio meno oneroso”. Difatti è un approccio quantomeno consigliato
dall’FDA per chi intenda classificare il proprio dispositivo come software per immetterlo in seguito
sul mercato. In particolare, FDA consiglia che la documentazione da includere in una richiesta pre-
market sia adeguata al cosiddetto "Level of Concern", ovvero alla classe di rischio del dispositivo.
Il “Level of Concern” del dispositivo mira a stimare la severità del rischio che un dispositivo potrebbe
provocare, sia direttamente che indirettamente, su un paziente od un operatore come risultato di una
falla del dispositivo stesso, difetti progettuali, o semplicemente in virtù del normale impiego del
dispositivo per i suoi specifici usi.
A tal fine FDA raccomanda di descrivere il ruolo che il suddetto software ha nel causare, controllare,
e/o mitigare il rischio che potrebbe convergere in un danno al paziente o all'operatore, cioè su come
le operazioni del software associate al funzionamento del dispositivo possano affliggere il paziente o
l'operatore. Questo è un fattore fondamentale nella determinazione di un appropriato “Level of
Concern” per il dispositivo. Bisogna specificare tuttavia che il “Level of Concern” viene definito
solo per essere utilizzato in questo contesto specifico e non è relazionato alla classificazione del
dispositivo (Classe I, II o III) o all'analisi del rischio.
FDA raccomanda che si debba determinare il “Level of Concern” prima di qualsiasi tentativo di
mitigazione di rischi rilevanti. In altre parole, la determinazione del “Level of Concern” dovrebbe
essere guidata dalle analisi di rischio in assenza di mitigazioni, indipendentemente dagli effetti delle
mitigazioni sui rischi individuali. Infine FDA raccomanda che venga descritto specificatamente come
si sia arrivati a quel determinato “Level of Concern”.

I “Level of Concern” sono tre: Maggiore (Major), Moderato (Moderate) e Minore (Minor):

 Il “Level of Concern” è considerato Maggiore qualora, un guasto o un danno latente, possano

causare direttamente/indirettamente la morte o un danno serio al paziente o ad un operatore.
anche attraverso un'incorretta o ritardata informazione;

5
Rappresenta la procedura necessaria al fine di poter immettere un dispositivo sul mercato, le commissioni pre-market sono: 510(k) (Pre-market Notification), PMA (Pre-
market Approval Application), IDE (Investigational Device Exemption) e HDE (Humanitarian Device Exemption) [12]

23
 24

 Il “Level of Concern” è considerato Moderato, nel caso in cui, un guasto o un danno latente,
possano direttamente/indirettamente risultare in un danno minore al paziente o all'operatore,
anche attraverso l'incorretta o ritardata informazione;

 Il “Level of Concern” è considerato Minore se, un danno o un guasto latente di progetto, è

improbabile causi qualsiasi danno al paziente o all’operatore. [12]

Come viene determinato quindi quale sia lo specifico “Level of Concern”? L’FDA ha messo a
disposizione delle tabelle, ognuna per quel preciso “Level of Concern”, contenente degli specifici
quesiti ai quali bisogna rispondere. Qualora la risposta a qualsiasi domanda sia “No”, si deve
continuare verso la domanda successiva:

Se la risposta a qualsiasi domanda seguente è SI, il “Level of Concern” per quel dispositivo
software è probabile sia quello Maggiore:
1. Il dispositivo software è qualificato come un dispositivo software per le analisi del
sangue?
(Un dispositivo software per le analisi del sangue è definito come prodotti software
intesi per essere usati nella manipolazione del sangue e dei suoi relativi componenti o
per il mantenimento dei dati che il personale del sistema di analisi del sangue usa nel
prendere decisioni riguardo l’adeguatezza dei donatori ed il rilascio del sangue o dei
suoi componenti per la trasfusione o altre manipolazioni)
2. Il dispositivo software è inteso che venga usato in combinazione con farmaci o liquidi
biologici?
3. Il dispositivo software è un accessorio di un dispositivo medico che ha un livello di
interesse maggiore?

4. Prima di mitigare i rischi, può un guasto del dispositivo software risultare nella morte
o in un danno serio, sia al paziente o ad un utente del dispositivo? Esempi di ciò
includono le seguenti domande:

a) Il dispositivo software controlla una funzione di supporto o sostentamento alla vita?

b) Il dispositivo software controlla il rilascio di energia potenzialmente dannosa che può
scaturire nella morte o in un serio danno, come sistemi di trattamento delle radiazioni,
defibrillatori e generatori di ablazione?

24
 25

c) Il dispositivo software controlla il rilascio di un trattamento o terapia nel quale un

errore o malfunzionamento potrebbe risultare nella morte o in un serio danno?
d) Il dispositivo software fornisce un’informazione diagnostica che guida direttamente
una decisione circa il trattamento o la terapia, tale che se applicato erroneamente,
potrebbe causare un serio danno o la morte?
e) Il dispositivo software fornisce il monitoraggio di segnali vitali e allarmi per il
trattamento di potenziali situazioni nelle quali l’intervento medico è necessario?

Tabella 2: relativi quesiti per il livello di interesse maggiore [12]

Se il dispositivo software non ha il livello di interesse maggiore e la risposta a qualsiasi quesito

sottostante è SI, il livello di interesse è probabile sia quello Moderato
1. Il dispositivo software è un accessorio di un dispositivo medico che possiede un livello
di interesse moderato?
2. Primariamente alla mitigazione dei rischi, può un guasto del dispositivo medico
causare una lesione moderata, sia al paziente che all’operatore del dispositivo?
3. Potrebbe un malfunzionamento, o un difetto progettuale latente, nel dispositivo
software portare ad una diagnosi erronea o ad un ritardo nel rilascio di
un’appropriata cura medica che potrebbe probabilmente portare ad una lesione
moderata?

Tabella 3: relativi quesiti per il livello di interesse moderato [12]

Se le risposte a tutte le domande relative alle Tabelle 1 e 2 di sopra sono NO, probabilmente
il livello di interesse appropriato è quello Minore

Tabella 4: relativo quesito per il livello di interesse minore [12]

25
 26

1.4 Principi di categorizzazione e categorie SaMD

Col termine “uso previsto” si intende lo scopo, specificato dal fabbricante, di utilizzo del prodotto,
processo o servizio come stabilito nelle specifiche, istruzioni e informazioni fornite dal fabbricante.
In particolare per categorizzazione si intende la “classificazione” dei dispositivi medici software
tramite dei principi riferiti al suo uso specifico al fine di individuare la classe e la relativa procedura
di registrazione. Ci sono molti aspetti da tenere in considerazione nell’utilizzo in ambito clinico che
possono aumentare o ridurre la probabilità di creare situazioni rischiose ai pazienti.
Esempi di questi aspetti sono:

 Tipologia o condizione della malattia;

 Fragilità del paziente rispetto alla condizione o alla malattia;
 Progressione della malattia o stadio della malattia;
 Usabilità dell’applicazione;
 Progettazione verso un tipo di utente specifico;
 Livello di dipendenza o assegnamento da parte dell’utente, sulle informazioni di output;
 Abilità dell’utente nel rilevare informazioni in uscita erronee;
 Trasparenza di ingressi, uscite e metodi per l’utente;
 Livello di evidenza clinica disponibile e di confidenza sull’evidenza;
 Tipologia di informazione in uscita e livello di influenza sull’intervento clinico;
 Complessità del modello clinico utilizzato per trarre l’informazione in uscita;
 Conoscenza della specificità dell’informazione in uscita;
 Maturità delle basi cliniche del software e fiducia nell’output;
 Benefici dell’informazione di uscita nei confronti di quelli basilari;
 Caratteristiche tecnologiche della piattaforma su cui il software è volto ad operare;
 Metodo di distribuzione del software.

Sebbene molti di questi aspetti possono influenzare l’importanza del dato in uscita dal SaMD, solo
alcuni possono essere identificati dall’uso previsto del SaMD. Generalmente, questi aspetti possono
essere raggruppati all’interno dei seguenti due fattori principali che forniscono una descrizione
adeguata dell’uso previsto del SaMD:

A. Importanza del dato fornito dal SaMD nei confronti della decisione clinica, e
B. La dichiarazione della situazione o condizione dell’assistenza sanitaria

26
 27

Il primo di questi fattori identifica lo scopo medico specifico del SaMD. La dichiarazione dovrebbe
spiegare come il SaMD incontri uno o più scopi descritti nella definizione di dispositivo medico.
Il secondo fattore, invece, identifica la situazione o la condizione dell’assistenza sanitaria per il quale
il SaMD è destinato. Quando questi fattori sono inclusi nella descrizione dell’uso prevista del
fabbricante, essi possono essere utilizzati per “categorizzare” il SaMD.
In particolare, i due fattori “A” e “B” sopraelencati aiutano lo sviluppatore a determinare la categoria
del SaMD nel quadro della categorizzazione. Infine, esiste un ulteriore fattore chiamato “C”, il quale
serve per aiutare i fabbricanti nella gestione delle modifiche del SaMD che possono convergere verso
modifiche della categoria. In particolare esso descrive le funzionalità di base del SaMD e identifica
le sue funzioni critiche, ciò è essenziale per la destinazione d’uso delle informazioni fornite dal SaMD
nei confronti delle decisioni cliniche in una specifica situazione o condizione di assistenza sanitaria.
La destinazione d’uso dell’informazione fornita dal SaMD nella gestione clinica possiede significati
differenti verso l’azione presa dall’utente.

In riferimento alla dichiarazione A, si ha:

 Trattamento e diagnosi: si intende trattare, prevenire o mitigare la connessione con altri

dispositivi medici, prodotti medicinali od altri mezzi che somministrano una terapia verso il
corpo umano. Si intende anche però, diagnosticare e determinare una specifica condizione o
malattia ad esempio sfruttando sensori, dati o altra informazione proveniente da altri dispositivi
hardware o software, relativi a una condizione o malattia;

 Guidare la gestione clinica: per aiutare nel trattamento tramite la fornitura di un supporto alla
salute migliore e l’uso efficace dei prodotti medicinali o di un dispositivo medico. Per aiutare
nella diagnosi tramite l’analisi delle informazioni rilevanti, per aiutare a predire il rischio di
una condizione o malattia o come aiuto per produrre una diagnosi definitiva ed infine per
identificare segni precoci di una condizione o malattia;

 Dare informazioni sulla gestione clinica: per informare circa le opzioni di trattamento,
diagnosi, prevenzione, o mitigazione di una condizione o di una malattia; per fornire
l’informazione clinica tramite l’aggregazione di informazioni pertinenti, come ad esempio
malattia, medicine, dispositivi medici, popolazione etc.;

Ed in merito alla dichiarazione B, si ha:

27
 28

 Situazioni o condizioni critiche: si intendono situazioni o condizioni dove diagnosi accurate

o tempestive o azioni di trattamento sono vitali per evitare la morte, disabilità a lungo termine
o altri gravi deterioramenti della salute di un singolo paziente o di salute pubblica. Il SaMD è
opportuno venga utilizzato in una situazione o condizione critica dove:

o Il tipo di malattia o condizione:

 Riguarda stati di supporto alla vita, inclusi stati incurabili;
 Richiede importanti interventi terapeutici;
 Quando a volte il tempo è critico e, in funzione della progressione della malattia, può
influenzare l’abilità dell’utente di riflettere circa il dato d’uscita;
o La popolazione target designata è fragile rispetto alla malattia o condizione;
o Destinato agli utenti professionisti o specializzati;

 Situazioni o condizioni serie: si intendono situazioni o condizioni dove un’accurata diagnosi

o trattamento è di vitale importanza per evitare interventi non necessari (ad esempio biopsie) o
per interventi tempestivi, importanti per mitigare conseguenze irreversibili nel lungo termine
sulla condizione di salute di un singolo paziente o di salute pubblica. Il SaMD è considerato
per essere utilizzato in una situazione o condizione seria quando:

o La tipologia di malattia o condizione è:

 Moderata nella progressione, spesso curabile;
 Non richiede importanti interventi terapeutici;
 Normalmente, non ci si aspetta che l’intervento sia critico in termini di tempo al fine
di evitare la morte, disabilità a lungo termine o altri seri deterioramenti della salute,
fornendo all’utente l’abilità di rilevare raccomandazioni errate;
o La popolazione target designata non è fragile rispetto alla malattia o condizione;
o Destinato sia per utenti professionisti o specializzati che non professionisti;

 Situazioni o condizioni non serie: si intendono situazioni o condizioni dove una diagnosi
accurata ed il trattamento è importante ma non critico per interventi di mitigazione delle
conseguenze irreversibili nel lungo termine sullo stato di salute di un singolo paziente o di
salute pubblica. Il SaMD è considerato essere utilizzato in una situazione o condizione non
seria quando:

o La tipologia della condizione o malattia è:

 Lenta, con progressione prevedibile dello stato di malattia;

28
 29

 Potrebbe non essere curabile, può essere gestita con efficienza;

 Richiede solo modesti interventi terapeutici;
 Gli interventi sono normalmente di natura non invasiva, fornendo all’utente l’abilità
di rilevare raccomandazioni errate;
o La popolazione target designata è composta di individui i quali non sempre sono pazienti;
o Destinato all’utilizzo sia da utenti professionisti o specializzati sia da utenti non
professionisti.

Si enuncia ora un approccio per categorizzare o classificare i SaMD in base ai fattori identificati nelle
dichiarazioni precedenti. I seguenti principi sono quelli ritenuti necessari da utilizzare nell’approccio
di categorizzazione del SaMD:

 La categorizzazione si basa su un’accurata e completa definizione della dichiarazione del

SaMD;

 La determinazione delle categorie è la combinazione dell’importanza dell’informazione fornita

dal SaMD verso la decisione clinica e dalla situazione o condizione clinica;

 Le quattro categorie, I, II, III e IV, si basano sul livello di impatto sul paziente o sulla sanità
pubblica, dove le informazioni accurate fornite dal SaMD per trattare o diagnosticare, guidare
o informare la gestione clinica è vitale per evitare la morte, disabilità a lungo termine o altri
seri deterioramenti della salute;

 Le categorie hanno un significato relativo l’una all’altra. La categoria IV possiede il livello di

impatto più alto, la categoria I il più basso;

 Quando la definizione della dichiarazione del SaMD del fabbricante indica può essere
utilizzato in diverse situazioni o condizioni di assistenza sanitaria, esso è categorizzato alla più
alta categoria in base alle informazioni incluse nella definizione della dichiarazione del SaMD;

 Quando un fabbricante effettua delle modifiche al SaMD durante il ciclo di vita, il quale risulta
nella modifica della definizione della dichiarazione, la categorizzazione del SaMD dovrebbe
essere rivalutata appropriatamente. Il SaMD è categorizzato secondo le informazioni incluse
nella modifica della definizione della dichiarazione del SaMD;

29
 30

 Il SaMD avrà la sua categoria secondo la sua definizione di dichiarazione anche se un SaMD
si interfaccia con altri SaMD, altri dispositivi medici hardware, o utilizzati come modulo di un
sistema più ampio;

Si riporta sotto la seguente tabella che definisce le categorie per un SaMD:

Importanza dell’informazione fornita dal SaMD

Stato della verso la decisione clinica
situazione o
condizione di salute Trattamento o Guidare la Informare sulla
diagnosi decisione clinica gestione clinica
Critica IV III II

Seria III II I

Non-seria II I I

Tabella 5: Categorizzazione di un SaMD [10]

Vediamo più nel dettaglio i criteri per la determinazione della categoria del SaMD:

 Criterio riferito alla categoria IV:

i. il SaMD che fornisce informazioni per trattare o diagnosticare una malattia in una
situazione o condizione critica appartiene alla categoria IV ed è considerato essere di
grande impatto;

 Criterio riferito alla categoria III:

i. il SaMD che fornisce informazioni per trattare o diagnosticare una malattia in una
situazione o condizione seria appartiene alla categoria III ed è considerato essere di
grande impatto;

ii. Il SaMD che fornisce informazioni per guidare la gestione clinica di una malattia in una
situazione o condizione critica appartiene alla categoria III ed è considerato essere di
grande impatto;

30
 31

 Criterio riferito alla categoria II:

i. il SaMD che fornisce informazioni per trattare o diagnosticare una malattia in una
situazione o condizione non seria appartiene alla categoria II ed è considerato essere di
medio impatto;

ii. Il SaMD che fornisce informazioni per guidare la gestione clinica di una malattia in una
situazione o condizione seria appartiene alla categoria II ed è considerato essere di medio
impatto;

iii. Il SaMD che fornisce informazioni per informare la gestione clinica per una malattia in
una situazione o condizione critica appartiene alla categoria II ed è considerato essere di
medio impatto.

 Criterio riferito alla categoria I:

i. Il SaMD che fornisce informazioni per guidare la gestione clinica di una malattia o di
condizioni in una situazione o condizione non seria appartiene alla categoria I ed è
considerato essere di basso impatto;

ii. Il SaMD che fornisce informazioni per informare la gestione clinica per una malattia o
condizioni in una situazione o condizione seria appartiene alla categoria I ed è
considerato essere di basso impatto;

iii. Il SaMD che fornisce informazioni per informare la gestione clinica per una malattia in
una situazione o condizione non seria appartiene alla categoria I ed è considerato essere
di basso impatto. [5]

Vediamo infine alcuni esempi relativi all’applicazione del quadro di regolarizzazione ampiamente
enunciato in precedenza su alcuni dispositivi medici utilizzati nella pratica clinica (Tabella 6):

31
 32
Categoria Esempio
Un SaMD che esegue l’analisi di immagini diagnostiche
per produrre decisioni sul trattamento in pazienti con
ictus acuto, dove una veloce ed accurata differenziazione
tra ictus ischemico ed emorragico è cruciale al fine di
IV scegliere una precoce inizializzazione della terapia
tromboembolica intravenosa di salvataggio della massa
cerebrale od un intervento di rivascolarizzazione
Un SaMD utilizzato per fornire informazioni tramite
l’approvvigionamento di immagini, monitorando la
crescita o altri dati a supplemento di altre informazioni
III che un fornitore di servizi sanitari utilizza per
diagnosticare se una lesione alla cute è maligna o benigna
Un SaMD che analizza informazioni sul battito cardiaco
II da mostrare ad un medico, come aiuto nella diagnosi di
un’aritmia
Un SaMD che invia tracciati ECG, velocità del passo,
battito cardiaco, distanza percorsa, e località relativa
I all’esercizio di un paziente, basato sulla riabilitazione
cardiaca, verso un server al fine di essere monitorato da
un professionista qualificato
Tabella 6: esempi di categorizzazioni SaMD
32
Motivazione
Questo SaMD sfrutta il criterio della categoria IV,
in quanto l’informazione fornita dal SaMD è
utilizzata per trattare un paziente fragile in una
condizione critica poiché in pericolo di vita, può
richiedere un importante intervento terapeutico, ed
è sensibile al tempo.
Questo SaMD sfrutta il criterio della categoria III,
in quanto l’informazione fornita dal SaMD è
utilizzata come aiuto per diagnosticare una
condizione che può essere pericolosa per la salute,
potrebbe richiedere un intervento terapeutico e
potrebbe essere critica in termini di tempo tramite
l’unione di informazioni rilevanti per rilevare i
segnali precoci di una malattia
Questo SaMD sfrutta il criterio della categoria II,
in quanto l’informazione fornita dal SaMD è
utilizzata per aiutare nella diagnosi di una malattia
in una condizione che può essere di progressione
moderata, potrebbe non richiedere un intervento
terapeutico e tale trattamento normalmente non ci
si aspetta sia critico in termini di tempo
Questo SaMD sfrutta il criterio della categoria I, in
quanto l’informazione fornita dal SaMD è un
insieme di dati per fornire informazioni cliniche
che non possono innescare immediatamente
un’azione a breve termine per il trattamento della
condizione del paziente, la quale non ci si aspetta
sia normalmente critica in termini di tempo al fine
di evitare la morte, disabilità a lungo termine, o
altri gravi deterioramenti della salute
 33

Capitolo 2

2 Il quadro regolatorio in Europa

Nel presente capitolo verranno trattati gli aspetti regolatori necessari a convalidare un software
medicale all’interno dell’Unione Europea, le caratteristiche di applicabilità e le relative peculiarità.
In particolare, verrà analizzata la normativa CEI EN 62304 [11], in cosa consiste e come viene
applicata al fine di validare il software medicale.

2.1 Lo standard CEI EN 62304:2006

Al fine di validare un software medicale nell’Unione Europea, è indispensabile sfruttare la normativa
CEI EN 62304:2006 “Medical device software -- Software life cycle processes” [11]. Tale normativa
è diretta sia ai fabbricanti sia agli utilizzatori ed introduce un approccio sistematico per la
progettazione ed il mantenimento del software durante tutto il suo ciclo di vita. Questa norma non
tratta la validazione e l’immissione del software a scopi medicali, di cui si occuperà la norma IEC
82304-1:20066, e che esula dagli scopi di questo lavoro, bensì richiede solamente che i Processi, le
Attività e le Funzioni siano completati al fine di mantenere la conformità con lo standard. Questo
standard non prescrive inoltre uno specifico modello di ciclo di vita per il software, ma saranno gli
utilizzatori di questo standard ad avere la responsabilità di selezionare uno specifico modello di ciclo
di vita per il progetto del software e di mappare i processi, le attività e le funzioni di questo standard
su quello specifico modello.

2.1.1 Scopo dello standard

Lo scopo di questa norma è quello di raccomandare un processo per lo sviluppo del software come
dispositivo medico, in linea con le Direttive in essere e il sistema di qualità nel settore dei dispositivi
medici. Più precisamente, lo standard, fornisce un quadro dei processi del ciclo di vita del software
con le attività e le funzioni necessarie al mantenimento ed alla sicurezza del dispositivo medico
software.

6
Infatti IEC 82304-1:2016 fa riferimento a IEC 62304 e interseca il suo ambito, ma definisce i requisiti a livello di sistema / prodotto (cioè requisiti di prodotto,
validazione del prodotto, identificazione del prodotto e istruzioni per l'uso, attività post-market)

33
 34

In particolare, in riferimento all’appendice A dello standard, esso definisce un gruppo di processi che
devono essere seguiti nello sviluppo e mantenimento di un dispositivo medico software e che la scelta
di tali processi sia appropriata e commisurata al rischio verso il paziente o terzi, ad esempio medici o
altro personale sanitario.
Nel tempo, purtroppo, sono avvenuti diversi incidenti connessi al servizio o alla manutenzione di
sistemi di dispositivi medici, includendo aggiornamenti e miglioramenti software inappropriati, per
questo motivo il processo globale di mantenimento del software è considerato essere così
importante, quanto il processo di sviluppo del software vero e proprio.
L’appendice A dello standard, spiega come la norma consenta di migliorare:

 L’affidabilità del software richiedendo dettagli e rigore durante le singole fasi di progettazione,
test o verifica;
 La sicurezza del dispositivo medico software;

La norma, in particolare, si applica allo:

 Sviluppo;
 Manutenzione del software, quando:
o esso stesso è un dispositivo medico;
o esso è integrato nel dispositivo medico finale;

2.1.2 Relazione con altri standard

La norma CEI EN 62304:2006 [11] deve essere utilizzata insieme ad altri standard, laddove
appropriati, nello sviluppo di un dispositivo medico, tali relazioni sono mostrate nell’appendice C
dello standard.
Gli standard sulla gestione dei dispositivi medici come gli standard internazionali ISO 14971:2012
“Application of risk management to medical devices” [13] e ISO 13485:2016 “Quality management
systems - Requirements for regulatory purposes” [14] forniscono un’ambiente di gestione che delinea
le basi per sviluppare un dispositivo medico.
In particolare, è molto importante che il fabbricante applichi un processo di gestione del rischio che
sia conforme alla norma ISO 14971:2012 [13]. È obbligatorio infatti, all’interno della
documentazione di processo, inserire un’opportuna analisi del rischio redatta in conformità alla norma
sopracitata all’ultima revisione, la quale, deve includere i pericoli che possono essere causati, anche
indirettamente, dal software stesso.

34
 35

Il fabbricante dovrà quindi identificare i componenti software che potrebbero contribuire ad una
situazione pericolosa (classi B, C).
In particolare il fabbricante prenderà in considerazione le potenziali cause, tra cui:

a) Specifiche errate o incomplete della funzionalità;

b) Difetti del software nella funzionalità del componente identificato;
c) Fallimento o risultati imprevisti da SOUP7;
d) Guasti hardware o altri difetti del software che potrebbero causare operazioni software
imprevedibili; e
e) Uso improprio del software ragionevolmente prevedibile.

Perciò, per uno sviluppo ed una manutenzione sicura del dispositivo medico software è necessario
stabilire una gestione del rischio in conformità con la ISO 14971:2012 [13], integrata ad un sistema
di gestione della qualità conforme alla ISO 13485:2016 [14], delineando un quadro complessivo da
affiancare all’applicazione di appropriate tecniche ingegneristiche. La combinazione di questi tre
concetti porta il fabbricante del dispositivo medico a seguire un processo decisionale chiaramente
strutturato, chiaro e ripetibile al fine di promuovere la sicurezza del dispositivo medico software.
Altri standard sulla sicurezza come gli standard “Medical electrical equipment” CEI EN 60601:2006
[15] e CEI EN 61010-1:2010 “Safety requirements for electrical equipment for measurement,
control, and laboratory use - Part 1: General requirements” [16] si prefiggono come obiettivo quello
di creare dispositivi medici sicuri.
Quando il software è parte integrante di un dispositivo medico, lo standard CEI EN 62304:2006 [11]
fornisce una guida più dettagliata su cosa sia richiesto per sviluppare e mantenere in sicurezza un
dispositivo medico software. Molti altri standard come gli standard ISO/IEC/IEEE 12207:2017
“Systems and software engineering -- Software life cycle processes” [17], IEC 61508:2010
“Functional safety of electrical/electronic/programmable electronic safety-related systems” [18] e
ISO/IEC 90003:2014 “Software engineering -- Guidelines for the application of ISO 9001:2008 to
computer software” [19] possono essere visti come una fonte di metodi, strumenti e tecniche che
possono essere utilizzate per implementare i requisiti della CEI EN 62304:2006 [11].

7
SOUP sta per “Software Of Unknown Provenience”, esso è un Software Item che è già stato sviluppato e disponibile, ma che non è stato sviluppato per essere
incorporato in un dispositivo medico o in un software precedentemente sviluppato per il quale non sono disponibili registrazioni adeguate dei processi di sviluppo, è
conosciuto anche col nome di: “Off-Th-Shelf Software”.[ 11]

35
 36

In figura 13 sono mostrate le relazioni con i vari standard sopracitati, e come questi si interfaccino tra
loro. [11]

Figura 13: relazione della norma CEI 62304 con altri standard [11]

Nel capitolo precedente si è parlato dell’importanza della validazione del software, importanza
considerata alla stregua della progettazione del software stesso. A tal proposito, anche se non implica
direttamente la relazione con la norma CEI EN 62304:2006 [11], questa considerazione sulla
validazione del software è stata recepita a livello normativo con la modificazione all’interno della
Direttiva 93/42/CEE [1], in particolare all’Allegato I dei requisiti essenziali, che recitava:

“12.1. I dispositivi che contengono sistemi elettronici programmabili devono essere progettati in
modo tale da garantire la riproducibilità, l’affidabilità e le prestazioni di questi sistemi
conformemente all’uso cui sono destinati. […]” [1]

Nei confronti della successiva modifica della Direttiva 93/42/CEE (con recepimento della
2007/47/CE) [8], che recita:

36
 37

“12.1. I dispositivi che contengono sistemi elettronici programmabili devono essere progettati in
modo tale da garantire la riproducibilità, l’affidabilità e le prestazioni di questi sistemi
conformemente all’uso cui sono destinati. […]
12.1 bis. Per i dispositivi che incorporano un software o costituiscono in sé un software medico, il
software è convalidato secondo lo stato dell’arte, tenendo conto dei principi del ciclo di vita dello
sviluppo, della gestione dei rischi, della validazione e della verifica.” [8]

Questa modifica sottolinea ancora meglio come una buona e rigorosa progettazione del software
medicale scongiuri da eventuali rischi di ogni tipo. Ovviamente è bene sottolineare anche come non
esista un metodo che garantisca al 100% la sicurezza per ogni tipo di software, bensì tale norma
fornisce delle valide metodologie da seguire per progettare il software medicale secondo i criteri più
stringenti, esaurienti ed efficaci in funzione della sua futura utilità.

2.1.3 Processo di sviluppo del software

Il software è spesso parte integrante della tecnologia del dispositivo medico. Stabilire la sicurezza e
l’efficacia di un dispositivo medico contenente software richiede la conoscenza di ciò che il software
è tenuto a svolgere nonché dimostrare che l’uso del software soddisfi quegli specifici obiettivi senza
causare alcun rischio inaccettabile. Si è accennato in precedenza che la norma CEI EN 62304:2006
fornisce un quadro dei processi del ciclo di vita del software, dove ogni Processo del ciclo di vita è
ulteriormente diviso in diverse Attività, e queste ulteriormente divise in diverse Funzioni.
Per prima cosa è bene specificare che tre sono i termini che identificano le diverse parti da cui può
essere composto un software. Vediamoli più nel dettaglio:

 Software Item: rappresenta qualunque parte identificabile di un programma per computer;

 Software System: rappresenta una raccolta integrata di software item organizzati per compiere
una specifica funzione o una specifica serie di funzioni;
 Software Unit: rappresenta un software item che non può essere più suddiviso in altri item;

Il livello più alto della decomposizione è costituito quindi dal Software System, mentre il livello più
basso non ulteriormente scomponibile è la Software Unit. Tutti i livelli di composizione, compresi i
livelli superiore e inferiore, possono essere chiamati Software Item. Un Software System, quindi, è
composto da uno o più Software Item e ciascun Software Item è composto da una o più Software
Unit o Software Item decomponibili. La responsabilità di fornire la definizione e la granularità dei
Software Item e delle Software Unit è lasciata al fabbricante.

37
 38

La decomposizione software concettualmente è espressa nella figura 14:

Figura 14: decomposizione del software nelle sue principali componenti

Vediamo adesso più nel dettaglio, cosa si intende con i vari stadi di decomposizione software, relativi
al processo del ciclo di vita dello stesso:

 Attività: set di una o più funzioni correlate o interagenti tra loro;

 Funzione: singola operazione che necessita di essere eseguita;
 Processo: set di attività correlate o interagenti tra loro, le quali trasformano gli input in output;

Per cui, il processo di sviluppo del software consta di un certo numero di attività (Figura 15):

Customer needs Activities outside the scope of this standard Customer needs
satisfied

SYSTEM development ACTIVITIES (including RISK MANAGEMENT)

7 SW RISK MANAGEMENT

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

SW SW SW SW SW unit SW integration SW system SW release

development requirement architectural detailed implementation and integration testing
planning analysis design design and verification testing

8 SW configuration management

9 SW problem resolution

Figura 15: panoramica sul processo di sviluppo del software con relative attività e funzioni [11]

38
 39

Andiamo un po' più nel dettaglio dello standard CEI EN 62304:2006. In base all’appendice A della
norma CEI EN 62304:2006, il requisito principale che si riscontra è che una serie di processi devono
susseguirsi nello sviluppo e manutenzione del dispositivo medico software e, che la scelta dei processi
sia appropriata ai rischi verso il paziente e verso terzi. Ciò deriva dalla convinzione che il test del
software non sia sufficiente per determinare che il software sia effettivamente sicuro durante il suo
normale funzionamento.
I Processi richiesti dallo standard ricadono all’interno di due categorie:

1. Processi richiesti per determinare i rischi provenienti dall’operazione di ogni software item
all’interno del software;
2. Processi richiesti per raggiungere una probabilità appropriatamente bassa di errore del software
per ogni software item, scelto sulla base della determinazione di questi rischi;

Lo standard CEI EN 62304:2006 richiede che venga eseguita la prima categoria per tutto il
dispositivo medico software e la seconda categoria per i software item selezionati.

Tutte le attività che sono richieste come parte della prima categoria di processi sono identificate con
la dicitura “(classe A, B, C)”, la quale indica che sono richieste indipendentemente dalla
classificazione del software a cui si applicano.

Le Attività necessarie durante il ciclo di vita del software, nelle classi di sicurezza A, B e C, e che
devono essere documentate, sono:

 L’attività che produce un piano relativo alla gestione dei rischi o alla classificazione della
sicurezza del software;
 L’attività che produce un’uscita che è un input per la gestione del rischio o classificazione di
sicurezza del software;
 L’attività che è una parte della gestione del rischio o della classificazione di sicurezza del
software;
 L'attività che stabilisce un sistema di amministrazione, documentazione o sistema di
conservazione dei registri che supporti la gestione del rischio o la classificazione di sicurezza
del software;
 L’attività che si svolge normalmente quando la classificazione del relativo software è
sconosciuta;

39
 40

 L'attività che può causare una modifica che potrebbe invalidare l'attuale classificazione di
sicurezza del software associato. Ciò include la scoperta e l'analisi dei problemi relativi alla
sicurezza dopo il rilascio.

Le attività necessarie durante il ciclo di vita del software, nelle classi di sicurezza B e C, e che devono
essere documentate, sono:

 L'attività che accresce l'affidabilità del software richiedendo maggiori dettagli o più rigore nel
design, test o altra verifica;
 L'attività amministrativa che supporta un'altra attività richiesta per le classi B o C;
 L'attività che supporta la correzione di problemi legati alla sicurezza;
 L'attività che produce documenti di progettazione, implementazione, verifica e rilascio di
software relativamente alla sicurezza.

Le attività necessarie durante il ciclo di vita del software, nella classe di sicurezza C, e che devono
essere documentate, sono:

 L'attività che migliora ulteriormente l'affidabilità del software richiedendo maggiori dettagli, o
più rigore, o ancora, attenzione a problemi specifici nella progettazione, test o altra verifica;

In base a quanto visto nel capitolo precedente circa la classificazione del software, è bene che il
fabbricante assegni ad ogni Software System una classe di sicurezza, in accordo con i possibili effetti
o rischi sul paziente, sull’operatore, o altro personale nei confronti del quale il Software System può
contribuire. Come già accennato le classi di sicurezza del software devono inizialmente essere
assegnate in funzione della severità, come segue:

 Classe A: non è possibile nessun danno o lesione alla salute;

 Classe B: è possibile un danno di natura non grave;
 Classe C: è possibile un danno o lesione di natura grave, compresa la morte;

Se il rischio dovesse sorgere da una falla del Software System, la probabilità di quel danno deve essere
assunta al valore 100 %.

Tuttavia:

 Se il rischio di morte o di un grave danno, causato da una falla del software, è successivamente
ridotto ad un livello accettabile (come definito dalla norma ISO 14971:2012 [13]) ad esempio

40
 41

tramite una misura hardware di controllo del rischio, o riducendo le conseguenze del danno o
la probabilità di morte derivante da quella falla, la classificazione di sicurezza del software
potrebbe essere ridotta da C a B;
 Se il pericolo di un infortunio di natura non grave, causato da una falla del software, è allo
stesso modo ridotto ad un livello accettabile da una misura hardware di controllo del rischio,
la classificazione di sicurezza del software potrebbe essere ridotta da B ad A.

Il fabbricante dovrà necessariamente documentare la classe di sicurezza del software assegnata ad

ogni Software System, nel documento di gestione del rischio, denominato “Risk Management File”.
Entrando più nello specifico, quando un Software System è decomposto nei suoi Software Items e,
quando un software Item è decomposto in altri Software Item, quel Software Item deve ereditare
necessariamente la classificazione di sicurezza del Software Item originale o del Software System,
salvo che il fabbricante documenti una ben precisa logica a favore della classificazione di sicurezza
del software in differenti classi. Tale logica deve spiegare tuttavia come i nuovi Software Item sono
segregati cosicché possano essere classificati separatamente.
La figura successiva (Figura 16) illustra il possibile partizionamento dei Software Item all'interno di
un Software System e come le classi di sicurezza del software verrebbero applicate al gruppo di
Software Item nella scomposizione.

Figura 16: segregazione della classificazione di sicurezza del software [11]

In questo esempio il fabbricante conosce, per il tipo di dispositivo medico software in fase di sviluppo,
che la classificazione preliminare di sicurezza del software per il Software System, è la classe C.
Durante la progettazione dell’architettura software il costruttore ha deciso di suddividere il sistema,
come mostrato in figura, in tre Software Items: X, W e Z.

Il fabbricante è in grado di aggregare all’interno del Software Item Z tutte le parti del Software System
che potrebbero causare la morte o lesioni gravi e segregare tutti i contributi del Software System, dai
pericoli che potrebbero causare la morte o lesioni gravi, che potrebbero risultare in un danno di natura
non grave, all’interno del Software Item W. Il Software Item W è classificato come classe di sicurezza

41
 42

del software B ed il Software Item Z si trova nella classe di sicurezza del software C. Il Software Item
Y pertanto deve essere classificato come classe C. Il Software System è anch’esso in una classe di
sicurezza del software C per questo requisito. Il Software Item X è stato classificato in una classe di
sicurezza del software A. Il fabbricante è in grado di documentare una logica a favore della
separazione tra Software Item X e Y, così come tra Software Item W e Z, per assicurare l'integrità
della segregazione. Se il partizionamento non fosse possibile i Software Item X e Y devono essere
classificati nella classe di sicurezza del software C.

Lo standard CEI EN 62304:2006, come già accennato, non richiede un particolare modello di ciclo
di vita per lo sviluppo del software, esso però implica dipendenze tra processi, in quanto gli input di
un processo sono generati da un altro processo. Per esempio, la classificazione sulla sicurezza del
sistema software dovrebbe essere completata dopo che il processo di analisi del rischio ha stabilito
quale danno potrebbe esserci da un difetto del sistema software.

Il modello del ciclo di vita dello sviluppo del software è una struttura concettuale che abbraccia tutta
la vita del software, dalla definizione dei suoi requisiti, al suo rilascio per la produzione, il quale:

 Identifica i processi, le attività e le funzioni coinvolte nello sviluppo del Prodotto Software;
 Descrive la sequenza e la dipendenza tra attività e funzioni;
 Identifica le tappe fondamentali nelle quali viene verificata la completezza dell’output
dell’attività e/o funzione richiesta;

A causa della logica dipendenza tra processi, è più facile descrivere questi ultimi tramite una
sequenza, il che implica un ciclo di vita “waterfall” o “once-through”, ma possono essere usati anche
altri cicli di vita. Alcune di queste strategie di sviluppo, come definite dallo standard CEI ISO IEEE
12207 [17], includono:

 Waterfall: è chiamata anche strategia “Once-through”, ad ogni modo tale strategia consiste
nell’esecuzione del processo di sviluppo una sola volta. Più precisamente: si determinano le
necessità dell’utente, vengono definiti i requisiti, viene progettato il sistema, viene
implementato, viene testato, sistemato ed infine viene distribuito;

 Incremental: con la strategia “incrementale” si determinano dapprima i bisogni dell’utente e

si definiscono i requisiti del sistema, poi viene eseguito il resto dello sviluppo in una sequenza
di blocchi. Il primo blocco incorpora parte delle capacità pianificate, il blocco successivo
aggiunge più capacità, e così via, fino a che il sistema risulta essere completo;

42
 43

 Evolutionary: la strategia “evolutiva” sviluppa anch’essa il sistema in blocchi ma differisce

dalla strategia incrementale nel riconoscimento che i bisogni dell’utente non sono
completamente percepiti e tutti i requisiti non possono essere ancora definiti in anticipo. In
questa strategia, i bisogni dell’utente ed i requisiti del sistema sono parzialmente definiti in
anticipo, solo dopo sono rifiniti nei blocchi successivi;

Tali strategie sono riassunte nella seguente tabella:

Strategie di sviluppo Definizione iniziale dei Cicli di sviluppo Distribuzione del

requisiti? multipli? software
provvisorio?
Waterfall (Once-through)
SI NO NO
Incremental (Preplanned product
improvement) SI SI SE APPLICABILE

Evolutionary NO SI SI

Tabella 7: modelli di ciclo di vita, come definite nella norma ISO CEI 12207 [17]

Qualunque sia il modello di ciclo di vita scelto è necessario mantenere le logiche dipendenze tra gli
output dei processi, come specifiche, documenti di progetto e software. Il modello del ciclo di vita
waterfall raggiunge questi obiettivi ritardando l’inizio del processo sino a che gli input per quel
processo sono completi ed approvati. Altri cicli di vita, in particolare i cicli di vita evolutivi,
consentono di produrre l’output di un processo prima che siano disponibili tutti gli input per quel
processo. Ad esempio, un nuovo Software Item può essere specificato, classificato, implementato e
verificato prima che l'intera architettura software sia stata ultimata. Tali cicli di vita portano con sé il
rischio che un cambiamento o uno sviluppo in un output di un processo invalidi l’output di un altro
processo.
In seguito possiamo vedere i principi più importanti riguardo il modello del ciclo di vita dello sviluppo
software:

 Tutti gli output di un processo devono essere mantenuti in uno stato coerente, ogni volta che
l’output di un processo viene creato o modificato, tutti gli output correlati a quel processo
dovrebbero essere aggiornati per mantenere sia la loro coerenza con gli altri output sia tutte
le dipendenze esplicite o implicite richieste dallo standard;

43
 44

 Tutti gli output dei processi devono essere disponibili quando necessari come input per lavori
futuri sul software;
 Prima ancora del rilascio di qualunque dispositivo medico software, tutti gli output di un
processo devono essere coerenti tra loro e tutte le dipendenze, tra gli output di processo
espliciti ed impliciti richiesti dallo standard, dovrebbero essere stati osservati;

Il processo di mantenimento del software è molto simile a quello del suo sviluppo. Esso è mostrato
in Figura 17.

Maintenance
Activities outside the scope of this standard Request
request
satisfied

SYSTEM development ACTIVITIES (including RISK MANAGEMENT)

7 SW RISK MANAGEMENT

6.1 6.2 5.3 5.4 5.5 5.6 5.7 5.8

Establish SW Problem and SW SW SW unit SW integration Software Software

maintenance modification architectural detailed implementation and integration system release
plan analysis design design and verification testing testing

6.3 Modification implementation

8 SW configuration management

9 SW problem resolution

Figura 17: panoramica sul processo di mantenimento del software e relative funzioni [11]

Come si può notare dalla figura precedente, questo standard identifica due processi aggiuntivi,
considerati essenziali per lo sviluppo di dispositivi medici software sicuri. Essi sono il processo di
gestione della configurazione del software (clausola 8) ed il processo di risoluzione dei problemi del
software (clausola 9).

44
 45

Vediamoli un po' più nel dettaglio:

 Processo di gestione della configurazione del software: è un processo che applica procedure
tecniche ed amministrative durante il ciclo di vita del software al fine di identificare e definire
i Software Items, includendo la documentazione, modifiche di controllo e rilascio degli Items
e delle richieste di modifiche. La gestione della configurazione di sistema è necessaria per
ricreare un Software Item, identificare le sue parti costituenti, e provvedere alla creazione di
una storia sulle modifiche apportate. Le richieste di modifica approvate sono rese tracciabili
rispetto alle modifiche effettive ed alla verifica del software. Per cui, l’obiettivo di utilizzare
un sistema di gestione della configurazione è quello di garantire che tutti gli output di un
processo siano portati ad uno stato coerente e le loro dipendenze mantenute;

 Processo di risoluzione dei problemi del software: è un processo usato per analizzare e
risolvere i problemi, qualunque sia la loro natura o la loro fonte, includendo quelli scoperti
durante l’esecuzione dello sviluppo, manutenzione, o durante altri processi. L’obiettivo è
quello di fornire un mezzo tempestivo, responsabile, e documentato per garantire che i
problemi rilevati vengano analizzati e risolti;

Nei prossimi verranno trattati i compiti che il fabbricante del software dovrà soddisfare in relazione
alla norma CEI EN 62304:2006 [11].

2.3.1.1 Piano di sviluppo del software

L'obiettivo di questa attività è quello di pianificare le funzioni di sviluppo del software al fine di
ridurre i rischi causati dal software stesso, comunicare le procedure e gli obiettivi ai membri del team
di sviluppo ed assicurarsi che i requisiti di qualità del sistema per il dispositivo medico software siano
stati soddisfatti.
Il fabbricante, perciò, deve stabilire un piano (o piani) di sviluppo del software per condurre le attività
del processo di sviluppo adeguatamente allo scopo, grandezza e classificazione di sicurezza del
software appartenente al sistema software da sviluppare. La pianificazione è un’attività iterativa che
dovrebbe essere riesaminata ed aggiornata col progredire dello sviluppo. È ovvio che il piano si
evolverà per incorporare maggiori e migliori informazioni man mano che viene compreso il sistema
ed il livello di sforzo necessario per svilupparlo.

45
 46

Il modello del ciclo di vita di sviluppo del software deve essere completamente definito o essere
referenziato nel piano (o nei piani) di sviluppo.
Il piano dovrà contenere dunque le seguenti informazioni:

 I processi da utilizzare nello sviluppo del sistema software;

 I risultati attesi (documentazione inclusa) delle attività e funzioni del software;
 La tracciabilità tra i requisiti di sistema, i requisiti software, i test del sistema software e
l’implementazione delle misure di controllo del rischio nel software;
 La gestione delle modifiche e della configurazione del software, includendo anche il software
utilizzato a supporto dello sviluppo;
 La risoluzione dei problemi del software al fine di gestire problematiche identificate nel
prodotto software, nei risultati attesi e nelle attività, ad ogni fase del ciclo di vita;

2.1.3.2 Analisi dei requisiti del software

Questa attività richiede che il fabbricante stabilisca e verifichi i requisiti per il dispositivo medico
software. Stabilire requisiti verificabili è essenziale, per determinare che il dispositivo medico
software mostri un comportamento accettabile e dimostrare che tale dispositivo completato sia
effettivamente pronto per l'uso.
Per ogni sistema software del dispositivo medico, il fabbricante deve definire e documentare i
requisiti del sistema, tuttavia ci sono evidenti differenze tra i requisiti del sistema software incorporato
nel dispositivo medico ed i requisiti del sistema vero e proprio, se il sistema software è un SaMD,
poiché, in quest’ultimo caso, i requisiti del sistema software e quelli del sistema coinciderebbero.
A fronte di ciò, un'area che genera frequente confusione è data dalla distinzione tra esigenze del
cliente, input di progettazione, requisiti software, specifiche funzionali del software e specifiche di
progettazione del software. È necessario quindi fare chiarezza:

Input di sono l'interpretazione delle esigenze del cliente trasformate in requisiti, formalmente
progettazione documentati, del dispositivo medico

Requisiti sono le specifiche formalmente documentate di ciò che il software fa per

Software soddisfare le esigenze del cliente e gli input del progetto

Specifiche sono spesso incluse nei requisiti del software e definiscono in

funzionali del dettaglio ciò che il software fa per soddisfare i suoi requisiti
software

Specifiche di definiscono come il software sarà progettato e

progettazione scomposto per implementarne i requisiti e le specifiche
del software funzionali

46
 47

Quando appropriato per il software del dispositivo medico, il fabbricante deve includere nei requisiti
del software:

a) I requisiti funzionali e di capacità, tra questi:

 Performance come ad esempio scopo del software, requisiti di sincronizzazione;
 Caratteristiche fisiche, ad esempio linguaggio di programmazione, piattaforma, sistema
operativo;
 Ambiente di sviluppo sotto il quale il software deve essere eseguito, ad esempio
hardware, dimensione della memoria, processore e infrastrutture di collegamento;
 Necessità di compatibilità con gli aggiornamenti, SOUP o altre versioni del dispositivo.
b) Input e output del sistema software:
 Caratteristiche dei dati, ad esempio numerici, alfanumerici, formato;
 Limiti e difetti
c) Interfacce tra il sistema software ed altri sistemi;
d) Allarmi software, avvertenze e messaggi per l’operatore;
e) Requisiti di sicurezza, tra questi:
 Quelli riferiti al compromesso delle informazioni sensibili;
 Autenticazione;
 Autorizzazione;
 Regime di controllo ed integrità di comunicazione;
f) Requisiti di usabilità ingegneristica che sono sensibili ad errori umani, tra questi:
 Supporto per operazioni manuali;
 Interazioni uomo-apparecchiatura;
 Vincoli sul personale;
 Aree che richiedono particolare attenzione umana;
g) Definizione dei dati e requisiti sul database;
h) Requisiti di installazione e di accettazione del trasporto del dispositivo medico software al sito
operativo e di manutenzione;
i) Requisiti riferiti ai metodi di funzionamento e manutenzione;
j) Sviluppo della documentazione utente;
k) Requisiti di manutenzione dell’utente;
l) Requisiti regolatori;

47
 48

2.1.3.3 L’architettura del software

Questa attività richiede che il fabbricante definisca i principali componenti strutturali del software, le
loro proprietà esternamente visibili e le relazioni tra essi.
Il fabbricante deve trasformare i requisiti del dispositivo medico software in una architettura software
documentata, che descriva la struttura del software e ne identifichi i Software Items. Per cui lo scopo
di questa attività è quella di definire l’architettura software che soddisfa tutti i requisiti di progetto
elencati nel piano di sviluppo del software. Il fabbricante deve altresì sviluppare e documentare
un’architettura per le interfacce tra i Software Items ed i componenti esterni ai Software Items (sia
software che hardware), e tra i Software Items (classe B, C).
Se il Software Item è SOUP, il fabbricante deve specificare i requisiti di performance nell’item SOUP
che sono necessari per la destinazione d’uso (Classe B, C), deve altresì specificare il sistema
hardware e software necessari al suo funzionamento.
Il fabbricante infine deve individuare la segregazione tra Software Item, essenziale per il controllo
del rischio, verificando che la segregazione sia efficace (classe C).
È opportuno infine che il fabbricante verifichi e documenti che l’architettura:

a) Implementi il sistema ed i requisiti del software includendo quelli legati al controllo del rischio;
b) Supporti le interfacce tra Software Item e questi ultimi e l’hardware;
c) Supporti il corretto funzionamento di qualsiasi item SOUP, (classe B, C).

2.1.3.4 Lo sviluppo software

Questa attività richiede al fabbricante di perfezionare i Software Item e le interfacce definite

nell'architettura per creare le Software Unit e relative interfacce. Il fabbricante dovrebbe definire il
livello di dettaglio delle Software Unit infatti, la progettazione dettagliata, specifica: algoritmi,
rappresentazioni di dati, interfacce tra diverse Software Unit e interfacce tra Software Unit e strutture
dati. In particolare il fabbricante deve:

a) Rifinire l’architettura software fino al dettaglio delle singole Software Unit (classe B, C);
b) Sviluppare delle specifiche dettagliate di progetto delle singole Software Unit (classe C);
c) Sviluppare specifiche dettagliate di progetto per le interfacce, sia hardware che software
(classe C);
d) Verificare e documentare che le specifiche dettagliate di progetto del software implementino
l’architettura e non contengano alcune contraddizioni con la stessa (Classe C);

48
 49

2.1.3.5 Implementazione e verifica delle software unit, module e

system

Questa attività richiede che il fabbricante scriva e verifichi il codice per le Software Unit.
Lo sviluppo dettagliato deve essere tradotto in codice sorgente, il codice rappresenta infatti il punto
in cui la decomposizione delle specifiche finisce e la composizione del software eseguibile
comincia. Il fabbricante dovrà quindi implementare e verificare le singole Software Unit, i moduli e
l’intero sistema, nonché definire il protocollo di prove da utilizzare nella fase di verifica del codice,
queste attività sono da svolgere solamente per le classi di sicurezza del software B e C. Il protocollo
di prove dovrà contenere il criterio di accettabilità della singola Software Unit.
Alcuni criteri di accettabilità riguardano la verifica:

a) Della corretta sequenza temporale degli eventi;

b) Della corretta implementazione dell’algoritmo;
c) Della corretta gestione degli errori ed eventualmente delle funzioni di autodiagnosi;
d) Della corretta inizializzazione delle variabili;
e) Della corretta gestione della memoria (problemi di overflow);
f) Del comportamento del software con i valori limiti delle variabili d’ingresso.

Il fabbricante inoltre deve eseguire la verifica delle unità software e documentarne i risultati. Questa
attività è da svolgere solamente per le classi di sicurezza del software B e C.

2.1.3.6 Integrazione software e test di integrazione

Questa attività richiede al fabbricante di pianificare ed eseguire l'integrazione delle Software Unit in
Software Item aggregati, nonché l'integrazione di Software Item in Software Item aggregati più
elevati, e per verificare che i Software Item risultanti si comportino come previsto.
I test di integrazione del software si concentrano sul trasferimento dei dati e sul controllo attraverso
le interfacce interne ed esterne dei Software Item. Le interfacce esterne sono quelle con altri software,
incluso il software del sistema operativo e l'hardware del dispositivo medico.
In questa fase perciò il fabbricante deve:

a) Integrare le Software Unit in conformità al piano di integrazione (classe B, C);

b) Verificare l’integrazione in conformità al piano di integrazione (classe B, C).
In particolare deve:
o Integrare le Software Unit nei Software Item e questi nel Software System;
o Integrare nel Software System i componenti hardware, i Software Item e supporti vari;

49
 50

c) Testare l’integrazione dei Software Item in conformità al piano e documentarne i risultati

(classe B, C);
d) Verificare che i Software Item integrati eseguano quanto richiesto (classe B, C)
e) Valutare le procedure di test e verifica dell’integrazione affinché siano corrette (classe B e C).

Il test “White-box”, noto anche come glass box test, structural test, clear box test e open-box test, è
una tecnica di prova in cui vengono utilizzate le conoscenze esplicite del funzionamento interno del
Software Item per selezionare i dati di test. Il test White-box utilizza una conoscenza specifica del
Software Item per esaminare le uscite. Il test è accurato solo se il tester sa ciò che il Software Item
dovrebbe fare e può quindi verificare se il Software Item si discosta o meno dall'obiettivo prefissato.
Il test White-box non può tuttavia garantire che la specifica completa sia stata implementata poiché si
concentra sulla verifica dell'implementazione del Software Item.
Il test “Black-box”, noto anche come test Closed-box, si concentra sul test delle specifiche funzionali
e non può garantire che tutte le parti dell'implementazione siano state testate. Pertanto, il test Black-
box testando la specifica scoprirà i difetti di omissione, indicando che parte della specifica non è stata
soddisfatta. Il test White-box invece testando l'implementazione, ne scoprirà i guasti, indicando che
parte dell'implementazione è difettosa. Per testare completamente un prodotto software potrebbero
essere richiesti dunque sia test White-box che test Black-box.
Inoltre il fabbricante deve:

 Documentare i risultati dei test (passati/falliti ed una lista delle anomalie);

 Conservare documentazione sufficiente per permettere che il test venga ripetuto;
 Identificare il tester;
 Inserire eventuali anomalie rilevate durante l'integrazione del software e le prove di
integrazione, all’interno di un processo di risoluzione dei problemi software;

Queste attività sono da svolgere solamente per le classi di sicurezza del software B e C.

2.1.3.7 Convalida e rilascio del software

In questa fase si parla impropriamente della convalida del software anche se in realtà lo scopo di
questa fase è quello di verificare che il software sviluppato durante il progetto soddisfi sia i requisiti
iniziali richiesti dal cliente, in termini di funzionalità e prestazioni, sia i requisiti introdotti dall’analisi
dei rischi, in termini di efficacia del controllo dei rischi. In altri termini il software rilasciato nella
versione BETA deve risultare conforme ai requisiti software di progetto.

50
 51

È la fase di verifica chiamata “Black-box”, descritta in precedenza, e deve essere in grado di coprire
i seguenti aspetti di verifica:

 Delle funzionalità e prestazioni;

 Del comportamento del software nelle condizioni di errore;
 Dell’efficacia del controllo del rischio;
 Del grado di usabilità del software;
 Di installazione e condizioni limiti di funzionamento;

La verifica deve essere eseguita tramite un protocollo di prove redatto nella fase della definizione
dell’architettura. Deve essere svolta sul dispositivo finale tenendo conto di tutte le possibili varianti
del dispositivo stesso. Le prove devono essere svolte sia in condizioni normali di funzionamento che
in condizioni di funzionamento improprio, ma altresì probabile, del dispositivo. Il risultato della
verifica deve essere documentato in modo da validare la revisione emessa.
Qualora venisse scoperto un funzionamento anomalo, si dovrà procedere nei seguenti modi:

 Correggere l’anomalia e definire quali parti del software devono essere riverificate, tramite
Regression Testing. Non è sufficiente infatti verificare solo la correzione dell’anomalia ma
occorre verificare anche che la modifica non abbia generato un non corretto funzionamento in
altre parti del software. La profondità della verifica deve essere concordata e pianificata a
seconda della criticità della modifica stessa;
 Decidere di non procedere con la modifica verificando che tale azione non abbia nessuna
conseguenza sul controllo del rischio, ma documentando presenza ed effetto dell’anomalia;

Il risultato della procedura di “validazione” deve essere documentato, solo per le classi di sicurezza
del software B e C, e deve contenere le seguenti informazioni:

 Risultato della verifica;

 Versione del software provato;
 Configurazione hardware su cui è stata eseguita la validazione;
 Identificativo della persona che ha eseguito la validazione;

A questo punto, si passa alla fase di rilascio vero e proprio del software. Tuttavia prima del rilascio
del software in produzione, il fabbricante deve:

 Assicurarsi che la verifica del software sia stata completata ed i risultati valutati;

51
 52

 Valutare e documentare le anomalie residue conosciute (Classe B, C);

 Documentare le versioni rilasciate (Classe A, B, C);
 Documentare come il software rilasciato è stato creato, ovvero procedure e ambiente di sviluppo
(Classe B, C);
 Assicurarsi che attività e compiti siano completi (Classe B, C);
 Archiviare software e documentazione relativa (Classe B, C);
 Assicurare la recuperabilità dello stato del software in fase di rilascio in produzione senza il
verificarsi di corruzioni o anomalie (Classe B, C);

2.1.3.8 Software change control

Come già accennato ad inizio capitolo purtroppo molti incidenti presso il paziente sono causati dal
mantenimento del software che comporta spesso aggiornamenti o sostituzioni direttamente presso il
cliente. A tal proposito il fabbricante deve stabilire un piano di mantenimento del software,
contenente criteri e procedure di documentazione, valutazione, risoluzione, uso del processo di
gestione del rischio, uso del processo di risoluzione dei problemi software, uso del processo di
gestione della configurazione software, procedure di valutazione di aggiornamenti, debug,
obsolescenze, etc. (Classe A, B, C)
Per eseguire al meglio questi procedimenti, il fabbricante deve:

 Tenere conto dei feedback post-market interni ed esterni;

 Documentare e valutare i feedback post-market come problem report;
 Valutare i problem report che inficiano la sicurezza del dispositivo;

A seguito di queste valutazioni, il fabbricante dovrà:

 Analizzare la richiesta di modifica (Classe B, C);

 Valutare e approvare ogni richiesta di modifica;
 Informare gli utilizzatori, in merito alle conseguenze dell’utilizzo del software non modificato,
o su come ottenere ed installare le modifiche apportate (Classe A, B, C)

Il fabbricante, a questo punto, dovrà utilizzare il processo stabilito per implementare le modifiche e
rilasciare il software così modificato, secondo le procedure definite per il rilascio del software. [11]

52
 53

In definitiva, il ciclo di vita dello sviluppo del software può essere visto attraverso il seguente
V-model (figura 18):

Figura 18: rappresentazione del ciclo di vita del software tramite V-model

53
 54

Capitolo 3

3. Quadro regolatorio negli USA

Purtroppo, nel corso del normale funzionamento del dispositivo medico, ci possono essere delle
problematiche che a volte costringono i produttori ad effettuare i cosiddetti “recalls” (richiami).
Questi contribuiscono, in relazione alla funzione sicura e qualitativa dei dispositivi medici, ad evitare
incidenti che potrebbero causare lesioni e morte a pazienti ed utilizzatori.
Negli Stati uniti, sono stati analizzati dati provenienti dal database dei recalls FDA tra il 2009 e il
201; i risultati rivelano che in media più di un dispositivo medico su tre, che sfrutta un software per
le sue operazioni, è stato richiamato a seguito di “fallimento” del software stesso. All’interno del
range mostrato in Figura 19 si può notare come ci sia dapprima una crescita notevole del numero di
richiami dovuti al software e poi un assestamento ma sempre su valori elevati. Questo denota un
incremento della consapevolezza circa l’importanza del software nel quadro medicale. [20]

Total FDA SW recalls

900
491
480 497 478
800 500
490 500
475
700 486
488
600
RECALLS

500

400
324
283 294
300 258 244
221 222 224
180
200
107
100

0
2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
YEARS

Total Medical Devices SW Recalls Total Medical Devices Recalls

Figura 19: Richiami di dispositivi medici e medici software da parte dell’FDA nel periodo 2009-2018 [20]

In Figura 20 è possibile in particolare notare le varie tipologie di recalls attribuibili al SW. Si nota un
forte spostamento dei dati nei confronti dei recalls dovuti a SW Design che quindi risulta essere la

54
 55

parte più delicata in termini di importanza all’interno delle fasi di progettazione SW.

Different types of software's FDA Recalls

350 250
240
300 258
215
161
250 199 183 191

200 166
RECALLS

150
103
100 10 13
9 14
4
41 10 11
15
0 20 10 14
50 12
0 22 26 10 8 4
3
6
2
0 9
0 4
19 4 9
12 0
4
4 13 13 1
5 10 13
0 11
0 0 0 0
0
2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
ANNI
SW Design Change SW Manufacturing/ SW Deployment
SW Change Control SW Design (Manufacturing Process)
SW Use Environment SW Design

Figura 20: Differenti tipologie di recalls dell’FDA [20]

Infine in quest’ultimo grafico (Figura 21) è mostrato l’andamento dei recalls dovuti al SW in funzione
delle tre classi di rischio del SW, anche in questo caso vi è un forte spostamento verso la classe 2 che
a livello numerico rappresenta la maggior parte dei dispositivi medici e medici SW.

FDA's recalls according to risk classes

2000
1791
1800
1600
1400
1200
Recalls

1000
800
600
400
200 94 69 90 42 43 82 39
0 0 1 5 0 7 1 3 2 0
0
SW Design SW SW Change SW Design SW Design SW use
Change Manufacturing/ Control (Manufacturing Environment
SW Deployment Process)
Classi di rischio per Categoria

Classe 1 Classe 2 Classe 3

Figura 21: Recall dell’FDA in funzione della classe di rischio del dispositivo medico SW [20]

55
 56

A fronte di ciò, si evidenzia l’importanza e la necessità di un sistema che gestisca al meglio

l’immissione sul mercato di dispositivi medici software, in termini di validazione e verifica
dell’effettivo funzionamento del dispositivo. Sotto questo punto di vista solamente attraverso processi
efficaci, potremmo ridurre le dinamiche che portano al fallimento del dispositivo medico software.
Su questa linea, il quadro regolatorio di un dispositivo medico che possiede il software, secondo
l’FDA, consta di una serie di documenti guida. Questi includono considerazioni basilari come
l’analisi dei rischi, la precisa descrizione dei requisiti software, come tradurre questi requisiti nella
progettazione del software, test di verifica che mostrano che il dispositivo incontra tutti i requisiti,
test di validazione per dimostrare che il software incontra i bisogni dell’utente e gli utilizzi specifici
ed infine dimostrare una tracciabilità che mostra come tutti i requisiti siano stati incontrati nonché
tutte le diverse possibili attenuazioni del rischio per il software, e questo non è facile da fare.
Negli Stati Uniti il documento guida principale, per la validazione di un software medicale, è
denominato: “General Principles of Software Validation” [21]. Alla fase di verifica e validazione,
segue la vera e propria fase di immissione del dispositivo nel mercato statunitense, in cui
andranno considerate le specifiche procedure a seconda del rischio introdotto dal dispositivo medico
stesso, le procedure sono la 510(k) (Pre-market Notification) e la PMA (Pre-market Approval
Application). Al fine di eseguire al meglio questa fase l’FDA fornisce una specifica guida
denominata: “Guidance for the Content for Premarket Submissions for Software Contained in
Medical Devices” [12].

3.1 La linea guida di riferimento: “General Principles of Software

Validation”

Questa guida espone i principi che FDA considera essere essenziali ai fini della validazione del
software medicale. Questa guida viene applicata a software:

 Utilizzati come componenti, parti o accessori di un dispositivo medico;

 Che sono essi stessi considerati dispositivi medici (SaMD);
 Utilizzati nell’industria manifatturiera, ad esempio controllori a logica programmabile8, per
la produzione di un dispositivo;
 Utilizzati nell’implementazione dei sistemi di qualità dei fabbricanti di dispositivi;

8
I PLC (Programmable Logic Controller) sono dei controllori logici usati per automatizzare dei processi industriali, in questi controllori l’elaborazione è effettuata sulla
base di un algoritmo di controllo espresso tramite un programma. [22]

56
 57

Inoltre la guida fornisce utili informazioni e raccomandazioni ai seguenti individui che interagiscono
con il SaMD:

 Persone facenti parte del sistema di regolazione della qualità dei dispositivi medici;
 Persone responsabili della progettazione, sviluppo, o produzione del dispositivo medico
software;
 Persone responsabili della progettazione, sviluppo, produzione, o approvvigionamento di
strumenti automatizzati usati nella progettazione, sviluppo, o produzione dei dispositivi
medici o di strumenti software usati per implementare il sistema di qualità stesso;
 Investigatori FDA;
 Funzionari di conformità della FDA;
 Revisori scientifici della FDA

3.1.1 Scopo della linea guida e approccio utilizzato

Lo scopo della guida è un po’ più ampio rispetto allo scopo della validazione in senso stretto.
In questa guida infatti sono discusse attività come pianificazione, verifica, test, tracciabilità,
configurazione ed altri aspetti circa la buona progettazione ingegneristica del software e risultano
essere importanti attività che, tutte insieme, aiutano a supportare la validazione finale del software.
La prima cosa importante che tale guida mette in evidenza è il tipo di approccio che essa utilizza.
L’FDA infatti si basa su quello che considera essere l'approccio meno oneroso in tutte le aree della
regolamentazione dei dispositivi medici, tale approccio è denominato: “The Least Burdensome
Approach”, in parte già discusso nel primo capitolo. Questa guida riflette l’attenta revisione messa in
atto sui requisiti legali e scientifici rilevanti e su come sfruttare tale approccio per andare incontro a
questi requisiti.
Entriamo ora, però, nel dettaglio di cosa intenda l’FDA con i termini Verifica e Validazione del
software. Il sistema di regolazione della qualità è armonizzato con la normativa ISO 8402:19949, la
quale tratta la “verifica” e la “validazione” come termini distinti e separati. Dall’altro lato, molti
articoli e giornali vertenti sull’ingegneria del software usano i termini “Verifica” e “Validazione”
come se fossero interscambiabili, o in molti casi si riferiscono alla “Verifica, Validazione e Test” del
software come se questo fosse un singolo concetto, senza distinzione tra i tre termini, si parla infatti
di “VV&T”. In particolare, si ha:

9
È una normativa internazionale vigente dal 31 dicembre 1995 al 31 dicembre 2000, la quale stabiliva i termini e le definizioni fondamentali relativi alla qualità, ai sistemi
qualità ed agli strumenti e alle tecniche per tenerla sotto controllo. È stata rimpiazzata dalla normativa UNI EN ISO 9000. [23]

57
 58

 Verifica del Software: fornisce prove oggettive che gli output del progetto di una particolare
fase del ciclo di vita di sviluppo del software incontrano tutti i requisiti specifici per quella
fase. La verifica del software ricerca la consistenza, completezza, e correttezza del software e
della sua documentazione di supporto, come viene sviluppato, e fornisce supporto per la
successiva fase di validazione del software. Il test del software è una delle tante attività di
verifica, intesa a confermare che gli output di sviluppo del software incontrano i requisiti di
input. Altre attività di verifica includono svariate analisi statiche e dinamiche, ispezioni del
codice e di documenti, procedure dettagliate, ed altre tecniche;

 Validazione del Software: è una parte della validazione del dispositivo finito, ma non è
definita separatamente nel sistema di regolazione della qualità, bensì ne fa parte. L’FDA
considera la validazione del software essere: “la conferma tramite ispezione e fornitura di
evidenze oggettive che le specifiche software sono conformi ai bisogni dell’utente ed ai suoi
usi previsti, e che i particolari requisiti implementati attraverso il software possono essere
completamente soddisfatti”. La validazione software può aumentare l'utilizzabilità e
l'affidabilità del dispositivo, convergendo in una diminuzione dei fallimenti, ridotti richiami
e azioni correttive, minor rischio per il paziente e utenti, e ridotta responsabilità ai fabbricanti
di dispositivi. La validazione software può anche ridurre i costi a lungo termine, ed una
modifica del software meno costosa ed affidabile;

La verifica e validazione del software possono essere procedure delicate, in quanto uno sviluppatore
non può testare il software per sempre, ed è difficile sapere “quanta evidenza” è effettivamente
sufficiente. In larga misura, la validazione del software è un modo di sviluppare un “livello di
confidenza” in cui il dispositivo incontra tutti i requisiti e le aspettative dell’utente circa le funzionalità
del software. Misure come l’identificazione di difetti nella documentazione delle specifiche, la stima
dei difetti rimanenti, la copertura dei test, ed altre tecniche vengono utilizzate per sviluppare un livello
accettabile di confidenza prima che il prodotto sia venduto.
È ovvio che il livello di confidenza, e perciò il livello della validazione, verifica e test necessari del
software, varieranno dipendentemente dal rischio di sicurezza imposto dal funzionamento automatico
del dispositivo. Per molti anni, sia l’FDA che le industrie regolamentate hanno tentato di definire la
validazione del software all’interno della terminologia: processo di validazione.
Per esempio, altre guide dell’FDA a volte descrivono la validazione del software nel sito di utenza in
termini di qualifica di installazione (IQ), installazione, documentazione e controlli di sicurezza,

58
 59

qualifica operativa (OQ), completo controllo del sistema, test funzionali, calibrazione, funzionalità
SW e qualifica delle prestazioni (PQ), test applicativi, ri-calibrazione ed aggiustamento della
configurazione, continua manutenzione e contratti di servizio.
Sebbene, la terminologia IQ/PQ/OQ abbia servito al meglio i suoi scopi, ed è uno dei molti modi per
organizzare i compiti della validazione del software nel sito di utenza, tale terminologia non è stata
compresa al meglio tra gli svariati professionisti del software, e per questo non ci soffermiamo oltre.
Un ultimo decisivo step di cui si avvale l’intero processo di sviluppo del dispositivo medico software
è la revisione. Le revisioni della progettazione sono esami documentati, completi e sistematici del
progetto per valutarne l’adeguatezza, ovvero la capacità del progetto di incontrare quei requisiti,
nonché identificarne eventuali problemi.
La revisione del progetto è uno strumento fondamentale per la gestione e la valutazione dei progetti
di sviluppo. Durante le revisioni formali del progetto, le risposte ad alcune domande chiave
dovrebbero essere documentate, ed includono:

 Sono stati dimostrati i compiti, risultati attesi ed output per ogni attività del ciclo di vita del
software?
 I task, i risultati attesi o gli output di ciascuna attività del ciclo di vita del software:
o Soddisfano i requisiti delle altre attività del ciclo di vita del software in termini di
correttezza, completezza, consistenza ed accuratezza?
o Soddisfano gli standard, le pratiche, e le convenzioni di quella attività?
o Costituiscono una corretta base per l’inizializzazione dei compiti per la successiva
attività del ciclo di vita?

Queste sono solo alcune delle possibili domande che ci si pone in fase di revisione del software.

3.1.2 Lo sviluppo del software come parte della progettazione del

sistema

Lo sviluppo del software è una fase che va di pari passo con l’implementazione fisica del dispositivo
medico ed è tipica dello stadio di progettazione del sistema.
Ci sono bisogni dell'utente ed usi specifici per un dispositivo ultimato, ma gli utenti tipicamente non
specificano se quei requisiti sono riscontrati dall'hardware, software o da una combinazione di
entrambi. Perciò, la validazione del software deve essere considerata parte integrante del contesto
complessivo della validazione del progetto del sistema. Una descrizione documentata dei requisiti
rappresenta i bisogni dell’utente ed i relativi usi specifici da cui il dispositivo è prodotto.

59
 60

La correttezza e completezza di entrambi i requisiti di sistema ed i requisiti software dovrebbero

essere etichettati come parte del processo di progettazione del dispositivo.
Tuttavia è bene sottolineare come il software differisca dall’hardware, a causa di molti fattori, tra i
più importanti vi sono:

 La maggioranza dei problemi software sono riconducibili ad errori fatti durante il processo di
progetto e di sviluppo. Mentre la qualità del prodotto hardware dipende fortemente dal
progetto, sviluppo ma anche dalla fabbricazione, cosa che nel software c’è in minima parte;
 A differenza dell’hardware, il software non è un’entità fisica e non si consuma, in quanto
viene continuamente modificato ed aggiornato ed i suoi componenti non subiscono i danni
del tempo;
 Una caratteristica del software è data dalla velocità e facilità con la quale è possibile
aggiornarlo, a differenza dell’hardware in cui è necessario un tempo più lungo;

A causa della sua complessità, il processo di sviluppo del software dovrebbe essere ancora più
strettamente controllato rispetto a quello hardware, al fine di evitare problemi che non possono
essere facilmente riscontrabili in seguito nel processo di sviluppo. Per queste, ed altre ragioni,
l’ingegneria del software necessita di un livello ancor più grande di scrupolosità nella gestione e nel
controllo rispetto all’ingegneria hardware. [21]

3.1.3 Requisiti regolatori per la convalida del software

Come già visto nel capitolo precedente riguardo allo standard IEC 62304:2006+AMD1:2015 [11],
anche questa guida raccomanda un’integrazione sulla gestione del ciclo di vita del software, ed in
particolare, un’attività di quality management, in accordo con i current Good Manufacturing
Processes (cGMP’S) noti anche come FDA 21 CFR Part 82010 [24] [25]. Infatti la validazione del
software è un requisito del regolamento del sistema di qualità. In particolare, in accordo con la 21
CFR 820.30 [13] si ha che:

“A meno che non sia espressamente esentato in un regolamento di classificazione, qualsiasi

dispositivo medico software sviluppato dopo il 1 giugno 1997, indipendentemente dalla sua classe di
dispositivi, è soggetto alle disposizioni di controllo di progettazione applicabili”

10
Per garantire la sicurezza ed efficacia dei dispositivi medici, l’FDA regola i cosiddetti cGMP’s (current Good Manufacturing Processes) conosciuti anche come FDA 21
CFR Part 820, una serie di definizioni che consentono di regolare il sistema qualità dei dispositivi medici, in armonia con la ISO 13485:1996 basata sulla ISO 9001:1994
[24]

60
 61

I requisiti di validazione sono applicati ai software citati ad inizio capitolo. Ovviamente anche gli
altri controlli sul dispositivo quali pianificazione, input, verifica e revisione sono requisiti richiesti
dai cGMP’s. Sempre in accordo con i cGMP’s, in particolare la 21 CFR 820.70(i) [25] si ha che:
qualunque software utilizzato per progettare, automatizzare, testare, distribuire, etichettare, produrre
e confezionare qualsiasi parte del processo di produzione del dispositivo o qualunque parte del
sistema di qualità deve essere validato per i suoi specifici usi. In aggiunta a quanto sopra, i computer
sfruttati per creare, modificare e mantenere la documentazione elettronica e per gestire le firme
elettroniche sono anch’essi soggetti ai requisiti di validazione secondo la 21 CFR 11.10(a) [26], al
fine di essere validati in maniera da garantire l’accuratezza, consistenza ed affidabilità. [25]
Analogamente alla CEI EN 62304:2006 [11], anche questa guida non raccomanda uno specifico
modello di ciclo di vita o uno specifico metodo, bensì raccomanda che le attività di validazione e
verifica siano condotte durante tutto il ciclo di vita del software.
Una particolarità che alcuni di questi software sopra descritti possiedono è che spesso sono sviluppati
o dalla casa madre o tramite contratto, infatti, il software viene spesso acquistato Off-The-Shelf 11per
un particolare uso specifico, L'uso di questa tipologia di software nei dispositivi medici automatizzati,
nella produzione automatizzata e nelle operazioni di regolazione del sistema di qualità è in aumento.
Il software Off-The-Shelf può avere molte funzionalità, tuttavia solo alcune di queste sono necessarie
al fabbricante del dispositivo. I fabbricanti sono responsabili dell'adeguatezza del software utilizzato
nei loro dispositivi o utilizzato per produrre tali dispositivi. Quando i produttori di dispositivi medici
acquistano software Off-The-Shelf, devono assicurarsi che funzionino come previsto nell'applicazione
prescelta. L’importanza di quest’ultima considerazione è tale che l’FDA ha messo a disposizione dei
fabbricanti una guida che fornisce loro i dettagli necessari per assicurare tali disposizioni di sicurezza
sui loro dispositivi. Tale guida è denominata: “Guidance for Industry, FDA Reviewers, and
Compliance on Off-The-Shelf Software Use in Medical Devices” [27].

3.1.4 Principi di convalida del software

In questo paragrafo si introdurranno un po' più nel dettaglio i principi generali che dovrebbero essere
considerati per la convalida o validazione del software:

 Requisiti: una documentata specifica dei requisiti software fornisce una linea base sia per la
validazione che per la verifica del software. Per cui, il processo di validazione del software

11
Tale termine indica un software “pronto all’uso”. Tutti i software di sistema di produzione e/o di qualità, anche se acquistati in commercio, devono presentare requisiti
documentati che definiscono completamente l'uso specifico e le informazioni su quali risultati di test ed altre prove possono essere confrontati, per dimostrare che il
software è convalidato per la sua destinazione d'uso [21]

61
 62

non può essere completato senza una precisa specificazione dei requisiti software come
definito nella 21 CFR 820.30 [28];

 Prevenzione dei difetti: la garanzia della qualità del software urge focalizzarsi sul prevenire
l’introduzione di difetti all’interno del processo di sviluppo del software e non sul tentare di
“testare la qualità all’interno del codice software dopo essere stato scritto”. Il test del
software è in parte limitante nella sua abilità di far riaffiorare tutti i difetti latenti del codice
software, tuttavia risulta essere un’attività assolutamente necessaria, anche se in molti casi
non è sufficiente a stabilire che il software sia adatto per i suoi specifici compiti. Al fine di
ottenere tale sicurezza, gli sviluppatori software dovrebbero usare un mix di metodi e tecniche
per prevenire ed identificare gli errori del software che si presentano. Il “miglior mix” di
metodi dipende da molti fattori includendo ambiente di sviluppo, applicazione, dimensione
del progetto, linguaggio e rischio. Ovviamente questo processo richiede tempo e fatica; per
questa ragione la preparazione per la validazione del software dovrebbe cominciare in
anticipo, durante la pianificazione dello sviluppo e degli input di progettazione. La
conclusione finale che il software è stato validato dovrebbe basarsi sulle evidenze collezionate
dagli sforzi pianificati e condotti durante tutto il ciclo di vita del software;

 Ciclo di vita del software: la validazione del software prende posto all’interno dell’ambiente
di un ben preciso ciclo di vita. Il ciclo di vita del software contiene i task di ingegneria del
software e la documentazione necessaria a supportare lo sforzo di validazione del software.
In aggiunta, il ciclo di vita del software contiene task specifici di convalida e verifica che sono
appropriati per lo scopo specifico del software;

 Pianificazione: il processo di convalida del software è definito e controllato attraverso l’uso

di un piano. Il piano di validazione del software definisce “cosa” deve essere realizzato
durante il processo di validazione del software. I piani di validazione del software sono uno
strumento efficace del sistema di qualità, includendo aree come lo scopo, l’approccio, le
risorse, gli orari, le tipologie e le estensioni delle attività e dei task;

 Procedure: il processo di validazione del software, come avveniva anche nella normativa IEC
62304:2006+AMD1:2015 [11], viene anche qui eseguito attraverso l’uso di procedure. Queste
procedure stabiliscono “come” condurre il processo validazione del software. Le procedure

62
 63

dovrebbero identificare le azioni specifiche o la sequenza di azioni che devono essere prese
per completare singole attività di convalida e task;

 Validazione del software dopo una modifica: a causa della complessità del software, un
cambiamento apparentemente localizzato potrebbe avere un impatto significativo sull’intero
sistema. Quando un qualsiasi cambiamento, anche se piccolo, è fatto al software, è necessario
ristabilire lo stato di validazione del software. Ogni volta che il software viene modificato,
dovrebbe essere condotta un’analisi della validazione non tanto per la modifica in sé, ma
anche per determinare l’estensione e l’impatto di quella modifica sull’intero sistema
software. In base a questa analisi, lo sviluppatore software dovrebbe condurre un appropriato
test di regressione del software per mostrare che le immutate ma vulnerabili porzioni del
sistema non sono state accidentalmente colpite. I controlli sulla progettazione ed i test di
regressione appropriati forniscono la consapevolezza che il software è validato in seguito ad
una modifica dello stesso;

 Copertura della validazione ed indipendenza della revisione: la selezione delle attività di

validazione e task dovrebbe essere commisurata con la complessità di progettazione del
software ed il rischio associato con l’uso del software per i suoi specifici scopi. Per dispositivi
a basso rischio, possono essere condotte solamente le attività di validazione basilari, ma col
crescere del rischio dovrebbero essere aggiunte maggiori attività di validazione al fine di
coprire il rischio addizionale che si viene necessariamente a creare. Le attività di convalida
dovrebbero essere condotte usando il principio di "indipendenza della revisione" poiché
l'auto-validazione è estremamente difficile. Quando possibile perciò, una valutazione
indipendente è sempre la migliore, specialmente per le applicazioni a rischio più elevato.
Alcune aziende quindi sfruttano per le attività di validazione terze parti che le effettuino;

63
 64

3.1.3.4 Ciclo di vita del software

La validazione del software è compiuta attraverso una serie di attività e task che sono pianificati ed
eseguiti a vari stadi dello sviluppo del ciclo di vita del software. Questi task possono essere occorrenze
singole o possono essere iterate più volte, a seconda del modello di ciclo di vita utilizzato ed allo
scopo delle modifiche eseguite con il progredire del progetto software. In questo paragrafo ci andremo
ad occupare di quelle attività che costituiscono parte integrante del modello di ciclo di vita del
software, tali attività copriranno il software dalla sua nascita sino al suo ritiro. In Figura 22 sono
esposte le tipiche attività che fanno parte del ciclo di vita del software:

Pianificazione
della qualità

Definizione dei
Ritiro requisiti di
sistema

Specifiche
Manutenzione dettagliate dei
requisiti software

Specifiche di
Installazione progetto del
software

Programmazione
Test
del codice

Figura 22: Tipici task inclusi nello sviluppo del ciclo di sviluppo del software

Durante ognuna di queste attività dovrebbe essere condotta la verifica di ognuno dei task effettuati in
figura a supporto della validazione del software. Lo scopo del modello del ciclo di vita del software
ha il compito di organizzare queste attività di sviluppo in vari modi e di fornire un quadro per
monitorarne e controllarne il progetto.

Vediamo adesso queste attività un po' più nel dettaglio:

 Pianificazione della qualità: la pianificazione del progetto e dello sviluppo dovrebbe

culminare in un piano che identifichi i task necessari, le procedure per la risoluzione ed il
resoconto di anomalie, risorse e requisiti di gestione delle revisioni includendo anche quelle

64
 65

formali di progettazione. Dovrebbe essere identificato il modello di ciclo di vita del software
e le sue attività associate, così come quei task necessari per ogni attività del ciclo di vita del
software. Il piano dovrebbe includere:

 Gli specifici task per ciascuna attività de ciclo di vita;

 L’enumerazione di fattori di qualità significativi, come affidabilità, manutenibilità ed
usabilità;
 Metodi e procedure per ciascun task;
 Criteri di accettazione del task;
 Criteri per la definizione e documentazione degli output in maniera che siano conformi
ai requisiti di input;
 Input ed output per ciascun task;
 Ruoli, risorse e responsabilità per ciascun task;
 Rischi;
 Documentazione delle necessità dell’utente;

In particolare, i task tipici che stanno all’interno della pianificazione della qualità sono:

 Piano di gestione del rischio;

 Piano di gestione della configurazione;
 Piano di garanzia della qualità del software:
 Piano di validazione e verifica del software;
 Task di validazione e verifica, e criteri di accettazione;
 Programma per l’allocazione delle risorse;
 Requisiti di segnalazione;
 Requisiti di revisione formale del progetto;
 Procedure di segnalazione e risoluzione dei problemi;
 Altre attività di supporto;

 Requisiti: i requisiti di sviluppo includono l’identificazione, l’analisi, e la documentazione

dell’informazione circa il dispositivo ed il suo uso specifico. Aree di particolare importanza
includono l’allocazione delle funzioni del sistema hardware/software, condizioni operative,
caratteristiche dell’utente, potenziali rischi e task previsti. In aggiunta, i requisiti dovrebbero
dichiarare chiaramente gli usi specifici del software.
Non è possibile validare il software senza predeterminare e documentare i suoi requisiti.

65
 66

I requisiti software tipici specificano quanto segue:

 Tutti gli input del sistema software;

 Tutti gli output del sistema software;
 Tutte le funzioni che il sistema software eseguirà;
 Tutti i requisiti prestazionali che il software incontrerà;
 La definizione di tutte le interfacce utente esterne, così come qualunque interfaccia
interna software-sistema;
 Come gli utenti dovranno interagire col sistema;
 Cosa costituisce un errore e come tali errori dovrebbero essere gestiti;
 Tempi di risposta richiesti;
 Ambiente operativo destinato allo sviluppo del software;
 Tutti i range, limiti, default, e specifici valori che il software accetterà;
 Tutti i requisiti di sicurezza, specifiche, caratteristiche o funzioni che saranno
implementate nel software;

Più nello specifico, i task tipici che stanno all’interno dei requisiti sono:

 Analisi preliminare dei rischi;

 Analisi di tracciabilità
 Requisiti software per i requisiti di sistema, e viceversa;
 Requisiti software per l’analisi del rischio;
 Descrizione delle caratteristiche dell’utente;
 Elenco delle caratteristiche e limitazioni della memoria primaria e secondaria;
 Valutazione dei requisiti di sistema;
 Analisi dei requisiti per l’interfaccia utente del software;
 Generazione del piano di test del sistema;
 Generazione del piano di accettazione del test;
 Revisione o analisi delle ambiguità;

 Progettazione: nel processo di progettazione, gli specifici requisiti software vengono tradotti in
una rappresentazione logica e fisica del software, al fine di poter essere implementato.
La specifica di progetto del software è una descrizione di ciò che il software dovrebbe fare e come
dovrebbe farlo. Le specifiche complete di progettazione del software vincolano il programmatore

66
 67

a stare all’interno dei limiti concordati nei requisiti di progetto. La sicurezza e le problematiche
di usabilità del dispositivo dovrebbero essere considerate quando si sviluppano diagrammi di
flusso, diagrammi di stato, strumenti di prototipazione e test. Dovrebbero essere eseguiti anche le
analisi dei task e delle funzioni, le analisi dei rischi, i test dei prototipi e le revisioni nonché test
completi sull’usabilità.
In particolare, le specifiche di progetto del software dovrebbero includere:

 Le specifiche dei requisiti software, includendo criteri predeterminati per l’accettazione

del software;
 L’analisi dei rischi software;
 Procedure di sviluppo e linee guida per la programmazione;
 Documentazione di sistema, la quale descrive il contenuto del sistema in cui il
programma è destinato a funzionare, includendo la relazione tra hardware, software ed
ambiente fisico;
 Hardware da utilizzare;
 Parametri da misurare o da memorizzare;
 Strutture logiche (includendo controlli logici) e fasi di elaborazione logica (algoritmi);
 Strutture dati e diagrammi di flusso dei dati;
 Definizione delle variabili (di controllo e dati) e descrizione di dove sono usati;
 Errori, allarmi e messaggi di errore;
 Software di supporto (sistemi operativi, driver etc.);
 Collegamenti di comunicazione, quali collegamenti tra moduli interni del software,
collegamenti con i software di supporto, collegamenti con l’hardware e con l’utente;
 Misure di sicurezza;
 Qualunque vincolo addizionale non identificato negli elementi di cui sopra.

Da notare come i primi quattro elementi sopra riportati di solito sono documenti preesistenti e separati
che sono inclusi come riferimento nelle specifiche di progettazione del software precedenti.
Tipicamente le procedure di sviluppo scritte fungono da guida per l'organizzazione mentre le
procedure di programmazione scritte fungono da guida per i singoli programmatori.
In particolare i task tipici che stanno all’interno della progettazione sono:

 Analisi aggiornata dei rischi del software;

 Analisi di tracciabilità;
 Valutazione del progetto del software;

67
 68

 Analisi del progetto dei collegamenti di comunicazione;

 Generazione dei piani di test del modulo;
 Integrazione del piano di test;
 Generazione del test di progettazione (modulo, integrazione, sistema e accettazione).

 Costruzione e programmazione: il software dovrebbe essere costruito o attraverso la

programmazione o assemblando insieme componenti software precedentemente programmati, ad
esempio librerie, software Off-The-Shef ecc., per essere sfruttati all’interno di una nuova
applicazione. La programmazione è l’attività software dove la specifica di progetto dettagliata
è implementata come codice sorgente. La programmazione è quindi il livello più basso di
astrazione per il processo di sviluppo del software. Essa è l’ultima fase nella scomposizione dei
requisiti software dove le specifiche del modulo sono tradotte in un linguaggio di
programmazione. Generalmente questa fase coinvolge l’uso di un linguaggio di programmazione
ad alto livello, ad esempio linguaggi orientati agli oggetti quali C++, C# e JAVA per citare i più
importanti, ma potrebbe anche implicare l’utilizzo di linguaggio assembler per operazioni critiche
in termini di tempi. Il codice sorgente può essere compilato o interpretato al fine di poterlo
utilizzare su una piattaforma hardware di destinazione. Ovviamente decidere la scelta dei
linguaggi di programmazione, gli strumenti di costruzione del software, assemblatori e
compilatori, dovrebbe includere delle considerazioni circa l’impatto sulla qualità dei task
successivi, ad esempio debugging e test. Detto ciò, è importante eseguire quella che viene
chiamata analisi di tracciabilità del codice sorgente, il quale è uno strumento importante per
verificare che tutto il codice sia collegato alle specifiche e alle procedure di prova stabilite.
Questa analisi di tracciabilità del codice sorgente deve verificare che:

 Ogni elemento delle specifiche di progettazione del software è stato implementato nel
codice;
 I moduli e le funzioni implementate nel codice possono essere ricondotte ad un
elemento nelle specifiche software di progettazione e analisi del rischio;
 I test per i moduli e le funzioni nel codice sono ricondotti ad un elemento nella
progettazione del software e analisi del rischio;
 I test per moduli e funzioni possono essere tracciati al codice sorgente per gli stessi
moduli e funzioni;

I task tipici che stanno all’interno della programmazione sono:

 Analisi di tracciabilità:

68
 69

 Codice sorgente per la specificazione di progettazione;

 Test Case e il codice sorgente e per la specificazione di progettazione;
 Codice sorgente e valutazione del codice sorgente;
 Analisi dell’interfaccia del codice sorgente;
 Generazione dei test case e procedure di test (modulo, integrazione, sistema e
accettazione);

 Test del software: il test del software comporta l’esecuzione del software sotto condizioni note
con input definiti e risultati documentabili che possono essere confrontati con le aspettative
prestabilite. È un’attività avida di tempo, difficoltosa ed imperfetta, perciò è necessaria una
precisa programmazione anticipata in maniera tale da essere più efficiente. Si dovrebbero
identificare i programmi, gli ambienti, le risorse, personale, strumenti, le metodologie, input,
procedure, risultati attesi, la documentazione ed i criteri di segnalazione.
Un processo di testing del software dovrebbe basarsi su principi che effettuano l’ispezione del
prodotto software. Principi di test del software applicabili includono:

 L’esito atteso del test è predefinito;

 Un buon Test Case ha un’alta probabilità di esporsi ad errore;
 Un test di successo è un test che trova un errore;
 C’è indipendenza dalla programmazione;
 Vengono utilizzate sia l’esperienza applicativa, l’utente, che quella software,
programmazione;
 I tester utilizzano strumenti differenti dai programmatori;
 L’ispezione del caso ordinario è insufficiente;
 La documentazione del test permette il suo riuso ed un’indipendente conferma
dello stato “passato/fallito” di un risultato del test durante la successiva revisione;

Una volta che i compiti prerequisiti, ad esempio l’ispezione del codice, sono stati completati con
successo, il test del software può cominciare. Esso inizia con il test a livello della Software Unit
e si conclude con il test del Software System. Potrebbe esserci un distinto livello di integrazione
dei test. Un prodotto software deve essere contestato con casistiche di test basati sulla sua
struttura interna e con casistiche di test basati sulle sue specifiche esterne. Questi test dovrebbero
fornire un esame approfondito e rigoroso circa la conformità del prodotto software con le sue
definizioni e requisiti funzionali, prestazionali e di interfaccia.

69
 70

Test basati sul codice sono conosciuti col nome di test White-Box, già introdotti nel capitolo
precedente, e sono chiamati test strutturali. Essi identificano casistiche di test basati sulla
conoscenza ottenuta dal codice sorgente, specifica dettagliata di progetto ed altri documenti di
sviluppo. I test strutturali possono identificare la presenza di codice “morto” cioè che non
viene mai eseguito quando il programma è in esecuzione. I test strutturali vengono eseguiti
principalmente con test di livello unitario (modulo), ma possono essere estesi ad altri livelli di
test del software. Il livello del test strutturale può essere valutato sfruttando metriche che sono
progettate per mostrare quale percentuale della struttura software è stata valutata durante il test.
Le principali metriche di copertura strutturale sono:

 Copertura delle dichiarazioni: questo criterio richiede sufficienti casistiche di test

per ogni dichiarazione del programma per poter essere eseguito almeno una volta;
tuttavia, il suo conseguimento non fornisce sufficiente fiducia circa il
comportamento del prodotto software;
 Copertura decisionale (succursale): questo criterio richiede sufficienti casistiche di
test per ciascuna decisione del programma o ramo da eseguire in modo che ogni
possibile risultato si verifichi almeno una volta. È considerato essere un livello minimo
di copertura per la maggior parte dei prodotti software, e da solo è insufficiente per
applicazioni ad alta integrità;
 Copertura delle condizioni: questo criterio richiede sufficienti casistiche di test
per ogni condizione di decisione del programma di assumere tutti i possibili
risultati almeno una volta. Si differenzia dalla copertura decisionale solo quando
devono essere valutate più condizioni per raggiungere una decisione;
 Copertura multi-condizione: questo criterio richiede un numero sufficiente di
casistiche di test per esercitare tutto le possibili combinazioni di condizioni in una
decisione del programma;
 Copertura del ciclo: questo criterio richiede sufficienti casistiche di test per tutti
i cicli del programma eseguiti per zero, uno, due e molte iterazioni che coprono
l'inizializzazione, l’esecuzione tipica, le condizioni di terminazione o di limite;
 Copertura del percorso: questo criterio richiede sufficienti casistiche di test per
ogni percorso ammissibile, di base, etc., dall'inizio alla fine di un segmento
definito di programma, da eseguire almeno una volta. A causa dell'enorme
numero di possibili percorsi attraverso un programma software, la copertura del

70
 71

percorso è generalmente non raggiungibile. La quantità di copertura del percorso è

normalmente stabilita in base al rischio o criticità del software sotto test;
 Copertura del flusso di dati: questo criterio richiede un numero sufficiente di
casistiche di test per ogni possibile flusso di dati da essere eseguito almeno una
volta. Sono disponibili diverse strategie di test del flusso di dati.

I test basati su definizioni o su specifiche sono anche noti come test funzionali o test "Black-Box",
anche in questo caso introdotti nel capitolo precedente. Essi identificano test basati sulla definizione
di cosa il prodotto software è destinato a fare. Questi test mettono in discussione l’uso o la
funzionalità di un programma, e le interfacce interne ed esterne del programma stesso.
Vediamo come i seguenti tipi di test del software hanno un livello di sforzo crescente:

 Caso ordinario: è necessario testare il software con input usuali. Tuttavia

testare il software con gli input usuali non consente di testare a fondo quel prodotto
software. Di per sé quindi, il testing di casi ordinari non riesce a fornire una sufficiente
affidabilità del prodotto software;
 Uscita forzata: si vanno a scegliere gli ingressi al test per garantire che gli output
del software selezionati (o tutti) siano generati dal test;
 Robustezza: il test del software dovrebbe dimostrare che il prodotto software si
comporta correttamente quando gli vengono forniti, inaspettatamente, input non
validi. Alcuni di questi metodi sono il “Class Partitioning”, “Boundary Value
Analysis” ed “Error guessing”. Anche se importanti e necessarie, queste tecniche
non assicurano che tutte le più scabrose situazioni riscontrabili dal software vengano
riconosciute dal test;
 Combinazione di input: i metodi di test funzionali identificati enfatizzano
soprattutto input singoli o individuali di test. Tuttavia, la maggior parte dei
prodotti software lavora con più ingressi durante le normali condizioni operative.
Test approfonditi sui prodotti software dovrebbero considerare le combinazioni di
input che un'unità software o un sistema potrebbero incontrare durante il proprio
funzionamento. L’”Error guessing” potrebbe essere esteso per identificare
combinazioni di input, ma è una tecnica ad hoc. Il “Cause-Effect graphic” invece è
una tecnica di test funzionale del software che identifica sistematicamente le
combinazioni di input per un prodotto software da includere nei casi di test;

71
 72

Si è visto come i test funzionali e strutturali del software identifichino delle tecniche che forniscono
degli specifici input per il test. Una debolezza di queste tecniche è data dalla difficoltà nel collegare
criteri di perfezionamento dei test funzionali e strutturali all’affidabilità del prodotto software. Test
del software più avanzati come i test statistici, possono essere impiegati per fornire l’ulteriore
garanzia che un prodotto software è affidabile. I test statistici utilizzano dati di test generati
casualmente da una ben definita distribuzione in base ad un preciso profilo di lavoro, come ad
esempio uso specifico, uso rischioso o uso nefasto del prodotto software. Tuttavia è bene
sottolineare come i test funzionali e strutturali siano dei prerequisiti necessari per i test statistici
del prodotto software.
In particolare i tipici task di test sono:

 Pianificazione dei test;

 Identificazione dei Test Case;
 Identificazione dei Test Case più funzionali;
 Analisi di tracciabilità
 Test unitari per la progettazione dettagliata;
 Test d’integrazione per la progettazione ad alto livello
 Test del sistema per i requisiti software
 Esecuzione del test unitario;
 Esecuzione del test d’integrazione;
 Esecuzione del test Funzionale;
 Esecuzione del test di sistema;
 Esecuzione del test di accettazione;
 Valutazione dei risultati del test;
 Risoluzione/Valutazione dell’errore;
 Resoconto finale del test.

 Installazione: il test nel sito di utenza è una parte essenziale della validazione del software.
Il sistema di regolazione della qualità richiede procedure di installazione e di ispezione così come
di documentazione dell’ispezione e del test per dimostrare la corretta installazione, come riportato
dalla 21 CFR 820.17 [25]. La terminologia riguardante il test nel sito di utenza può essere confusa.
Termini come beta test, sito di validazione, test di accettazione dell’utente, verifica
dell’installazione e test d’installazione sono tutti termini utilizzati per descrivere il test nel sito di
utenza. Questi test dovrebbero avvenire sul sito di utenza in presenza di hardware e software

72
 73

effettivi, che faranno parte della configurazione del sistema installato. Alcune delle valutazioni
che sono state di fatto eseguite in precedenza dallo sviluppatore software, dovrebbero essere
ripetute nel sito di utenza. Queste possono includere test per la valutazione dell’elevato volume
di dati, test e messaggi di errore ed implementazione dei requisiti di sicurezza.
I task tipici di installazione svolti sul sito di utenza sono:

 Esecuzione dei test di accettazione;

 Valutazione dei risultati dei test
 Risoluzione/Valutazione dell’errore;
 Resoconto finale del test;

 Manutenzione: applicato al software, il termine manutenzione non ha lo stesso significato di

quello applicato all’hardware. La manutenzione operativa dell’hardware e del software è diversa,
a causa dei loro meccanismi di errore/fallimento differenti. La manutenzione hardware include
tipicamente azioni di manutenzione preventiva, sostituzione dei componenti e modifiche
correttive. La manutenzione software include manutenzione correttiva, perfettiva e adattiva ma
non include azioni di manutenzione preventiva o azioni di sostituzione di componenti, come si
può vedere dalla seguente tabella:

Tipologia di modifica Tipologia di manutenzione

Correzione di errori e falle nel software Manutenzioni correttive
Modifica al software per migliorarne le prestazioni,
manutenibilità o altri attributi del Software System Manutenzioni perfettive

Modifica al software per renderlo utilizzabile in un Manutenzioni adattive

ambiente modificato

Tabella 8: tipologie di manutenzioni software in funzione della modifica apportata.

Quando vengono fatte delle modifiche al Software System, o durante lo sviluppo iniziale o durante
il rilascio post-manutenzione, dovrebbero essere condotte analisi di regressione per dimostrare
che le porzioni del software non coinvolte nelle modifiche non erano inavvertitamente impattanti.

In aggiunta ai task di verifica e validazione, i quali sono parte del processo di sviluppo standard
del software, è necessario affrontare le seguenti attività di manutenzione aggiuntive:

73
 74

 Revisione del piano di validazione del software: per il software che è stato
precedentemente validato, il piano di validazione del software esistente dovrebbe
essere revisionato in modo tale da supportare la validazione del software revisionato;
 Valutazione delle anomalie: i produttori software mantengono frequentemente
documentazione, come rapporti sui problemi del software, che descrivono le
anomalie scoperte nel software e le specifiche azioni correttive prese al fine di
eliminare ogni anomalia. Troppo spesso, tuttavia, sono ripetuti errori a causa degli
sviluppatori che non prendono in considerazione lo step successivo, ovvero
quello di determinare la radice della causa dei problemi e non fanno le dovute
modifiche procedurali necessarie per evitare la ricorrenza del problema. Un’analisi
sulla radice della causa delle anomalie può identificare le specifiche carenze
qualitative nel sistema. Laddove vengono identificati trend che riportano la
ricorrenza di anomalie simili, devono essere implementate appropriate azioni
correttive e preventive nonché un’opportuna documentazione per evitare ulteriori
ricorrenze di problematiche qualitativamente similari;
 Identificazione del problema e tracciamento della risoluzione: qualsiasi
problema riscontrato durante la manutenzione del software dovrebbe essere
documentato e la risoluzione di ogni problema tracciata;
 Proposta di valutazione delle modifiche: tutte le modifiche proposte,
miglioramenti, o aggiunte dovrebbero essere valutate per determinare l’effetto che
ciascuna modifica potrebbe avere sul sistema;
 Iterazione dei task: per le modifiche del software approvate, dovrebbero essere
eseguiti tutti i task di verifica e validazione per garantire che le modifiche
pianificate sono state implementate correttamente;
 Aggiornamento della documentazione: la documentazione dovrebbe essere
revisionata attentamente per determinare quali documenti hanno subito un
impatto maggiore dalla modifica; [21]

74
 75

3.1.3.2 Il processo di gestione del rischio

La gestione del rischio, o più comunemente chiamata Risk Management, è una pratica ingegneristica
che si riferisce all’applicazione metodica delle norme, delle procedure e delle pratiche che hanno il
fine di identificare, analizzare, monitorare ed infine contenere il rischio dovuto ad un dispositivo
medico e medico software. La norma di riferimento per questo tipo di processo è la norma ISO
14971:2012 [13]. Essa fa parte di una serie di standard internazionali edita dall’ISO (International
Organization for Standardization), la più importante organizzazione a livello mondiale per la
definizione di norme tecniche. In particolare l’ISO 14971:2012 [13], definisce i principi e le pratiche
di gestione del rischio ed è richiamata da una serie di importanti standard sui dispositivi medici.
È importante quindi per prima cosa capire cosa si intenda per “rischio”.
Se con riferimento a un determinato guasto indichiamo con S(t) la sicurezza che il guasto non
avvenga in uno specifico tempo t, con d l’entità del danno ad esso associato e con k la probabilità
che il danno si verifichi in presenza di un guasto, per rischio intendiamo il seguente prodotto:

𝑟(𝑡) = [1 − 𝑆(𝑡)] ∙ 𝑘 ∙ 𝑑

Dove 𝑘 ∙ 𝑑 è il danno probabile. Il rischio è perciò la probabilità che sia raggiunto il limite potenziale
di danno di un determinato fattore nelle condizioni di impiego o di esposizione.
A parità di sicurezza il rischio assume valori molto diversi in relazione al danno probabile, ciò
significa che a un danno maggiore non necessariamente corrisponde un rischio maggiore. Per cui, il
piano di gestione del rischio rappresenta il documento più importante del processo di gestione del
rischio. Si tratta di un vero e proprio “piano d’azione”, ovvero dell’insieme di documenti che
chiariscono la programmazione e la descrizione di tutte le attività di gestione del rischio da
parte del costruttore. Il piano di gestione del rischio può essere sia un documento separato sia
integrato nell’altra documentazione prodotta dal costruttore. Ovviamente l’ulteriore documentazione
presentata dal costruttore rende il piano di gestione del rischio più completo ed accessibile.
Il piano, al fine di soddisfare i requisiti imposti dalla norma ISO CEI 14971:2012 [13], deve includere
almeno quanto segue:

1. Lo scopo delle attività predisposte di gestione del rischio: l’identificazione del dispositivo
medico o delle fasi del ciclo di vita per le quali è applicabile ciascun elemento del piano;
2. Assegnazione delle responsabilità ed identificazione delle autorità preposte: nel piano di
gestione del rischio è necessaria infatti l’identificazione del personale responsabile di
qualunque attività specifica all’interno del processo di gestione del rischio, quali il revisore,
l’esperto, lo specialista di verifica o il responsabile di comprovata autorevolezza;

75
 76

3. I requisiti per il riesame delle attività di gestione del rischio: indicano come e quando
debbano essere eseguiti i riesami da parte della direzione per un determinato requisito medico
di un dispositivo, essi potrebbero far parte di altri requisiti di riesame del sistema della qualità;
4. I criteri per l’accettabilità del rischio: sono scelti a discrezione dal costruttore per la
determinazione del rischio accettabile, inclusi quelli quando la probabilità del verificarsi del
danno non possa essere stimata. Questi criteri possono essere comuni per categorie simili di
dispositivi medici;
5. Le attività di verifica: deve essere specificato il modo in cui sono portate a termine le due
distinte attività di verifiche richieste dalla ISO 14971:2012 [13]. La prima misura di verifica
è richiesta al fine di accertarsi che la misura di controllo del rischio sia stata implementata
nella progettazione finale, la seconda invece è richiesta per accertarsi che la misura attuata
riduca effettivamente il rischio;
6. Le attività connesse alla raccolta ed al riesame delle informazioni pertinenti di
produzione e post-produzione: è compito del costruttore definire procedure generiche per
la raccolta di informazioni da diverse fonti quali ad esempio gli utilizzatori o da rapporti di
incidenti e informazioni di feedback da parte dei clienti. I metodi per ottenere informazioni
post-produzione pertinenti con il rischio relativo all’uso di un determinato dispositivo medico
possono essere parte di procedure definite del sistema di gestione della qualità;

Inoltre occorre considerare che qualora il piano cambiasse durante il ciclo di vita del dispositivo deve
essere conservata una annotazione delle modifiche nella documentazione di gestione del rischio. In
generale il livello di dettaglio del piano, secondo la norma, dovrebbe essere commisurato al livello di
rischio associato al dispositivo medico.
Ogni elemento del processo di gestione del rischio andrebbe mappato in base al ciclo di vita del
prodotto definito dal costruttore. Alcuni elementi del processo si attuano durante le fasi di
realizzazione del prodotto stabilite dal costruttore, come ad esempio il controllo della progettazione
e dello sviluppo, mentre gli ulteriori elementi si attuano durante le altre fasi di ciclo di vita del
prodotto fino alla sua dismissione. Infine, nonostante si debbano pianificare tutte le attività relative
alla gestione del rischio, il costruttore può redigere diversi piani che coprono le differenti parti del
ciclo di vita del dispositivo. Infine, il piano di gestione del rischio dovrebbe documentare le decisioni,
basate sull’analisi del rischio, su quale tipo di monitoraggio post-commercializzazione sia appropriato
per il dispositivo, per esempio, se sia adeguato il monitoraggio reattivo o se siano necessari studi
proattivi. [13]
La figura 23 mostra una rappresentazione schematizzata del processo di gestione del rischio che si
conclude con le informazioni di produzione e post-produzione appena descritte:

76
 77

Figura 23: schema del processo di gestione del rischio. [13]

77
 78

A conclusione del capitolo possiamo vedere l’intero processo di VV&T del software tramite uno
schema waterfall che racchiude i principali step necessari alla convalida del dispositivo medico
software (Figura 24):

Figura 24: schema waterfall sull’ applicazione degli step necessari al processo di controllo e
pianificazione del dispositivo medico software. [28]

78
 79

Capitolo 4

4.1 Il progetto Chromo4Vis

Il progetto Chromo4Vis o anche detto C4V mira a trattare efficacemente la distrofia corneale, detta
anche cheratocono, una malattia degenerativa della cornea. In particolare, il sistema deve garantire il
trattamento della distrofia corneale sfruttando una tecnica non invasiva basata sull’applicazione della
riboflavina catalizzata tramite l’emissione di luce UV-A, con densità superficiale di potenza
opportunamente controllata.

4.2 Il Cheratocono

Il cheratocono è una patologia degenerativa corneale bilaterale e progressiva, di natura non

infiammatoria, che colpisce, con una frequenza di 1 su 2000, popolazioni di entrambi i generi e di
qualunque etnia. La patologia si sviluppa nella pubertà e generalmente progredisce per le seguenti
due decadi, dopodiché si stabilizza causando una progressiva riduzione della vista già in giovane età
a causa dell’astigmatismo irregolare, della miopia indotta, e nei casi più avanzati, delle cicatrici
corneali. La patologia è caratterizzata da un progressivo indebolimento ed assottigliamento del tessuto
corneale che porta inevitabilmente alla distorsione ed allo sfiancamento (ectasia) dello stroma, che si
traduce in una cornea a forma di cono causando aberrazioni ottiche e distorsioni visive. In figura 25
è possibile vedere una sezione dell’occhio con i 5 strati della cornea (sx) e la differenza tra la curvatura
corneale normale e quella affetta da cheratocono (dx).

Figura 25: sezione trasversale dell'occhio umano in cui si evidenziano gli strati corneali e la
disposizione delle fibrille di collagene all’interno dello stroma [6]

79
 80

I Cheratociti sono le cellule principali dello stroma, essi giocano un ruolo importante nel preservare
la trasparenza e la stabilità meccanica della cornea. Sono responsabili della sintesi e del mantenimento
del componente collagene e della matrice extracellulare. Diversi studi riguardo la cornea
cheratoconica hanno rivelato cambiamenti nella morfologia dei cheratociti, diminuzione della densità
dei cheratociti, nonché un aumento dell’apoptosi. Le cause dell’assottigliamento corneale nel
cheratocono non sono ancora chiare. Takahashi et al. videro che il numero di lamelle nella cornea
cheratoconica era significativamente più basso rispetto alla cornea normale, ma lo spessore delle
lamelle risultava inalterato. Inoltre diversi studi non hanno mostrato differenze nella spaziatura tra le
fibre delle cornee cheratoconiche e quelle di controllo, dimostrando che lo spessore dello stroma
corneale nel cheratocono non è il risultato di uno stretto impacchettamento delle fibrille, bensì è
dovuto alla progressiva perdita di lamelle dallo stroma. È stato anche riportato che l’orientamento
delle fibrille di collagene all’interno delle lamelle risultava essere alterato nel cheratocono,
suggerendo che la perdita di integrità strutturale potrebbe giocare un ruolo importante nella
patogenesi della malattia.
In Figura 26, ottenuta tramite microscopio SHG12, è possibile vedere la disposizione delle fibre di
collagene all’interno di una cornea sana e di una che presenta il cheratocono. La cornea normale, è
caratterizzata da numerose fibre sottili nello stroma ed uno strato di Bowman intatto, mentre la cornea
cheratoconica possiede regioni con un ridotto ammontare di lamelle di collagene (*) e regioni
interrotte nello strato di Bowman (Freccia). [15]

Figura 26: immagine da microscopio SHG che mostra le fibre di collagene in una cornea normale
(sinistra) ed in una cornea cheratoconica (destra) [15]

L’ezio-patologia del cheratocono è di tipo multifattoriale, infatti una predisposizione genetica è ben
documentata, con una incidenza che si attesta tra il 6% ed il 23% dei casi.[1][2]
Oltre l’eterogeneità genetica del cheratocono, oggi si enfatizza anche l’importanza di vari fattori
ambientali e non (UV, atopia, usura delle lenti a contatto, sfregamento cronico dell’occhio, carenza
di magnesio) nella patogenesi della malattia, che siano in grado di scatenare o accelerare la

12
SHG (Second-Harmonic generation) è un processo ottico non lineare in cui due fotoni con la stessa frequenza interagiscono con un materiale non
lineare, sono "combinati" e generano un nuovo fotone con il doppio dell'energia dei fotoni iniziali (equivalentemente, il doppio della frequenza e metà
della lunghezza d'onda). È un caso speciale di generazione di somma-frequenza. Il microscopio SHG è stato stabilito essere un meccanismo di
contrasto vitale per l'imaging della struttura e della funzione cellulare e tissutale.

80
 81

progressione della degenerazione corneale.

La pachimetria corneale (Figura 27) e la topografia corneale (Figura 28), sono gli strumenti
principali per la diagnosi di cheratocono, soprattutto nei casi precoci o non sintomatici, laddove la
cornea si mostra priva di segni obiettivi tipici della patologia. La topografia e la pachimetria corneale
sono anche esami strumentali indispensabili nel follow-up del paziente, al fine di evidenziare la
progressione della malattia. [4]
La pachimetria corneale, è la valutazione dello spessore corneale; si misura in µm e mediamente i
valori normali sono compresi tra i 520-540 µm. La topografia corneale, invece, indica attraverso una
scala colorimetrica, la curvatura corneale. In particolare le aree in blu indicano una curvatura più
grossa mentre le aree rosse indicano una curvatura più ripida, tale area rappresenta infatti il cono che
protrude, tipico della patologia.

Figura 27: pachimetria corneale Figura 28: topografia corneale

Ad oggi l’esatta causa scatenante del cheratocono è ancora incerta, anche se si suppone che sia
associata ad una anormale attività degli enzimi all’interno della cornea. [2]

4.2.1 Tecniche classiche per il trattamento del cheratocono

Le tecniche classiche per il trattamento refrattivo del cheratocono si avvalgono dell’uso di occhiali
e/o lenti a contatto. Gli occhiali possono garantire una sufficiente correzione durante i primi stadi di
cheratocono. Tuttavia, per gli stadi successivi, quando la cornea si modifica assumendo una forma
anormale, l’astigmatismo irregolare non può più essere corretto e diventano necessarie le lenti a
contatto. Le lenti a contatto, possono infatti adattarsi alla forma anormale dell’occhio fornendo una
nuova normale superficie rifrangente, correggendo effettivamente l’astigmatismo irregolare.
L’uso di lenti a contatto è uno dei più semplici modi di correggere leggeri cheratoconi e rappresenta
circa il 90% dei trattamenti. La tipologia di lenti a contatto dipende dalla severità della malattia, negli

81
 82

stadi precoci ad esempio, sono più adeguate lenti morbide. Verso stadi più avanzati della patologia,
quando la stabilità biomeccanica della cornea diminuisce drasticamente, l’utilizzo di lenti rigide
possono essere più adeguate e fornire un miglior supporto biomeccanico. Lenti ibride sono
un’opzione popolare, esse risultano essere rigide nel mezzo e più morbide sui bordi, conferendo
perciò il comfort delle lenti più morbide. Riguardo gli svantaggi delle lenti a contatto nel trattamento
del cheratocono, vi sono diverse complicazioni associate. Lo svantaggio principale riguarda il fatto
che la cornea può cambiare forma nel tempo, limitando la durata in cui le lenti mantengono una buona
visione. Altre complicazioni includono inadeguata lubrificazione e abrasioni corneali, i quali possono
causare visione distorta e fastidi. Alcune di queste complicazioni possono essere ridotte
dipendentemente dal design della lente a contatto stessa. [6]
Il trattamento chirurgico del cheratocono, invece, include il cross-linking corneale e, nei casi più
avanzati, il trapianto di cornea, sia esso lamellare profondo o a tutto spessore.

4.2.2 Tecniche innovative: il cross-linking corneale

A causa della giovane età di insorgenza, il cheratocono ha un impatto negativo notevole sulla qualità
della vita delle persone che ne sono affette. Nonostante l’uso continuo di lenti a contatto consenta alla
maggior parte dei pazienti un’adeguata qualità visiva, tuttavia non ha nessuna capacità di rallentare
la progressione della malattia. Numerosi studi clinici hanno dimostrato una differente rigidità e
viscoelasticità tra la cornea normale e quella affetta da cheratocono, la quale risulta incapace di
resistere al normale carico applicato dalla pressione intraoculare, tendendo a sfiancarsi. [6]
Recentemente, è stato sviluppato un nuovo metodo per il trattamento del cheratocono progressivo: il
cross-linking del collagene corneale, il quale aumenta la rigidezza della cornea sfruttando i raggi
UV-A e la riboflavina fotosensibilizzante.
In particolare, il cross-linking corneale ha come scopo l'incremento della forza meccanica del tessuto
corneale mediante la generazione di nuovi legami chimici tra le proteine dello stroma, secondo un
processo chimico denominato foto-polimerizzazione. La formazione di nuovi e ulteriori legami
crociati covalenti tra le proteine dello stroma corneale, stabilizza la struttura e le proprietà meccaniche
del tessuto [7]. Numerosi studi, affermano che il cross-linking del collagene possa ritardare o fermare
la progressione del cheratocono, migliorando la forma della cornea e producendo una miglior qualità
della visione [6].
L’intervento di cross-linking corneale consiste nell’instillare gocce di riboflavina (vitamina B2) sulla
cornea e nell’irradiare il tessuto imbibito della molecola terapeutica con luce ultravioletta (UV-A).

82
 83

La riboflavina intra-corneale, che assorbe la radiazione UV-A, innesca una serie di reazioni
fotochimiche che generano specie reattive di ossigeno, le quali a loro volta inducono la formazione
di legami chimici covalenti tra le proteine stromali. L'intervento di cross-linking corneale viene
eseguito in regime ambulatoriale in anestesia topica (tramite gocce di collirio). Dopo l’intervento, al
paziente è prescritta una terapia medica topica con colliri antibiotici, anti-infiammatori e lubrificanti,
per alcune settimane o mesi.
Il cross-linking corneale è eseguito sin dall’anno 2003, dapprima negli stati Europei quindi nei Paesi
ad economia emergente, ed infine negli Stati Uniti (2016); ogni anno sono eseguiti decine di migliaia
di trattamenti. Il cross-linking corneale non pregiudica l’uso della lente a contatto, che può essere re-
indossata dopo un adeguato periodo di tempo dall’intervento. Almeno la metà dei pazienti riferisce
un netto miglioramento della qualità della propria vita dopo il trattamento di cross-linking corneale.
Il cross-linking corneale è una valida terapia per arrestare la progressione del cheratocono e ridurre
drasticamente la necessità di sottoporre a cheratoplastica molti giovani pazienti.

4.2.3 Evidenze sperimentali sull’efficacia del cross-linking corneale

I risultati di laboratorio concordano nel presentare il cross-linking corneale con riboflavina e UV-A,
come una tecnica chirurgica in grado di migliorare le proprietà biomeccaniche del tessuto corneale
umano, ed incrementare la sua rigidità meccanica. Kamaev et al. hanno dimostrato che il meccanismo
principale del trattamento di cross-linking corneale consista nell'interazione diretta tra le triplette di
riboflavina ed i gruppi reattivi delle proteine stromali, che porta alla generazione di nuovi legami
chimici covalenti tra le proteine stromali attraverso reazioni radicaliche [11].

Lombardo et al., hanno dimostrato in diversi studi, il cui scopo è stato quello di analizzare il
comportamento biomeccanico della cornea umana a differenti scale di osservazione (da quella
molecolare a quella tissutale), come il cross-linking corneale con riboflavina/UV-A induca sia un
irrigidimento dello stroma corneale (misurato come incremento del modulo elastico di Young) che
una significativa riduzione delle proprietà viscoelastica (misurato come riduzione dell’isteresi),
confermando come la formazione di legami covalenti avvenga tra le proteine del collagene e le
proteine della matrice stromale [13][14]. Traslando i risultati sperimentali alla clinica, la formazione
di nuovi legami chimici covalenti tra le proteine dello stroma corneale, contribuisce all’effetto di
stabilizzazione della progressione del cheratocono a causa della maggior resistenza del tessuto alle
normali pressioni esercitate su di esso (per es. pressione intraoculare); verosimilmente vi sono altri
meccanismi biologici che contribuiscono a migliorare l’efficacia del trattamento nel lungo termine,

83
 84

quali ad esempio la produzione di proteine collagene e di componenti della matrice stromale più
regolari da parte dei cheratociti stromali, rigenerati dopo il trattamento [15].

4.2.4 Protocolli di trattamento del cross-linking corneale

Il protocollo standard di cross-linking corneale, o protocollo di Dresda, consiste nella rimozione

dell’epitelio e nella somministrazione di una soluzione di riboflavina, in genere arricchita di destrano
al 20% o altra sostanza viscoelastica, sullo stroma corneale per 30 minuti; l’irradiazione UV-A della
cornea consiste nell’illuminare la cornea con una densità di potenza pari a 3 mW/cm2 per 30 minuti,
rilasciando un’energia totale di 5.4 J/cm2.

In base alla letteratura scientifica, il protocollo standard di cross-linking è efficace, dove l’efficacia
è indicata come stabilizzazione o appiattimento della curvatura corneale massima, mediamente nel
70% dei casi trattati, con un tasso di insuccesso, ovvero necessità di trapianto di cornea, variabile
dall’8% al 33% ad un anno dall’intervento.

Tuttavia, il protocollo di cross-linking corneale standard, richiede la rimozione dell’epitelio, che è

un fattore predisponente ad una serie di complicanze maggiori, come le cheratiti infettive e la
formazione di cicatrici corneali più o meno dense (incidenza fino al 12% dei trattamenti), che
inducono una riduzione permanente della vista. In alcuni casi, la gestione di queste complicanze può
richiedere il trapianto di cornea. Inoltre, la durata dell’intervento standard è superiore ad un’ora, il
che lo rende poco tollerato dalla maggior parte dei pazienti.

Negli ultimi anni, perciò, un numero sempre crescente di chirurghi ha optato per protocolli che
consentono un risparmio di tempo, come ad esempio l’impiego di densità di potenza maggiori a 10
mW/cm2 per 9 minuti o 9 mW/cm2 per 10 minuti, i quali rilasciano comunque un’energia totale di
5.4 J/cm2 al tessuto corneale. In ogni caso, gli svantaggi della tecnica rimangono gli stessi ed il limite
è quello di non poter intervenire su cornee con spessore inferiore a 400 µm a causa del rischio di
danneggiare l’endotelio corneale.

Per ovviare ai limiti ed alle complicanze del protocollo standard, sono stati sviluppati e sono tuttora
in via di sviluppo nuovi protocolli, che evitano la rimozione dell’epitelio e che, per tale motivo, sono
stati denominati protocolli di cross-linking corneale transepiteliale. Tuttavia, gli studi clinici di
confronto tra il protocollo standard ed il primo protocollo transepiteliale, che faceva uso di soluzioni
di riboflavina arricchite di destrano al 15%, hanno dimostrato una sua minore efficacia nell’arrestare
la progressione del cheratocono rispetto al protocollo standard. Il tasso di insuccesso di questo primo

84
 85

protocollo transepiteliale, oggi in disuso, raggiungeva il 70% ad 1 anno dal trattamento. La causa
dell’insuccesso è stata riferita alla ridotta penetrazione della riboflavina, in soluzione con destrano,
nel tessuto corneale attraverso l’epitelio integro.

Negli ultimi anni, sono stati sviluppati nuovi protocolli di cross-linking transepiteliale, tra cui quello
assistito dalla iontoforesi corneale chiamato per l’appunto cross-linking transepiteliale con
iontoforesi. Esso dimostra, a 2 anni dal trattamento, di essere efficace nel 90% dei casi trattati senza
alcuna induzione di complicanze severe, seppure il numero di trattamenti sia ancora decisamente
inferiore a quello dei protocolli standard.

4.2.5 Studi clinici sull’efficacia del cross-linking corneale

In uno studio clinico randomizzato, Lombardo et al. hanno analizzato 35 occhi di 25 pazienti, in
particolare sono stati trattati con Cross-Linking Transepiteliale con Iontoforesi (CLT-ionto) 22
pazienti e 22 occhi mentre tramite Cross-Linking classico (CL) su 10 pazienti e 12 occhi.
I dati sulla popolazione ed i valori dei loro parametri funzionali, prima del trattamento sono mostrati
nella Tabella 9:

T-ionto CL Standard CL 𝑃 value

Age (years) 31.0 ± 6.6 29.4 ± 5.6 𝑃 = 0.55

Male/female gender (%) 18/3 (86%) 8/4 (67%)

𝐾(D) max 54.74 ± 4.01 54.76 ± 4.30 𝑃 = 0.87

BSCVA (logMAR) 0.12 ± 0.20 0.06 ± 0.10 𝑃 = 0.29

Central corneal thickness
484 ± 37 494 ± 34 𝑃 = 0.44
point on AS-OCT (𝜇m)
Spherical equivalent
−2.64 ± 2.41 −1.75 ± 2.12 𝑃 = 0.29
refraction (D)
Endothelial cell density
2635 ± 387 2625 ± 281 𝑃 = 0.93
(cells/mm2)

Tabella 9: caratteristiche demografiche e cliniche di gruppi di occhi trattati tramite (CL T-Ionto) e di
controllo (CL)

Rispetto alla baseline dei pazienti trattati mostrata nella tabella precedente, è stato dimostrato un
appiattimento medio del valore cheratometrico Massimo (Kmax) di -0.52±1.30 D e -0.82±1.20 D
rispettivamente a 1 anno dal trattamento transepiteliale con iontoforesi in 22 occhi e con protocollo
di Dresda in 12 occhi. L’acuità visiva corretta (CDVA) è migliorata in media di -0.10±0.12 logMAR
e -0.03±0.06 logMAR rispettivamente e la refrazione manifesta è migliorata in media di +0.71±1.44
D e +0.21±0.76 D rispettivamente. [27]

85
 86

In un altro studio clinico Vinciguerra et al. hanno dimostrato un appiattimento medio dell’indice Kmax
di -0.31±1.87 D e di -1.05±1.51 D rispettivamente ad 1 anno dal trattamento transepiteliale con
iontoforesi in 20 occhi e con protocollo di Dresda in 20 occhi. Sono stati trovati miglioramenti
significativi nell’acuità visiva corretta (CDVA) e nella refrazione manifesta (CTTP) 12 mesi dopo il
cross-linking con iontoforesi. I parametri raggiunti hanno suggerito che il trattamento transepiteliale
con iontoforesi possa essere comparato a quello standard nello stabilizzare la progressione della
patologia degenerativa. In aggiunta, un rapido miglioramento dei parametri funzionali è stato
riscontrato nel gruppo trattato con il cross-linking transepiteliale con iontoforesi. [26]

In un altro studio clinico retrospettivo, Cantemir et al., hanno comparato i risultati di pazienti trattati
con cross-linking epiteliale con iontoforesi e trattati col protocollo di Dresda, a 3 anni dall’intervento.
I risultati, per quanto riguarda l’acuità visiva, sono mostrati nelle Figure 29 e 30:

Figura 29: acuità visiva media non corretta nel Figura 30: acuità visiva media corretta nel
gruppo trattato con iontoforesi (verde) ed in quello gruppo trattato con iontoforesi (verde) ed in
trattato col protocollo standard (rosso) quello trattato col protocollo standard (rosso)

L’acuità visiva non corretta (UDVA) (Figura 29) cominciò a migliorare rapidamente nel gruppo
trattato con iontoforesi già dal terzo mese post-operatorio, ed è diventata significativamente più alta
nei primi 24 mesi di follow-up (p=0.022). A 36 mesi di follow-up, il valor medio di acuità visiva non
corretta è aumentato di 1.7 nella tabella di Snellen, nel gruppo trattato con iontoforesi, rispetto a 1.1

86
 87

nella tabella di Snellen, nel gruppo trattato col protocollo standard. A questo punto la differenza tra i
due gruppi non risultava più essere significativa dal punto di vista statistico (p=0.064).

L’acuità visiva corretta (CDVA) (Figura 30) si sviluppò in maniera differente all’interno dei due
gruppi trattati. Essa rimase stabile nei primi 3 mesi di follow-up con una crescita statisticamente
significativa a partire dal 6° mese di follow-up (p=0.037) nel gruppo trattato con Iontoforesi. Dopo
un declino iniziale, un mese dopo l’operazione, l’acuità visiva cominciò a migliorare a partire dal 6°
mese di follow-up nel gruppo trattato col protocollo di Dresda (p=0.038). L’acuità visiva corretta
continuò a migliorare durante tutti i restanti follow-up in entrambi i gruppi. Il trend dell’acuità visiva
corretta, valutato dal modello lineare generale, era significativamente più alto nel gruppo trattato col
protocollo di Dresda a 36 mesi di follow-up (p=0.001).

Per quanto riguarda i valori di cheratometria e pachimetria, essi sono mostrati nelle Figure 31 e 32:

Figura 31: Kmax (Maximum Keratometry Values) Figura 32: CTTP (Corneal Thickness at the
nel gruppo trattato con Iontoforesi e nel gruppo Thinnest Point) nel gruppo trattato con Iontoforesi
trattato con protocollo di Dresda. D = diottrie e nel gruppo trattato con protocollo di Dresda.

Dallo studio cheratometrico (Figura 31) è emersa una diminuzione del Kmax in entrambi i gruppi
trattati. L’appiattimento della cornea è continuato durante tutto il follow-up, senza alcuna differenza
statisticamente significativa tra i due gruppi, ad ogni step del follow-up. A 36 mesi dall’operazione,
il valore del Kmax si attestò a 1.2 D per il gruppo trattato col protocollo di Dresda e 0.9 per il gruppo
trattato col iontoforesi, senza alcuna differenza significativa (p=0.283).

87
 88

Per quanto riguarda la pachimetria (Figura 32) entrambi i gruppi hanno mostrato una significativa
riduzione del CTTP a 3 mesi dall’intervento, successivamente i valori pachimetrici ritornarono a
livelli preoperatori a 12 mesi dall’intervento, mentre un incremento statisticamente significativo si
evinse nel gruppo trattato col protocollo di Dresda (p=0.012) e nel gruppo trattato con iontoforesi
(p=0.02). [29]

In ultimo, Zhang et al., hanno eseguito una meta-analisi che sintetizza e confronta i risultati clinici di
sei studi controllati randomizzati pubblicati sull’archivio ClinicalTrials.gov. Dall’analisi degli studi,
sono stati inclusi 183 occhi nel gruppo di partecipanti trattati con protocolli di cross-linking corneale
transepiteliale e 161 occhi inclusi nel gruppo di partecipanti trattati con cross-linking standard
(protocolli di Dresda); la durata dei follow-up variava da 6 a 24 mesi, l'età media dei partecipanti
variava da 22.3 a 31.0 anni. La procedura di cross-linking transepiteliale era differente nei 6 studi, in
due dei quali includeva la iontoforesi come metodo di somministrazione della riboflavina e tra gli
studi l'irradiazione variava da 3 a 10 mW/cm2. Gli autori della meta-analisi non hanno riscontrato
differenze clinicamente significative né differenze significative nelle variazioni medie dell’indice
topografico di cheratometria simulata dell’apice del cono (Kmax) tra i gruppi trattati con cross-linking
standard e transepiteliale, sebbene siano state riscontrate differenze significative nei valori della
cheratometria media e nei valori di spessore della cornea centrale tra i gruppi. [33]

Per quanto riguarda la sicurezza, nella maggior parte dei casi, le complicanze (incidenza media 12%)
dopo il trattamento di cross-linking sono lievi e transitorie. La rimozione dell’epitelio è il fattore
predisponente alle più frequenti e principali complicanze nel protocollo standard, come ad esempio
la cheratite infettiva, la formazione di infiltrati corneali sterili e la formazione di opacità corneali.
Un ulteriore fattore di rischio nel protocollo standard è rappresentato dal trattamento di cornee con
spessore inferiore a 400 μm, a causa del rischio di indurre un danno foto-tossico alle strutture
endoteliali [40]. Non rimuovere l’epitelio corneale, riduce drasticamente la frequenza e l’intensità di
complicanze, a qualsiasi età e per qualsiasi stadio di cheratocono. Favorire una maggiore penetrazione
della riboflavina, ed una maggiore concentrazione stromale della molecola terapeutica nei protocolli
transepiteliali, consentirebbe quindi di aumentare ulteriormente la sicurezza del trattamento di cross-
linking, mantenendone l’efficacia clinica.
Concludendo, gli studi hanno dimostrato come entrambe le tecniche siano in grado di arrestare la
progressione del cheratocono ai suoi primi stadi, senza mostrare grosse differenze significative nei
principali parametri funzionali (Kmax, CTTTP, UDVA, CDVA) e nemmeno variando la procedura di
trattamento in termini di durata e potenza utilizzata. Entrambe le tecniche sono state in grado di
conferire un buon grado di sicurezza al paziente ed una rapida guarigione.

88
 89

4.3 Progettazione fisica del dispositivo C4V

Il dispositivo C4V (Chromo4Vis), come già introdotto ad inizio capitolo, fornisce una metodologia
non invasiva per arrestare la progressione del cheratocono, tramite una terapia guidata dalla
diagnostica per immagini (teranostica)13.

Il sistema nel suo complesso viene per semplicità suddiviso, in quattro aree tematiche:

1. Meccanica
2. Ottica
3. Elettronica
4. Software

Da un punto di vista costruttivo il sistema, per semplicità, è suddiviso in cinque sotto-assiemi

principali:

1. Una testa ottica

2. Un carrello di movimentazione
3. Un braccio snodato di allineamento
4. Un sistema di controllo ed architettura elettronica
5. Uno schermo touch-screen esterno (con eventuale tastiera e mouse)

Tutti i sotto-assiemi elencati in precedenza, sono mostrati in una rappresentazione schematica del
dispositivo in Figura 33:

Figura 33: Rappresentazione schematica dei 5 sotto-assiemi del

dispositivo C4V

13
Il dispositivo nasce da un’idea sviluppata all’interno dell’azienda Vision Engineering Italy

89
 90

A livello progettuale, è molto importante anche andare a capire come avverrà l’intervento vero e
proprio, in questo caso ambulatoriale, effettuato dal medico chirurgo. La rappresentazione schematica
precedente, è stata utilizzata per andare a simulare lo scenario operatorio. In Figura 34, infatti, è
possibile vedere, da diverse angolazioni, il rendering della simulazione:

Figura 34: rendering dello scenario operatorio: lateral view (9 B), Top view (9 A), ISO View (9 C, 9 D)

Come si evince dalla Figura 34, il dispositivo C4V verrà posizionato affianco al lettino del paziente.
Il medico chirurgo oculista, potrà in questo modo, impugnare la testa ottica che, tramite il braccio
snodabile, conferirà una certa mobilità è consentirà al medico di direzionare al meglio il fascio UV-
A nella cornea del paziente, sottoposto ad intervento di cross-linking.

90
 91

4.3.1 Progettazione Testa Ottica

La testa ottica è il componente principale di C4V, dato che rappresenta l’elemento che finalizza
l’applicazione della radiazione UV-A sulla superficie corneale del paziente.
Vediamo, più nel dettaglio, il funzionamento della testa ottica. In figura 35 è mostrato il rendering
della testa Ottica, realizzato tramite software CAD Creo®:

Figura 25: rendering della testa ottica e dei suoi componenti interni

Il fascio UV-A viene indirizzato nella prima ottica, la quale presenta una lente necessaria a collimare
il fascio. Il fascio collimato, a questo punto, attraversa l’Iride ovvero un componente che è in grado
di eliminare la parte spuria del raggio UV-A ed inoltre ridurre la parte di fascio collimata che non
risulta essere perfettamente a fuoco. Il fascio UV-A, a questo punto, va incontro ad un ulteriore
collimazione attraverso una seconda ottica, questa in particolare ha il compito di focalizzare il fascio
sullo specchio.

Lo specchio, a sua volta, riflette il fascio UV-A e lo indirizza verso un filtro interferenziale o filtro
dicroico. Questo, avendo banda passante di 410nm, riflette il fascio UV-A, indirizzandolo verso la
cornea del paziente. Il fascio UV-A verrà assorbito dalla riboflavina intra-corneale, questa a sua volta

91
 92

emetterà un segnale nella banda del verde (550 nm), questo segnale di fluorescenza viene letto dalla
camera RGB (poiché essendo > 410 nm passerà attraverso il dicroico). A questo punto interviene il
fotodiodo. Questo componente controlla che la gran parte di potenza della luce UV-A, il 90% per la
precisione, si diriga verso la cornea del paziente e solo il restante 10% della potenza si diriga verso
la camera. Un ulteriore controllo, davvero molto importante, viene effettuato dal LED di fissazione.
Questo LED infatti “spara” un fascio verde con λ=550 nm verso uno specchio, esso riflette il fascio
verso il basso e lo indirizza verso il paziente. Tale fascio, infatti, serve per l’allineamento dell’asse
visivo dell’occhio del paziente col raggio UV-A utilizzato per effettuare l’intervento. In particolare
se i 2 raggi risultassero shiftati anche di poco il dispositivo si spegnerebbe automaticamente, per
evitare che l’operazione non avvenga nell’opportuna sede della cornea. La scheda elettronica della
camera RGB sarà collegata infine con la scheda elettronica tramite porta USB, scheda che si trova
nel lato opposto della testa ottica.
Per concludere, la testa ottica dispone di due ulteriori controlli dati dai LED blu e rossi.
In particolare:

 LED blu: consentono di illuminare uniformemente la zona da trattare;

 LED rossi: consentono di mettere a fuoco il piano corneale del paziente da trattare;

La figura 36 mostra una schematizzazione circa il funzionamento della testa ottica:

Camera RGB

L3

LD Green led serves for pupil fixation.

DRIVER BS, 10:90
GREEN
L2 DM, longpass
>410 nm
LD UV- PD
DRIVER
A
optical L1 optical
fiber fiber
Two red laser for
focusing at corneal plane
cornea tissue
LD
DRIVER PD
BLUE optical fiber

LASER
DRIVER
RED

Blue led serves to illuminate homogeneously the

cornea. The angle of irradiation is not parallel mcontroller
with respect to the cornea axis but it assumes an
inclination of at least of 30°.

PC
Figura 36: funzionamento schematico della testa ottica

92
 93

Perciò il compito di questi de LED è quello, sostanzialmente, di garantire che il fascio UV-A, una
volta uscito dalla testa ottica, sia perfettamente a fuoco rispetto al piano corneale del paziente ma
inoltre consentono anche di evidenziare meglio la zona irradiata dal fascio UV-A.

4.3.2 Progettazione sistema di controllo e architettura elettronica

L’architettura elettronica ha il compito di controllare il funzionamento della testa ottica. In particolare

questo sotto-assieme si avvale di:

 1 Single Board Computer (SBC) per implementare:

o L’interfaccia grafica per l’utente;
o La comunicazione bluetooth/Wi-Fi
o Il Database;
o L’acquisizione delle immagini della camera RGB;
o L’acquisizione dei segnali di controllo dalla child board
o Il processamento delle immagini e dei segnali;

 1 Child Board, ovvero un microcontrollore che:

o Controlli in tensione/corrente i LED (Current Drivers);
o Monitori i voltaggi dai fotodiodi (UV-A, luce blu);
o Integri un modulo CPLD (Complex Programmable Logic Device) per funzioni critiche
di sicurezza HW;

Il sistema dovrà integrare inoltre un monitor 14/15” Touch Screen capacitivo/resistivo, per la
visualizzazione dell’interfaccia utente.

Il sistema completo è mostrato in figura 37:

Figura 37: Integrazione della Single Board Computer e della Child Board allo schermo
LCD in diverse viste

93
 94

La SBC sarà collegata al microcontrollore, che si troverà dall’altro lato della piastra della testa ottica
vista nel rendering, tramite collegamento seriale. Mentre le immagini dell’intervento, provenienti
dalla camera RGB a monitor, verranno trasmesse tramite collegamento USB tra la SBC e la camera
RGB situata nella testa ottica.

4.3.3 Progettazione Graphic User Interface (GUI)

Una parte importante del dispositivo C4V è ovviamente il Software, ed in particolare la Graphic User
Interface (GUI) o Interfaccia Utente, realizzata a livello di prototipo, in LabView14. Essa consente
all’utente di lavorare facilmente sul dispositivo, fornisce informazioni a schermo sull’intervento, sul
paziente, sulla cornea ed inoltre consente di stampare le suddette informazioni. La schermata iniziale
del menù si presenta come in figura 38:

Figura 38: schermata iniziale GUI

Dalla finestra precedente, il chirurgo avvia la fase di inizializzazione. Infatti, se la macchina è al suo
primo utilizzo, sarà necessaria una calibrazione da parte del tecnico, sul sito dell’utente.
In particolare sarà necessaria la calibrazione della densità di potenza del fascio UV-A e del tempo di
esposizione del paziente al fascio. Questi parametri sono molto importanti al fine di garantire una
buona riuscita dell’intervento sia in termini di risultati attesi, dal punto di vista clinico, sia in termini
di sicurezza verso il paziente. La calibrazione si divide in 4 fasi:

1. Centralizzazione del puntatore laser sul piano focale della telecamera

14
Il prototipo in LabView è stato realizzato interamente all’interno dei laboratori di Vision Engineering Italy, esso
servirà da supporto per progettare il dispositivo HW/SW commerciabile, grazie alla collaborazione con Visia Imaging

94
 95

2. Verifica accensione/spegnimento manuale dei LEDs (UV-A, rosso, verde e blu)

3. Misurazione dei valori di densità di potenza UV-A predefiniti (3, 5, 10, 15, 20 mW/cm2)

4. Infine si varia sia la densità di potenza che il valore di esposizione della camera. Si ha
l’inserimento del campione di fluorescenza pre-calibrato (eccitazione a 365 nm ed emissione
sui 540-560 nm) e regolando i valori di esposizione, si modificano i valori di intensità dei
pixel verdi, per cui tale procedura consiste nel far variare i valori di densità di potenza e di
esposizione in modo tale che eccitando il campione pre-calibrato, si ottiene sempre lo stesso
valore dei pixel verdi ottenuto eccitandolo con la densità di potenza pre-calibrata (figura 39)

Figura 39: fase di inizializzazione

Una volta completata l’inizializzazione, si può tornare al menu principale. Da qui è possibile inserire
le informazioni relative ad un nuovo paziente che dovrà sottoporsi al trattamento. In figura 40 è
mostrata la maschera che il chirurgo compila, inserendo i parametri del paziente ed il tipo di
trattamento che andrà a fare. C’è la possibilità di poter caricare dal database già le informazioni e/o
salvarle.

Figura 40: Inserimento dei dati del paziente

95
 96

Una volta inseriti i dati si passa all’esecuzione di un nuovo trattamento sul paziente. Il trattamento si
divide in tre fasi, la fase di cornea background, la fase di cornea soaking e la fase di UV-A irradiation.
In figura 41 è mostrata la schermata iniziale, in cui, a seconda dello stato del trattamento (cornea
background, cornea soaking, UV irradiation) si attivano e disattivano i LEDs UV-A/blu in modo
automatico e/o manuale tale da consentire al medico di poter intervenire durante il trattamento.
Questa schermata serve inizialmente per centrare l’area della cornea da trattare. In questa fase, il
medico va manualmente a spostare la lampada in modo da centrare il tessuto corneale, inteso come
ROI (Region Of Interest) ed accendere il puntatore laser rosso per facilitare il posizionamento
dell’occhio sul piano focale ed il led blu per il corretto centramento dell’occhio all’interno della ROI
di processamento.

Figura 41: schermata e fasi del trattamento di cross-linking corneale

A questo punto il medico chirurgo può cominciare l’intervento di cross-linking corneale. Il

trattamento, come accennato in precedenza, si divide in tre fasi:

 Cornea Background: è una procedura automatica in cui, per ogni trattamento, è necessario
misurare la fluorescenza di background del tessuto nativo (senza riboflavina), necessario per
valutare la concentrazione durante il trattamento nelle fasi successive. La procedura è la
seguente:

a) Accensione per uno/due sec della lampada UV-A con densità di potenza predefinita
per il trattamento in oggetto;

96
 97

b) Rilevazione dell’intensità media emessa dal tessuto corneale nel canale del verde della
camera RGB, 𝑰𝒃𝒂𝒄𝒌_𝒈𝒓𝒆𝒆𝒏 e memorizzazione di tale valore.

 Cornea Soaking: è una procedura manuale, il medico andrà ad instillare la giusta quantità di
riboflavina nella cornea del paziente. Per capire quale sia questo valore di concentrazione, il
sistema dovrà valutare la concentrazione in real-time, ogni 30s, durante l’intervento.
La procedura consta di diversi passi:

a) Somministrazione di una certa quantità di riboflavina nella cornea del paziente

b) Accensione del LED UV-A con densità di potenza predefinita per il trattamento, per
qualche secondo;
c) Misurazione dei valori di intensità dei pixel verdi, 𝑰𝒈𝒓𝒆𝒆𝒏 (𝒙,𝒚) , all’interno della ROI e
calcolo del valore di intensità media sempre all’interno della ROI, 𝑰𝒈𝒓𝒆𝒆𝒏
d) Calcolo dell’intensità media dentro la ROI, dovuta alla sola informazione della
riboflavina presente nel tessuto corneale, servendosi del valore di intensità di
background trovato nella fase 1: 𝑰 = 𝑰𝒈𝒓𝒆𝒆𝒏 − 𝑰𝒃𝒂𝒄𝒌_𝒈𝒓𝒆𝒆𝒏
e) Valutazione della concentrazione C, ed arresto del processo di somministrazione della
riboflavina se tale C supera la soglia di efficacia del trattamento, pari a 0.0014 g/cm2,
altrimenti, viene ripetuto il procedimento di somministrazione della riboflavina finché
non viene raggiunto tale valore

 UV-A Irradiation: è una procedura automatica, il dispositivo C4V assicura il miglior

trattamento di cross-linking alla cornea del paziente. La schermata non è accessibile o visibile
al medico, in questa fase il dispositivo irradia col fascio UV-A la zona della cornea da trattare.
Per farlo, anche in questo caso, si dovrà monitorare in real-time la concentrazione della
riboflavina. Questa parte della procedura è pressoché identica alla precedente, e si compone
di diversi passi:

a) Accensione del LED UV-A con densità di potenza predefinita per il trattamento
b) Misurazione dei valori di intensità dei pixel verdi, 𝑰𝒈𝒓𝒆𝒆𝒏 (𝒙,𝒚) , all’interno della ROI e
calcolo del valore di intensità media sempre all’interno della ROI, 𝑰𝒈𝒓𝒆𝒆𝒏
c) Calcolo dell’intensità media dentro la ROI, dovuta alla sola informazione della
riboflavina presente nel tessuto corneale, servendosi del valore di intensità di
background trovato nella fase 1: 𝑰 = 𝑰𝒈𝒓𝒆𝒆𝒏 − 𝑰𝒃𝒂𝒄𝒌_𝒈𝒓𝒆𝒆𝒏

97
 98

d) Valutazione della concentrazione C, ed arresto del processo di irradiazione se tale C è

inferiore ad una soglia di sicurezza per il trattamento, tale soglia è raggiunta quando
il 76% della riboflavina somministrata nella fase di Cornea Background viene
catalizzata, altrimenti il processo prosegue fino a che non viene raggiunto tale valore

La curva che viene acquisita al termine dell’intervento rappresenta la variazione della

concentrazione di riboflavina in funzione del tempo, il cui andamento è mostrato in Figura
42. La curva ha un andamento decrescente nel tempo in quanto la riboflavina, assorbendo i
raggi UV-A, va a creare tramite il processo di cross-linking nuovi ponti all’interno dello
stroma corneale:

Figura 42: Concentrazione di riboflavina in funzione del tempo

Al termine dell’intervento, il risultato finale è mostrato in figura 43:

Figura 43: presentazione finale dell'interfaccia utente, al termine del trattamento di cross-linking
corneale

98
 99

È possibile, successivamente, andare a selezionare differenti ROI in termini di dimensione, al fine di

valutare la concentrazione spaziale di riboflavina, ovvero controllare l'efficacia del cross-linking non
omogeneo per migliorare l'acuità visiva. Tale concentrazione spaziale è mostrata in figura 44:

Figura 44: concentrazione spaziale della riboflavina

Infine, una volta terminato il trattamento, viene mostrata una maschera, questa viene compilata
automaticamente dal sistema, dove però il chirurgo può aggiungere delle note, salvare i dati a fine
trattamento e stampare il report da consegnare al paziente (Figura 45).

Figura 45: maschera che consente di salvare e stampare il report dell'intervento

da consegnare al paziente

99
 100

In conclusione, il dispositivo Chromo4Vis può essere impiegato con ogni tipologia di protocollo
chirurgico, per il trattamento del cheratocono (standard o protocollo di Dresda, transepiteliale e
transepiteliale con iontoforesi) sia esso di entità moderata o grave. Il dispositivo ha il compito di
guidare il chirurgo ad eseguire l’intervento in maniera efficace e sicura sul singolo paziente, a
prescindere quindi dal protocollo di trattamento scelto. Il C4V è il primo dispositivo di teranostica al
mondo, in cui è possibile seguire in real-time l’avanzamento del trattamento e quindi la sua efficacia
a differenza di altri dispositivi laser in cui è necessario un follow-up sul paziente a distanza di mesi
dall’intervento.

4.4 Lo sviluppo Software presso Visia Imaging

Visia Imaging, è un’azienda che si occupa della progettazione del software all’interno del progetto
Chromo4Vis (C4V).
L’azienda sfrutta un particolare context per lo sviluppo del software chiamato DevOps, dalla
contrazione inglese di “Development” e “Operations”. Il context di sviluppo DevOps punta alla
comunicazione, collaborazione ed integrazione tra gli sviluppatori del software, al fine di aiutare a
sviluppare in modo più rapido ed efficiente prodotti e servizi software.
All’interno di questo context di sviluppo, per poter andare a progettare un software bisogna affidarsi
ai cosiddetti modelli di sviluppo del ciclo di vita del software, i quali consentono di organizzare al
meglio il ciclo di vita del prodotto software. Da questo punto di vista la metodologia di sviluppo
adottata dall’azienda, per sviluppare i suoi progetti, è la metodologia AGILE.
Il termine “AGILE”, coniato nel 2001, è un termine utilizzato per descrivere un gruppo di metodi di
sviluppo software nei quali la progettazione evolve attraverso la collaborazione tra i vari team di
sviluppo. Esso promuove un approccio basato sulla pianificazione adattiva, sviluppo evolutivo,
apprendimento continuo, ed incoraggia una rapida e flessibile risposta alle modifiche.
I metodi agili, spesso definiti framework, sono approcci globali alle fasi del ciclo di vita dello
sviluppo del software: pianificazione, esecuzione e consegna. [1]
In particolare, la metodologia agile è una tipologia di sviluppo usata per descrivere la progettazione
software in maniera iterativa. Lo sviluppo di software in maniera iterativa, accorcia il ciclo di vita
dello sviluppo del software. I team di sviluppo agili, eseguono l'intero ciclo di vita dello sviluppo del
software tramite piccoli incrementi, solitamente chiamati sprint. Gli sprint durano in genere 1-4
settimane. Lo sviluppo agile è spesso in contrasto con lo sviluppo tradizionale o waterfall, in cui
progetti più grandi sono pianificati in anticipo ed eseguiti contro tale piano. Produrre un codice di
qualità ad ogni sprint richiede che il team di sviluppo agile rispecchi il ritmo accelerato. Tutti i codici,
i test e la verifica della qualità devono essere eseguiti ad ogni singolo sprint. [2]

100
 101

4.4.1 Project Management

Per quanto riguarda la gestione della progettazione l’azienda, come già accennato nel paragrafo
precedente, sfrutta Azure DevOps. In seguito è possibile visualizzare la gestione relativa al progetto
C4V:

 Azure Boards: fornisce una serie di strumenti “Agili” da utilizzare per pianificare e tenere
traccia del progetto ed eventuali problemi. Al suo interno si hanno:

o Work Items (WITs): sono gli elementi di lavoro del progetto. Ogni Work Item
rappresenta un oggetto memorizzato nell'archivio dati dei Work Items. Ogni Work Item
è basato su uno specifico tipo e gli è assegnato un ID che lo contrassegna
univocamente all’interno dell’organizzazione o del team di progetto (Figura 47).

Figura 46: Esempi di WITs in cui è possibile notare l'ID, l'assegnazione, lo stato ed
il titolo [2]

o Boards: esse presentano i WITs come delle cards e consentono un aggiornamento

rapido dello stato dei WITs attraverso la semplice operazione di drag-and-drop.
Il nome “board” deriva dal fatto che le cards sono simili a quelle attaccate ad una
lavagna magnetica. Si possono definire colonne, settare limiti Work-In-Progress
(WIP), definire un lavoro “Done”, ed altro (Figura 47).

101
 102

Figura 47: struttura di una Board con i vari WITs [2]

o Backlogs: i Backlogs presentano i WITs come una lista gerarchica. Un product

backlog rappresenta il piano di progetto. Col termine “Product Backlog” si
definiscono tutti i WITs da svolgere, mentre con “Iteration Backlog” si intende un
lavoro da completare durante una specifica iterazione (Figura 48).

Figura 48: Portflio Backlog che mostra come i vari backlog sono gerarchicamente
definiti, l'assegnamento, lo stato ed il titolo [2]

o Sprints: forniscono una visione filtrata della lista di WITs (backlog) che il team ha
assegnato ad uno specifico percorso, detto Sprint. Gli Sprint sono definiti per un
progetto dal team di lavoro. Ogni WIT assegnato ad uno specifico Sprint, deve essere
ultimato dal membro del team entro il tempo specificato dallo Sprint (Figura 49).

102
 103

Figura 49: Filtro dei backlog che mostra i WITs rimanenti assegnati ed i giorni
rimanenti per completare lo Sprint [2]

o Queries: sono liste filtrate di WITs. Le query consentono di trovare gruppi di WITs
che hanno qualcosa in comune, in questo modo si possono smistare un set di WITs al
fine di modificarne la priorità o assegnarli (Figura 50).

Figura 50: Esempio di query per filtrare WITs accomunati tra loro [2]

 Repository: al suo interno viene inserito il codice sorgente vero e proprio del progetto.
In particolare il codice sorgente viene scritto all’interno di un editor di sviluppo professionale,
come Visual Studio. Qui tramite una procedura denominata archiviazione, il codice sorgente
apparirà all’interno della cartella Repos in DevOps.

103
 104

All’interno della metodologia AGILE, i WITs si presentano all’interno della struttura mostrata in
figura 51:

Figura 51: Struttura dei WITs all'interno del processo Agile [2]

Vediamo più nel dettaglio a cosa si riferisce ogni elemento evidenziato nell’immagine:

 Epic: rappresentano le macro-funzionalità del prodotto software. In particolare possiamo dire

che Epic corrisponde alla decomposizione SW discussa nel capitolo 2 (SW System, SW Item
e SW Unit)

 Features: le features rappresentano i sotto-moduli del prodotto software. In particolare le

features rappresentano i cosiddetti Product Requirements Document (PRD) di un progetto
SW. Essi contengono le specifiche di quello che l’intero dispositivo deve fare sia da un punto
di vista SW che HW

 User Story: sono riferite alle necessità specifiche dell’utente da inserire all’interno del
prodotto SW. In particolare le User Stories rappresentano i cosiddetti Software Requirements
Specification (SRS) di un progetto SW. Essi contengono i requisiti che il dispositivo software
deve soddisfare

 Task: rappresentano la parte operativa della progettazione SW. In particolare i Task

rappresentano i cosiddetti Software Design Specification (SDS) di un progetto SW. Essi
contengono le specifiche SW necessarie per trasformare i requisiti SW in un prodotto vero e
proprio prodotto software

104
 105

 Bug: rappresentano un particolare malfunzionamento all’interno del codice. [2]

4.4.2 Procedura di sviluppo

Visia Imaging presenta una sua procedura di sviluppo software ben definita, questa procedura
operativa fornisce una linea guida sulla gestione del ciclo di vita delle Applicazioni (ALM) per i
dispositivi medici progettati dall’azienda, in particolar modo orientata alla progettazione e lo sviluppo
del software. La procedura di sviluppo software è stata redatta in accordo con le principali direttive
internazionali:

 93/42/CEE: direttiva sui dispositivi medici

 98/79/CEE: direttiva sui dispositivi medici diagnostici in vitro
 UNI EN ISO 14971:2012: applicazione della gestione dei rischi ai dispositivi medici
 UNI EN ISO 13485:2016: sistema di regolazione della qualità nei dispositivi medici, requisiti
per scopi regolatori
 US cGMP 21CFR820.30: Current Good Manufacturing Processes
 CEI EN 62304:2006: processi relativi al ciclo di vita del software per dispositivi medici
 EN 62366:2015: applicazione della usability engineer ai dispositivi medici
 FDA, Guidance for the content of Premarket Submission for software contained in medical
device
 FDA, General Principles of Software Validation
 FDA, Off-The-Shelf Software use in medical device
 AAMI TIR45: guidance on the use of agile practices in the development odfmedical device
software

4.4.3 ALM: Modello del ciclo di vita e processi di sviluppo del

software

I documenti guida e gli standard richiedono che i fabbricanti dei dispositivi medici software scelgano
e definiscano il loro Modello di sviluppo del Ciclo di vita del Software (SDLC) rispettando le
attività che un processo software deve osservare.
Visia Imaging, sotto questo punto di vista, ha deciso di utilizzare un modello di sviluppo del ciclo di
vita del software Incrementale/Evolutivo con una personalizzazione del classico modello di

105
 106

sviluppo del ciclo di vita del software AGILE, necessario per poter sviluppare in un contesto di
dispositivo medico regolamentato.

Questo modello di sviluppo, segue il modello Incrementale in funzione di come la definizione ampia
del prodotto viene suddivisa in piccoli pezzi sul Backlog, con quei pezzi ulteriormente definiti,
progettati, codificati e testati, una Story alla volta, effettuo dei brevi incrementi. Il modello di sviluppo
segue, inoltre, il modello Evolutivo nel modo in cui esso consente la definizione del prodotto evolva
nel tempo, a volte effettuando attività di progettazione, coding e testing in maniera dinamica.

I pezzi sono integrati attraverso procedure di integrazione e validazione per dimostrare che le parti
aggiunte al sistema sono consistenti e non influiscono sulle funzionalità del sistema completo.

In Figura 52 è mostrato il processo spiegato in precedenza:

Figura 52: schema concettuale del processo di sviluppo del software presso Visia Imaging [1]

In base a quanto visto nella CEI EN 62304:2006, esso è uno standard che definisce una lista dei
processi del ciclo di vita del software con le attività ed i task necessari per la progettazione ed il
mantenimento dei dispositivi medici in totale sicurezza. Per quanto riguarda gli Stati Uniti, il 21 CFR
820 stabilisce una serie di procedure interconnesse le quali devono essere incorporate nel progetto e
sviluppo del dispositivo medico. Non viene specificato però nessun ciclo di vita per lo sviluppo del
software così come non vengono specificati controlli e task che devono essere integrati nel processo
di sviluppo del fabbricante. In base a questi standard, le attività del ciclo di vita del software, sono le
seguenti:

106
 107

1. SW Development Planning
2. SW Requirements Analysis
3. SW System Design
4. SW Unit Implementation and Verification
5. SW Integration and Integration Testing
6. SW System Testing
7. SW Release

Il modello del ciclo di vita è composto da quattro layers of abstraction, in cui sono eseguite le attività:

1. Project Layer
2. Release Layer
3. Incremental Layer
4. Story Layer

Le attività ed il modello del ciclo di vita descritto in precedenza sono mostrati in Figura 53:

Figura 53: Modello del ciclo di vita del Software utilizzato da Visia Imaging [1]

107
 108

Vengono analizzati ora, più nel dettaglio, i layer of abstraction citati in precedenza:

1. Project Layer: il ruolo del Project Layer è quello di fornire un set completo di attività
necessarie a consegnare un prodotto software ultimato

2. Release Layer: il ruolo del Release Layer è quello di fornire le attività eseguite per creare un
prodotto utilizzabile. Un progetto è fatto di una o più versioni, dipendentemente dal piano del
progetto, una versione può generare un prodotto che è o può essere venduto, oppure generare
una serie di funzionalità destinate solamente ad un uso interno

3. Incremental Layer: il ruolo del Incremental Layer è quello di fornire le attività per creare un
set di funzionalità utili, tuttavia non necessariamente un prodotto software completo. Una
versione è fatta di uno o più incrementi

4. Story Layer: il ruolo dello Story Layer è quello di fornire le attività per creare piccoli pezzi
funzionali, tuttavia non necessariamente un set completo. Un incremento è fatto di una o più
stories.

Infine viene dato un ulteriore dettaglio delle relative attività del ciclo di vita del software in accordo
col modello Incrementale/Evolutivo mostrato in figura 53:

 Software Development Planning: il Project Manager definisce la pianificazione nei differenti

Layers. All’interno del Project Layer, la pianificazione affronta le attività ad alto livello in
termini di gestione del progetto, nel Release Layer la pianificazione affronta invece le attività
a medio-livello, nel Incremental Layer si affrontano invece le attività a basso livello ed infine
nello Story Layer viene affrontata la pianificazione individuale dettagliata (assegnazione dei
task, pianificazione dettagli esecutivi per i task giornalieri, monitoraggio dei progressi)

 Software Requirements Analysis: lo scopo di questa attività è quello di determinare e

specificare i requisiti software (SRS) che devono essere incontrati durante l’intero ciclo di
vita del progetto. Questi requisiti non devono né essere in conflitto tra loro né tantomeno
risultare ambigui, bensì devono risultare facilmente verificabili per controllare che la
funzionalità garantita sia accettabile per l’utilizzatore. Le User Stories sono le prime forme di
espressione dei requisiti usati nel SDLC di Visia Imaging, i SRS saranno quindi una serie di
User Stories, in tal modo le SRS evolveranno con l’evolvere del sistema, come mostrato in
figura 54:

108
 109

Figura 54: SRS visti come una collezione di User story [1]

 Software Architectural Design: la progettazione architettonica del software avviene in due

level of abstraction. Nel Project Layer, avviene la progettazione architettonica principale.
Nello Story Layer, utilizzando i concetti AGILI di progettazione semplice e Refactoring15,
l'architettura del software emerge per supportare la nuova funzionalità aggiunta da una Story.

 Software Detailed Design/Software Design Specifications (SDS): la Software Design

Specifications (SDS) è una descrizione di cosa il software dovrebbe fare e come dovrebbe
farlo. Il Project Manager insieme agli sviluppatori traducono i requisiti Software in una
rappresentazione logica e fisica del software da implementare. In particolare viene identificato
il singolo "Software Item" che elenca in dettaglio le singole specifiche del software funzionale.
In seguito il Project Manager decompone, ogni Software Item, nelle sue Software Unit.

 Software Unit Implementation and Verification: per ogni Software Unit viene scritto il
codice sorgente, in questa fase finisce la decomposizione dei requisiti software ed inizia
l’implementazione dei Software Item, ed infine vengono definiti i protocolli di testing da
utilizzare per verificare il codice sorgente prodotto

 Risk Management: similmente alle altre attività del processo di sviluppo software, non tutti i
rischi sono conosciuti all’inizio del progetto bensì molti di questi si presentano man mano che
il dispositivo evolve. In questa fase vengono identificate potenziali cause di pericolo del
software come Bug del software, incompleta definizione delle funzioni da implementare ecc.
I risultati del processo di gestione del rischio sono documentati dal Project Manager durante

15
Col termine Refactoring si intende il miglioramento della struttura interna del codice sorgente di un programma esistente, preservandone tuttavia il
comportamento esterno

109
 110

l’intero processo di sviluppo del software all’interno del Risk Management File (RMF)

 Software Design Change: durante questa analisi, modifiche al software devono essere
valutate per l’impatto che queste hanno sul funzionamento del software stesso e le attività
devono essere identificate e ripetute, anche nella misura della riclassificazione della classe di
sicurezza del software

 Traceability: dal momento che il PRD è il documento di controllo per quanto concerne ciò
che il dispositivo necessita di fare sia da un punto di vista hardware che software, il Project
Manager mantiene una tracciabilità tra le caratteristiche descritte, ad alto livello, nel PRD e
le user Stories descritte nel SRS, come mostrato in Figura 55: [1]

Figura 55: tracciabilità tra PRD ed SRS [1]

110
 111

4.5 Test del Software

Il test del software è una procedura che viene fatta a “basso livello” consentendo di verificare la
funzionalità del nostro codice sorgente. Nel capitolo 2 e 3 sono state introdotte due tipologie principali
di test, i test Black-Box ed i test White-Box, rispettivamente dei test strutturali e funzionali. In questo
capitolo l’attenzione si sposta verso le varie metodologie di questi test accennati già nel capitolo 3.

4.5.1 Test White-Box

Il test White-Box è un particolare tipo di test che viene effettuato per rilevare errori in uno o più
componenti (parte di codice, metodo, funzione, classe, programmi, ecc.) di un sistema software.
Il suo funzionamento si basa su alcuni criteri che hanno lo scopo di trovare dati di test che consentano
di percorrere tutto il programma. Per trovare un errore nel codice, infatti, bisogna usare dei dati che
“percorrono” la parte erronea del programma. Per testare una parte di programma si introduce il
concetto di cammino: una sequenza di istruzioni attraversata durante un'esecuzione. Naturalmente
non esiste un criterio in grado di testare ogni singolo cammino dato l'elevato numero di questi ultimi
(soprattutto in presenza di cicli), tuttavia, è possibile trovare un numero finito di cammini
indipendenti che combinati tra loro forniscano tutti, o per lo meno la maggior parte, i restanti
cammini. Se eseguito correttamente e senza particolari eccezioni, il test può coprire fino al 90% delle
istruzioni.

I test White-Box più utilizzati sono in genere tre:

 Statement Code Coverage: è un test nel quale bisogna dare una certa copertura di controllo ai
vari statement del codice sorgente. Lo Statement Code Coverage è una tecnica di White-Box
testing che implica l'esecuzione di tutte le istruzioni eseguibili nel codice sorgente almeno una
volta. L’obiettivo del test Statement Code Coverage è quello di misurare il numero di
istruzioni nel codice sorgente che possono essere eseguite in base ai requisiti.
Uno statement non è altro che una riga di codice, terminante col “;”. La copertura in
particolare, viene data in % ed in genere una buona copertura si aggira intorno all’80%.
Ovviamente perché ci sia una copertura del 100% dovrò fare in modo di dare dei parametri in
input che mi consentano di controllare ogni statement, ovvero ogni espressione del mio codice
sorgente, almeno una volta.

111
 112

(𝑛𝑢𝑚𝑒𝑟𝑜 𝑑𝑖 𝑠𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡 𝑒𝑠𝑒𝑔𝑢𝑖𝑡𝑖)

𝑠𝑡𝑎𝑡𝑒𝑚𝑒𝑚𝑒𝑛𝑡 𝑐𝑜𝑑𝑒 𝑐𝑜𝑣𝑒𝑟𝑎𝑔𝑒 = ∙ 100
(𝑛𝑢𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙𝑒 𝑑𝑖 𝑠𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡)

 Branch Code Coverage: è un test in cui bisogna avere come requisito che, per ciascun ramo
nel programma, ad esempio, istruzioni if/else o cicli, ogni ramo sia stato eseguito almeno
una volta durante il test. A volte viene anche detto che ogni condizione del ramo deve essere
stata “vera” almeno una volta e “falsa” almeno una volta durante il test.
In questo modo si riesce a garantire che ogni possibile ramo, da ogni condizione di decisione,
venga eseguito almeno una volta.
(𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑖 𝐵𝑟𝑎𝑛𝑐ℎ𝑒𝑠)
𝐵𝑟𝑎𝑛𝑐ℎ 𝐶𝑜𝑑𝑒 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 = ∙ 100
(𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐵𝑟𝑎𝑛𝑐ℎ𝑒𝑠)

È quindi un test nel quale il codice sorgente deve rispettare entrambe le condizioni del branch
almeno una volta. In questo caso verranno forniti due input differenti che vadano a testare
l’efficacia/inefficacia del branch (Figura 56).

Figura 56: Branch Code Coverage

 Branch Condition Code Coverage: è un test nel quale vengono valutate, almeno una volta, le
singole espressioni logiche dei branch. A volte, infatti, le condizioni dipendono da diverse
condizioni più piccole, queste singole espressioni logiche più piccole sono chiamate
condizioni atomiche logiche. Una condizione atomica logica è una condizione che non ha
operatori logici come AND, NOT, OR ma che include i simboli <, > o =.
Una condizione a sua volta, potrà essere formata da diverse condizioni atomiche
logiche. La copertura del codice sorgente dovrà rispettare entrambe le condizioni del branch,
TRUE o FALSE, almeno una volta (figura 57).

Figura 57: Branch Condition Code Coverage

112
 113

Infine la Branch Condition Code Coverage è una copertura meno debole rispetto alla
Statement Code Coverage ed alla Branch Coverage in quanto non è richiesto eseguire ogni
dichiarazione o statement.

4.5.2 Test Black-Box

Il test Black-Box è un particolare tecnica di test del software nel quale la funzionalità del software
viene testata senza guardare alla struttura interna del codice, i dettagli di implementazione e la
conoscenza delle parti interne del software. Questo tipo di test si basa interamente sui requisiti e le
specifiche del software. Nel test Black-Box ci si focalizza dunque sugli input ed output del sistema
senza preoccuparsi della conoscenza interna del programma software, come si evince dalla figura 58:

Figura 58: schema concettuale del funzionamento del test Black-Box

Vi sono diverse tipologie di test Black-Box, tuttavia le seguenti sono le più importanti:

 Functional testing: questa tipologia di test Black-Box è relazionata ai requisiti funzionali del
sistema ed è eseguita dai software tester

 Non-Functional testing: questa tipologia di test Black-Box non è relazionata a testare una
specifica funzionalità del software, bensì ai requisiti non-funzionali quali performance,
scalabilità ed usabilità

 Regression Testing: questa tipologia di test Black-Box viene effettuata dopo aver terminato
la correzione del codice, aggiornamenti o qualsiasi altra manutenzione del sistema per
controllare che il “nuovo codice” non abbia influito sul codice esistente

113
 114

4.6 Validazione di un requisito software

Tra i requisiti fondamentali per la corretta applicazione, in termini di efficacia, che il trattamento di
cross-linking corneale deve avere vi è sicuramente il calcolo della concentrazione di riboflavina
durante il trattamento. In relazione alle tre fasi del trattamento di cross-linking cornale, la valutazione
della concentrazione in real-time durante l’intervento è fondamentale, per andare a stabilire la reale
efficacia che il trattamento ha nei confronti della cornea del paziente.

In particolare, la fase in questione è la fase di UV-A irradiation, ovvero la fase del trattamento in cui
si verifica il processo di fotoreazione tra il fascio UV-A e le molecole di riboflavina, somministrate
al paziente, con la formazione di nuovi ponti di collagene nello stroma corneale, riportando lo
spessore corneale ai valori fisiologici, contrastando in questo modo lo sfiancamento della cornea a
causa della patologia.
Al fine di andare a studiare come varia la concentrazione della riboflavina durante il trattamento, si
sfrutta una funzione, che fa corrispondere la lettura dei livelli di verde della camera RGB alla
concentrazione della riboflavina incognita. Nello specifico ad ogni istante il sistema registra la lettura
dei livelli di verde della camera RGB, questo livello di intensità viene pesato tramite dei coefficienti
e risulta essere proporzionale, in quel preciso istante, con la concentrazione di riboflavina presente a
livello corneale. In questo, in ogni istante del trattamento è possibile monitorare in real-time,
l’andamento della concentrazione in maniera tale che il medico chirurgo possa arrestare il processo
qualora tale concentrazione risultasse inferiore ad una soglia di sicurezza del trattamento.

La funzione dell’intensità (fluorescenza) dei livelli di verde in funzione della concentrazione della
riboflavina è la seguente:

𝐶 = 𝑝1 ∙ 𝐼 + 𝑝2 ∙ 𝐼 2 (16)

In cui:

 I: è il valore di intensità del pixel verde;

 𝑝1, 𝑝2 : sono dei parametri di fit della funzione, la procedura per la loro determinazione viene
effettuata sulla macchina prima della sua immissione in commercio. I valori che si
determinano non vengono modificati da macchinario a macchinario, bensì restano tali;

16
All-Optical Method to Assess Stromal Concentration of Riboflavin in Conventional and Accelerated UV-A Irradiation of the Human Cornea,
Investigate Ophtalmology & Visual Science, M. Lombardo, G. Lombardo

114
 115

4.6.1 Implementazione dello Unit Test per la validazione del

requisito software

La validazione dei requisiti software è stata implementata all’interno del software Visual Studio,
tramite la creazione di una classe in C# in cui viene implementato il calcolo della concentrazione
della riboflavina in accordo con la legge spiegata nel capitolo precedente. Al fine di validare il
requisito è stato poi implementato uno Unit Test riferito proprio a tale classe, in cui si è messo in
evidenza in funzionamento della classe sia in condizioni ottimali che non ottimali, riscontrando perciò
anche eventuali errori nella procedura.

Per prima cosa è stata implementata una classe in C# su Visual Studio, di nome
CrossLinkingCalculator all’interno di essa viene implementato il metodo per il calcolo della
concentrazione di Riboflavina. Il metodo prende come input l’intensità (intensity) e i due parametri
di fit p1 e p2, in particolare l’intensità è di tipo uint (uninsigned int) in quanto non può avere un valore
negativo. Tale classe è mostrata in Figura 59:

Figura 59: Classe in C# che implementa il metodo CrossLinkingCalculator

A questo punto è stato fatto il test, lo schema AAA (Arrange, Act, Assert) è un modo comune per
scrivere unit test per un metodo da testare.
 La sezione Arrange di un metodo di Unit Test inizializza oggetti e imposta il valore dei dati
passati al metodo da testare

115
 116

 La sezione Act richiama il metodo da testare con i parametri definiti

 La sezione Assert verifica che l'azione del metodo da testare si comporti come previsto
In particolare, a livello di codice C#, la classe per implementare lo Unit Test è mostrata in Figura 60:

Figura 60: classe in C# che implementa lo Unit Test del metodo CrossLinkingCalulator

Nel primo pezzo di codice vado a testare il metodo di calcolo della concentrazione, quando al doppio
dell’intensità mi aspetto il doppio della concentrazione. Nell’Arrange vado quindi a creare una nuova
classe CrossLinkingCalculator per inizializzare il test, nell’Act vado a creare due variabili double
dove, richiamando il metodo CalculateConcentration, gli passo i tre parametri (intensità, p1 e p2) ed
eseguo il calcolo. La prima variabile calcola la concentrazione mentre la seconda calcola il doppio
della concentrazione (in quanto li passerò 2 volte il valore dell’intensità). A questo punto si passa
all’Assert in cui si verifica che il metodo funzioni correttamente e quindi verifico effettivamente che
concentration_double_intensity > 2 * concentration.

Nel secondo pezzo di codice vado a testare il metodo di calcolo della concentrazione, quando non
ho nessun valore di intensità e mi aspetto perciò una concentrazione nulla. Nell’Arrange vado quindi
a creare una nuova classe CrossLinkingCalculator per inizializzare il test, nell’Act vado a creare una
variabile double dove, richiamando il metodo CalculateConcentration, gli passo i tre parametri
(intensità, p1 e p2), di cui però intensità ha valore nullo, ed eseguo il calcolo. A questo punto si passa

116
 117

all’Assert in cui si verifica che il metodo funzioni correttamente e quindi verifico effettivamente che
la concentrazione trovata sia nulla, ovvero concentration < Double.Epsilon.

Al fine di eseguire il test è stato utilizzato un tool di Visual Studio denominato AxoCover (Figure 61
e 62):

Figura 61: risultato dello Unit Test della classe CrossLinkingCalculator tramite AxoCover

Figura 62: risultato dello Unit Test del metodo Calculator tramite AxoCover

117
 118

Infine il report del test (Figura 63), è stato generato dal tool AxoCover di Visual Studio, utilizzato per
implementare il test. Nella parte in alto è mostrato un sommario, che riassume i risultati del test, ed
in basso, per ogni classe, gli statement coperti, non coperti e totali, la percentuale di statement coperti
(la colonna Line coverage) inclusi i branches (la colonna Branch coverage) (notare come i branches
li ho solo nella prima classe in quanto ho l’if sull’intensità). Si può notare come la copertura del test
risulta essere del 100%, tuttavia in un caso più “reale” una buona copertura sfiora circa l’80%-85%.

Figura 63: report relativo allo Unit Test in uscita da AxoCover

118
 119

Conclusioni

La validazione del software medicale è un processo molto complesso, ma necessario al fine di

garantire al futuro utilizzatore un dispositivo efficace e sicuro. Sicurezza ed efficacia sono infatti i
due termini chiave da soddisfare in un contesto clinico in cui la salute del paziente è protagonista. La
tesi ha permesso di mettere in risalto caratteristiche e peculiarità del quadro normativo Europeo e
Statunitense delineando quelli che sono gli step cardini del processo di validazione di un software in
ambito clinico.
Quanto visto a livello normativo è servito per poter applicare una procedura di validazione di un
requisito software all’interno di un contesto pratico, il progetto Chromo4Vis. Il dispositivo mira ad
arrestare e trattare una patologia degenerativa della retina, il cheratocono. Il funzionamento del
dispositivo guida attraverso le immagini il medico durante la fase di trattamento, ed all’interno di
questo contesto un requisito fondamentale è il monitoraggio della concentrazione della riboflavina
all’interno della cornea del paziente. La validazione è stata eseguita a livello di Software Unit, in cui
si è andato a testare il comportamento del codice che implementa il calcolo della concentrazione al
fine di valutare sia il suo corretto funzionamento, fornendo i giusti input al programma, sia
monitorando eventuali errori riscontrati, ottenuti inserendo differenti parametri ed input al
programma (Black-Box test), confermandone l’efficacia. In conclusione sono state studiate le
normative per la certificazione del software medicale, e questi concetti applicati al progetto
Chromo4Vis. È importante sottolineare come l'importanza del processo di sviluppo software, in un
contesto in cui il software avrà un ruolo sempre più determinante, coinvolga sempre più il dispositivo
medico software (SaMD) rispetto al classico concetto di dispositivo medico. A fronte di ciò, grazie
ad una legge che entrerà in vigore dal 2020, ogni azienda produttrice di dispositivi medici, dovrà
avere delle figure “responsabili del rispetto delle normative sui dispositivi medici”, aprendo quindi
nuovi scenari ed opportunità per il ruolo dell’ingegnere biomedico.

119
120

120
 121

Bibliografia
[1] Consiglio delle Comunità Europee, “Attuazione Della Direttiva 93/42/CEE, concernente i
Dispositivi Medici” 1993.

[2] M. D. Alfredo Castellano, Giorgio De Nunzio, "Fisica e Tecnica delle apparecchiature

biomediche". 2009.

[3] Thema-Med, “Cybersecurity: una nuova sfida per la sicurezza del paziente.” 2016.

[4] Ministero della Salute, “Definizione di ictus ischemico.”:

http://www.salute.gov.it/portale/salute/p1_5.jsp?lingua=italiano&id=28&area=Malattie_card
iovascolari.

[5] IMDRF Software as a Medical Device (SaMD) Working Group, “Software as a Medical
Device: possible Framework for Risk Categorization and Corresponding Considerations”
2014.

[6] Consiglio delle Comunità Europee, “Attuazione della Direttiva 2004/CE del Consiglio del 5
settembre 2007 che modifica la direttiva 90/385/CEE del Consiglio per il ravvicinamento
delle legislazioni degli Stati membri relative ai dispositivi medici impiantabili attivi, la
direttiva 93/42/ 2007".

[7] Consiglio delle Comunità Europee, “Attuazione della direttiva 90/385/CEE del Consiglio del
20 giugno 1990 concernente i dispositivi medici impiantabili attivi” 1990.

[8] C. delle C. Europee, “Attuazione Della Direttiva 93/42/CEE Concernente I Dispositivi

Medici” 2010.

[9] E. COMMISSION, E. and Sme. DG Internal Market, Industry, E. and H. T. Directorate

Consumer, and U. H. technology and Cosmetics, “Guidelines on the qualification and
classification of stand alone software used in Healthcare within the regulatory framework
of medical devices” 2016.

[10] Consiglio delle Comunità Europee, “Attuazione della direttiva 98/79/CE relativa ai dispositivi
medico-diagnostici in vitro” 2000.

[11] C. Comitato Elettrotecnico Italiano, “Software per dispositivi medici - Processi relativi al
ciclo di vita del software.”

[12] Food and Drug Administration, “Guidance for the Content of Premarket Submissions for

121
 122

Software Contained in Medical Devices” p. 23, 2005.

[13] International Organization for Standardization, “Medical devices - Application of risk

management to medical devices” p. 36, 2012.

[14] I. O. for standardization ISO, “Medical devices -Quality management systems - Requirements
for regulatory purposes” 2016.

[15] C. Comitato Elettrotecnico Italiano, “Medical electrical equipment -- Part 1-8: General
requirements for basic safety and essential performance -- Collateral standard: General
requirements, tests and guidance for alarm systems in medical electrical equipment and
medical electrical systems” 2006.

[16] C. Comitato Elettrotecnico Italiano, “Safety requirements for electrical equipment for
measurement, control, and laboratory use - Part 1: General requirements” 2010.

[17] C. Comitato Elettrotecnico Italiano, I. International Organization for standardization, and I.

Institute of Electrical and Electronics Engineers, “Systems and software engineering --
Software life cycle processes” 2017.

[18] C. Comitato Elettrotecnico Italiano, “Functional safety of electrical /electronic/

programmable electronic safety-related systems – Parts 1 to 7 together with a Commented
version” 2010.

[19] C. Comitato Elettrotecnico Italiano and I. International Organization for standardization,

“Software engineering -- Guidelines for the application of ISO 9001:2008 to computer
software” 2014.

[20] U.S Food and Drug Administration (FDA), “Database FDA recalls.”

[21] U.S Food and Drug Administration (FDA), “General Principles of Software Validation;
Final Guidance for Industry and FDA Staff (Document issued on: January 11, 2002)” FDA
Guid., p. 47, 2002.

[22] Università della Sapienza, “Controllori a Logica Programmabile (PLC).”:

http://www.diag.uniroma1.it/~deluca/automation/Automazione_PLC.pdf.

[23] ISO, “International Organization for standardization.”:

https://www.iso.org/standard/20115.html.

[24] U.S Food and Drug Administration (FDA), “FDA Medical Device Regulations.”:
https://www.fda.gov/medicaldevices/deviceregulationandguidance/postmarketrequirements/q

122
 123

ualitysystemsregulations/.

[25] U.S Food and Drug Administration (FDA), “CFR - Code of Federal Regulations Title 21.” :
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=820.

[26] U.S Food and Drug Administration (FDA), “CFR – Code of Federal Regulations Title
11.10.”: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10.

[27] U.S Food and Drug Administration (FDA), “Guidance for Industry - FDA Reviewers and
Compliance on Off-The-Shelf Software Use in Medical Devices” Change, p. 29, 1999.

[28] R. Health, “DESIGN CONTROL GUIDANCE FOR MEDICAL DEVICE

MANUFACTURERS,” 1997.

[29] R. Mencucci et al., “Effects of riboflavin/UVA corneal cross-linking on keratocytes and

collagen fibres in human cornea” Clin. Exp. Ophthalmol., vol. 38, no. 1, pp. 49–56, 2010.

[30] Y. Joshua Wheeler, Michael A. Hauser, Natalie A. Afshari, R. Rand Allingham and Liu, “The
Genetics of Keratoconus: A Review” vol. 45, no. 6, pp. 788–802, 2008.

[31] A. S. G. Nallathambi Jeyabalan, Rohit Shety1, Anuprita Ghosh2, Venkata Ramana Anandula
and G. Kumaramanickavel, “Genetic and genomic perspective to understand the molecular
pathogenesis of keratoconus” Indian J. Ophthalmol., vol. 61, no. 8, p. 384, 2013.

[32] C. N. Mcghee, “Keratoconus: The arc of past, present and future” Clinical and Experimental
Optometry, vol. 96, no. 2, pp. 137–139, 2013.

[33] R. Ambekar, K. C. Toussaint, and A. Wagoner Johnson, “The effect of keratoconus on the
structural, mechanical, and optical properties of the cornea” J. Mech. Behav. Biomed.
Mater., vol. 4, no. 3, pp. 223–236, 2011.

[34] M. H. and T. S. EBERHARD SPOERL, “Induction of Cross-links in Corneal Tissue” no. May
1997, pp. 97–103, 1998.

[35] P. Kamaev, M. D. Friedman, E. Sherr, and D. Muller, “Photochemical kinetics of corneal

cross-linking with riboflavin” Investig. Ophthalmol. Vis. Sci., vol. 53, no. 4, pp. 2360–2367,
2012.

[36] M. Lombardo, S. Serrao, M. Rosati, P. Ducoli, and G. Lombardo, “Biomechanical changes

in the human cornea after transepithelial corneal crosslinking using iontophoresis” J.
Cataract Refract. Surg., vol. 40, no. 10, pp. 1706–15, 2014.

123
 124

[37] G. Lombardo, N. L. Micali, V. Villari, S. Serrao, and M. Lombardo, “All-optical method to

assess stromal concentration of riboflavin in conventional and accelerated UV-A irradiation
of the human cornea” Investig. Ophthalmol. Vis. Sci., vol. 57, no. 2, pp. 476–483, 2016.

[38] M. Lombardo, S. Serrao, P. Raffa, M. Rosati, and G. Lombardo, “Novel Technique of

Transepithelial Corneal Cross-Linking Using Iontophoresis in Progressive Keratoconus” J.
Ophthalmol., vol. 2016, 2016.

[39] P. Vinciguerra et al., “Transepithelial Iontophoresis Versus Standard Corneal Collagen

Cross-linking: 1-Year Results of a Prospective Clinical Study” J. Refract. Surg., vol. 32, no.
10, pp. 672–678, 2016.

[40] Z. X. Zhang X, Zhao J, Li M, Tian M, Shen Y, “Conventional and transepithelial corneal

cross-linking for patients with keratoconus” PLoS One, 2018.

[41] E. Spoerl, M. Mrochen, D. Sliney, S. Trokel, and T. Seiler, “Safety of UVA-riboflavin cross-
linking of the cornea” Cornea, vol. 26, no. 4, pp. 385–389, 2007.

[42] L. Del Tongo and S. Fantechi, “Software Development Procedure” 2018.

[43] Microsoft, “https://docs.microsoft.com/en-us/azure/devops/learn/agile/what-is-agile.” .

[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27
][28][29][30][31][32][33][34][35][36][37][38][39][40][41][42][43]

124