4 Capitolo v1.1

Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
4. DEFINIZIONE DEL PROTOCOLLO PER LA
VALIDAZIONE DELLA PIATTAFORMA
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
4.1. Riferimenti legislativi e normativi
La piattaforma per l’integrazione del follow-up ambulatoriale dei
pazienti affetti da Scompenso Cardiaco con il servizio di home-monitoring,
può attualmente (e in un prossimo futuro dovrà) ritenersi un dispositivo
medico in forza alla recente direttiva 2007/47/CE del 5 settembre 2007. La
succitata direttiva modifica la direttiva 93/42/CEE del Consiglio concernente i
dispositivi medici, in particolare, includendo il software indipendente nella
definizione di dispositivo medico, che risulta essere:
“qualunque strumento, apparecchio, impianto, software, sostanza o
altro prodotto, utilizzato da solo o in combinazione, compreso il software
destinato dal fabbricante ad essere impiegato specificamente con finalità
diagnostiche e/o terapeutiche e necessario al corretto funzionamento del
dispositivo, destinato dal fabbricante ad essere impiegato sull’uomo a fini di:
- diagnosi, prevenzione, controllo, terapia o attenuazione di una
malattia;
- diagnosi, controllo, terapia, attenuazione o compensazione di una
ferita o di un handicap;
- studio, sostituzione o modifica dell'anatomia o di un processo
fisiologico;
- intervento sul concepimento,
la cui azione principale voluta nel o sul corpo umano non sia
conseguita con mezzi farmacologici né immunologici né mediante
metabolismo, ma la cui funzione possa essere assistita da questi mezzi.”
La medesima direttiva sottolinea l’importanza della validazione del
prodotto informatico prescrivendo tra i requisiti essenziali relativi alla
progettazione: “per i dispositivi che incorporano un software o costituiscono
in sé un software medico, il software è convalidato secondo lo stato dell’arte,
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
tenendo conto dei principi del ciclo di vita dello sviluppo, della gestione dei
rischi, della validazione e della verifica.”
Per consentire un graduale adeguamento alle modifiche piuttosto
radicali ed innovative per la legislazione europea gli Stati Membri
dell’Unione Europea dispongono di ancora alcuni mesi (precisamente fino al
21 Dicembre 2008) per adottare e pubblicare le disposizioni legislative,
regolamentari e amministrative al fine di conformarsi alla direttiva. Tuttavia
tali disposizioni si applicheranno a decorrere dal 21 marzo 2010. Al contrario
negli Stati Uniti oltre dieci anni fa la Food and Drug Administration (FDA)
pubblicò un draft dal titolo “General Principles of Software Validation”,
superato nel 2002 con il documento “General Principles of Software
Validation; Final Guidance for Industry and FDA Staff”.
Particolarmente interessante, anche al fine di comprendere gli obiettivi
di questo lavoro di tesi, risulta essere la definizione di validazione fornita
dalla FDA: “confirmation by examination and provision of objective evidence
that software specifications conform to user needs and intended uses, and that
the particular requirements implemented through software can be
consistently fulfilled” (conferma, sostenuta da evidenze oggettive, che le
specifiche del software siano conformi alle necessità degli utenti e agli usi
previsti e che le particolari richieste implementate dal software sia
conformemente soddisfatte). In pratica l’attività di validazione può essere
svolta sia durante l’intero ciclo di sviluppo sia a conclusione per assicurare
che le specifiche del software soddisfino le esigenze degli utenti nonché gli
usi previsti e che il prodotto informatico realizzato sia conforme alle
specifiche. Pertanto la definizione del protocollo di validazione comporta
inevitabilmente uno sforzo di riprogettazione e reingegnerizzazione del
software realizzato o in corso di sviluppo.
Ad ogni modo, sebbene la validazione del software venga condotta da
oltre 20 anni con metodologie consolidate in molti ambiti dell’industria del
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
software, nel settore dell’informatica sanitaria la normativa tecnica non è
ancora completamente assestata ed è in continua evoluzione. Un indiscusso
riferimento per il software medicale è rappresentato dalla norma CEI EN
62304:2006 “Software per dispositivi medici - Processi relativi al ciclo di vita
del software” che purtroppo non tratta della validazione del dispositivo
medico anche nel caso in cui questo è costituito da solo software. Per tanto si
ritiene opportuno riferirsi agli standard internazionali per il software in
generale, ovvero la norma ISO/IEC 9126-1:2001 Software engineering —
Product quality — Part 1 Quality model”1, che usata unitamente alla norma
ISO/IEC 15504, la quale riguarda il software process assessment, può fornire
il supporto per la revisione, verifica e validazione del software.
Inoltre sono in corso due progetti di standard relativamente al risk
management (fase importante per derivare i requisiti di sicurezza del
software): IEC 80001 Ed. 1.0 “Application of risk management to information
technology (IT) networks incorporating medical devices” con pubblicazione
prevista per Luglio 2010 e IEC/TR 80002 Ed. 1.0 “Medical device software Guidance on the application of ISO 14971 to medical device software” con
pubblicazione prevista per Settembre 2009.
In tale contesto di riferimento, non ancora completamente assestato, si è
deciso di definire un protocollo di validazione che miri ad accertare:
o la capacità del software di soddisfare le esigenze degli utenti;
o la conformità del software alla normativa applicabile.
4.2. Il protocollo di Validazione
Al fine di definire il protocollo di validazione, la piattaforma è stata
suddivisa in tre macro-aree, caratterizzate da diversi obiettivi:
o interfaccia per l’acquisizione e la trasmissione, che consente all’utente (
paziente, infermiere o medico, in relazione dello scenario considerato)
Recentemente pubblicata anche in lingua italiana come norma UNI CEI ISO/IEC 9126-1:2007 “Ingegneria
del software - Qualità del prodotto - Parte 1: Il modello di qualità”
1
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
di acquisire e trasmettere dati alfanumerici e segnali in maniera
affidabile e sicura;
o interfaccia per presentazione dei dati clinici, che
ha l’obiettivo di
garantire l’idonea rappresentazione di tutti i dati e i segnali acquisiti
nonché dei risultati del processing dell’ECG e della HRV al fine di
agevolare una corretta diagnosi;
o il web service per il processing dell’ECG e dell’HRV, che offre un
servizio di elaborazione remota e distribuita dell’ECG al fine di estrarre
informazioni che siano significative per i clinici.
4.3. Interfaccia Acquisizione e Trasmissione Dati
L’interfaccia di acquisizione e trasmissione ha come obiettivo primario
l’acquisizione e la trasmissione di dati alfanumerici e segnali biomedici
attraverso la modalità più adeguata alle esigenze dell’utente, garantendo
l’affidabilità, l’integrità e la sicurezza nella trasmissione.
Dal momento che è previsto l’utilizzo di questa interfaccia da parte di
diverse tipologie di utenti, quali pazienti, operatori socio-sanitari, infermieri e
medici, le esigenze risultano essere molteplici e eterogenee. In sintesi, anche
avvalendosi di questionari precedentemente somministrati [], si ritiene che le
esigenze, distinte per varie tipologie di utenti, siano:
o per i pazienti e i loro familiari: acquisizione e trasmissione in maniera
semplice e, per quanto possibile, automatizzata senza l’ausilio a
tecnologie web o PC, con i quali non hanno familiarità,
o per gli infermieri / medici: acquisizione con strumentazione con cui
sono abituati a lavorare.
L’esigenze dei pazienti
Come già specificato nel capitolo precedente, in fase di progettazione e
sviluppo, sono stati implementati tre distinti canali, proprio per soddisfare le
esigenze delle diverse tipologie di utenti.
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
Il primo canale, consente la trasmissione dell’ECG e dei parametri
alfanumerici attraverso una semplice telefonata da rete fissa o cellulare,
quindi conviene all’esigenze di pazienti anziani che non hanno familiarità con
la rete Internet.
Il software che consente l’acquisizione è stato sviluppato
4.4. Web service per il processing dell’ECG e della HRV
Il web service per il processing dell’ECG e della HRV si propone come
obiettivo di fornire informazioni in forma semplice e significativa come
ausilio per la diagnosi clinica.
Il sistema automatico per il processing dell’ECG richiede una
procedura di verifica, che si ritiene opportuno specificare in conformità alla
norma UNI CEN/TS 15127-1:2006 “Informatica sanitaria - Procedure di
verifica (test) del software per le misurazioni fisiologiche - Parte 1:
Generalità”. Infatti tale norma tecnica ha lo scopo di indicare le modalità
attraverso cui specificare un insieme di dati della procedura di verifica (test
data set), documentando la loro generazione e il loro uso in relazione al
software medicale progettato per elaborare dati.
La necessità della verifica deriva da due constatazioni: la consistenza
dei parametri derivati è sempre auspicabile per assistere il medico nelle
procedure di diagnosi clinica; inoltre è vero solo in teoria che lo stesso test
diagnostico eseguito sul medesimo paziente usando diversi dispositivi
produca il medesimo risultato finale, in quanto nella pratica si configurano
problemi di riproducibilità attribuibili a differenze nel protocollo di
acquisizione e/o nel processing dei dati. Proprio questa seconda fase è oggetto
di valutazione con l’impiego di test data set (TDS), opportunamente progettati
per valutare la qualità del software realizzato. Chiaramente il principio alla
base del test è quello di confrontare i valori dei parametri ottenuti dal software
con quelli attesi.
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
In generale il test data set è definito dai seguenti elementi:
o gli array dei dati dei pazienti (che possono essere sia dati clinici reali
che simulati);
o i parametri relativi agli array dei dati;
o le informazioni cliniche rilevanti;
o i dettagli del processing;
o i parametri da calcolare con il processing;
o il range atteso dei parametri;
o il formato dei report
In particolare per verificare l’algoritmo di rilevamento dei QRS e
quindi l’estrazione della serie RR si è progettato il test data set descritto in .
Come array dati si è scelto l’MIT-BIH Normal Sinus Rhythm Database per i
seguenti motivi:
o disponibilità delle cosiddette annotations, ovvero indicazioni in un file
delle occorrenze dei picchi R;
o assenza di significative aritmie e quindi i valori attesi degli intervalli
RR rientrano nel range fisiologico;
o frequenza di campionamento di 128 Hz, che, seppur non rientra nel
range ottimo dei 250-500 Hz, è accettabile ed è confrontabile con la
frequenza di campionamento più bassa dei dispositivi utilizzati (125
Hz);
o impiego in una precedente analisi retrospettiva [1].
Il confronto battito-battito è condotto seguendo le raccomandazioni
dell’Association for the Advancement of Medical Instrumentation[2].
L’elemento fondamentale del report è la tabella con le indicazioni del numero
di falsi negativi (FN) e positivi (FP), della sensitività[2], della predittività
positiva[2] e del detection rate error[3]. I falsi negativi si verificano quando
l’algoritmo non rileva un vero battito rappresentato dall’annotazione nel
database; i falsi positivi (FP) rappresentano la rilevazione di falsi QRS. La
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
sensitività, la positive prediction e il data error rate vengono calcolati con le
seguenti formule:
Sensitività ( Sensitivity ) 
VP
;
VP  FN
VP
;
VP  FP
FP  FN
Tasso di errore ( Data Error Rate) 
.
numero totale di QRS
Pr edittivià positiva ( Positive predictivity) 
dove VP sta per veri positivi ovvero il numero di QRS correttamente
riconosciuti.
Tabella 4.1: Test data set progettato per la verifica dell’algoritmo di riconoscimento
del QRS e dell’estrazione della serie RR
Elemento
Descrizione
array dei dati dei pazienti
MIT-BIH Normal Sinus Rhythm
Database
Parametri relativi agli array dei dati
18 tracciati di durata 20 minuti di
durata campionati a frequenza di 128
Hz.
informazioni cliniche rilevanti
i soggetti sono:
5 uomini con età 26-45;
13 donne con età 20-50.
non presentano significative aritmie
dettagli del processing
Parametri
da
calcolare
specificati nel capitolo precedente
con
il occorrenze dei picchi R e serie degli
processing
intervalli RR
Range atteso dei parametri
i valori attesi degli intervalli RR
rientrano nei range fisiologici.
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
Formato dei report
tracciati
ECG
con
i
picchi
R
riconosciuti;
tabella riassuntiva con indicazione
dei falsi positivi, dei falsi negativi e
della percentuale di errore, per ogni
singolo segnale e in totale;
confronto delle serie degli intervalli
RR come ottenute dalle annotazioni e
dal web service
Analogamente, per verificare l’analisi della HRV è stato progettato test
data set relativamente simile. Gli array dei dati comprendono sia serie RR
estratte Normal Sinus Rhythm RR Interval Database, che serie RR sintetizzate
Elemento
Descrizione
array dei dati dei pazienti
MIT-BIH Normal Sinus Rhythm
Database
Parametri relativi agli array dei dati
Serie RR estratte da 54 tracciati ECG
campionati a frequenza di 128 Hz,
ottenuti da un’analisi automatizzata
con successiva revisione e correzione
manuale
informazioni cliniche rilevanti
i
soggetti
presentano
un
ritmo
sinusale normale:
30 uomini, con età tra i 28.5 e 76;
24 donne, con età tra i 58 e i 73
dettagli del processing
Parametri
da
calcolare
Specificate nel capitolo precedente
con
il I parametri indicati nella tabella
processing
Range atteso dei parametri
I valori attesi secondo linee guida
formato dei report
tabella riassuntiva con indicazione
Capitolo 4 – Definizione del Protocollo per la Validazione della Piattaforma
dei parametri calcolati ed eventuali
valori fuori range evidenziati;
presentazione
ottenute
(segmentazione
delle
dal
dello
immagini
processing
spettro
e
grafico a torta del rapporto LF/HF)
Tuttavia, le procedure di verifica sino ad ora descritte attengono ad una
valutazione tecnica senza alcun riferimento all’efficacia clinica,
J E Mietus, C-K Peng, I Henry, R L Goldsmith and A L Goldberger, “The pNNx files: re-examining a
widely used heart rate variability measure”; Heart 2002;88;378-380
2
Association for the Advancement of Medical Instrumentation, “American National Standard for
Ambulatory Electrocardiographs, publication ANSIlAAMI EC38-1998”, 1998.
3
Xue Q, Hu YH, Tompkins WJ. “Neural-network-based adaptive matched filtering for QRS detection”.
IEEE Trans. Biomed. Eng. 1992;39:315-29.
1