HRV con Theremino

Ciao ragazzi.

Sto facendo alcune prove con il file RR ottenuto da Theremino ECG, e qualcosa non mi convince, ma non riesco a capire cosa.
Purtroppo, non ho ancora modo di collegare degli elettrodi, e solo uno dei file di esempio di Theremino ECG ha una durata maggiore di 5 minuti.

Nel frattempo, ho ragionato sull’ultimo intervento di Livio di Theremino.
Alla prima lettura, non mi era chiaro il motivo per il quale l’analisi successiva del tracciato produca tempi RR diversi da quelli dell’analisi in tempo reale.
Ma poi mi sono chiesto come farei io per estrarre questi dati, ed ho ipotizzato una risposta.
L’istante esatto del ciclo cardiaco al quale attribuire il punto del tempo al quale riferirsi nel calcolo del periodo RR è localizzato, secondo la letteratura, nel picco più alto della forma d’onda, che viene appunto denominato R.
Immagino che la determinazione di questo punto venga fatta dal software analizzando tutte le letture precedenti, e facendo un auto-set di un trigger al valore più prossimo alla media di quelli letti in precedenza.
Questo implica, tra l’altro, la necessità di analizzare inizialmente un certo numero di battiti prima di poter iniziare ad estrarre i tempi RR.
Ovviamente, un set del trigger molto vicino al massimo delle letture è più preciso nella determinazione del tempo, ma potrebbe non attivarsi con letture di ampiezza un pochino inferiore, saltando così dei battiti e inficiando gravemente la bontà della lettura totale.
Se invece impostiamo il trigger troppo basso, il riconoscimento del punto massimo del picco R si sposta indietro nel tempo, in quanto viene localizzato prima del punto più alto del picco.
Se questo è il metodo attualmente utilizzato, è chiaro che i parametri per l’impostazione automatica del punto di trigger possono essere solo quelli precedenti nel tempo reale, mentre ci si può riferire alla totalità delle letture (quindi comprendendo anche quelle successive) nell’analisi pre-processo del file con i dati RAW (penso che possiamo definire in questo modo il file di Theremino ECG che permette di riprodurre l’intero grafico delle forme d’onda).
In prima battuta, concordo con Livio quando dice che l’impiego dell’analisi di tutte le ampiezze prima dell’estrazione dei dati RR possa consentire un miglioramento globale della precisione delle durate RR.
Ma se ci ragiono con più attenzione, mi rendo conto che il tracciato potrebbe essere affetto da variazioni di ampiezza durante il periodo di acquisizione dei dati.
Il motivo più banale, e forse più probabile, è la variazione di conduttività del contatto tra elettrodi e pelle, a seguito di movimenti del soggetto, ma non possiamo escludere variazioni di ampiezza della forma d’onda indotte dal sistema stesso che stiamo osservando.
Anzi, potrebbe anche essere interessante fare una valutazione statistica delle variazioni di ampiezza in riferimento alle misure HRV.
Ovviamente, questo tipo di valutazione sarà difficilissimo, dato il legame strettissimo tra i due valori, almeno finché utilizziamo un trigger di ampiezza per valutare il picco R.
Sto pensando (e forse è lo stesso pensiero di Theremino) a un metodo diverso.
Anziché riferire il trigger a un valore di ampiezza, perché non riferirlo a un valore di derivata del segnale?
Si potrebbe estrarre la media dei valori massimi precedenti, e in questo modo creare un range di auto trigger relativamente ampio (comunque più ampio dei valori minimi e massimi dei picchi precedenti), entro il quale fare un’ulteriore analisi della derivata del segnale, e in questo modo localizzare esattamente il punto nel quale la forma d’onda ha derivata 0, ovvero localizzare la cresta dell’onda.
Il primo filtro riferito ai valori di ampiezza permette di escludere dal calcolo della derivata quelle parti della forma d’onda diverse dal picco R.
Questo sistema ha un difetto: la sua precisione dipende direttamente dal numero di campioni al secondo con il quale vengono acquisiti i dati RAW, per cui potrebbero non esistere due campioni appartenenti al un punto della curva con derivata 0.
Una alternativa potrebbe essere quella di localizzare due punti di derivata leggermente diversa da 0, uno prima e uno dopo il picco massimo, e calcolare l’istante R in mezzo tra le due letture.
Mi rendo conto che un sistema di questo tipo richiede parecchio calcolo e molta programmazione, e penso che valga la pena di approfondire per capire se abbiamo davvero bisogno di questa precisione.
Il prossimo passo è la compilazione a mano di alcuni file di dati RR, simulando diverse situazioni standard e inserendo errori di misura di 5 ms o meno, per vedere di quanto cambiano i risultati in Kubios.

Vi lascio un nuovo link molto interessante.
https://www.biot.it/images/pdf/Dossier-HRV-e-ambiti-applicativi.pdf

Ciao
Maurizio

Ciao Lorenzo.
Non avevo ancora indagato sui prezzi, ma da quanto dici capisco che la mia intuizione era giusta.
L’analisi del file RAW e la conseguente estrazione dei tempi RR è un punto critico, ed è molto importante per noi capire di quale precisione abbiamo bisogno.
Penso che risoluzioni al di sotto dei 2 ms siano difficili da raggiungere con precisione scientifica, anche lavorando con micro programmati appositamente, e sono convinto che i prodotti commerciali che usano interfacce acquisite con app da cellulare garantiscano tempi e precisioni inferiori.
Questo non significa che una maggiore precisione non sia utile per fare la differenza tra un giocattolo e uno strumento professionale.
Non concordo invece sulla tua affermazione relativa gli errori sistematici, perché in realtà questi errori sarebbero legati ai tempi e alle ampiezze, quindi per nulla ripetitivi.
L’elevazione al quadrato dei tempi RR in realtà non l’ho ancora capita. Il Kubios acquisisce valori in secondi con risoluzione in ms.
Mentre resto in attesa dei tuoi aggiornamenti teorici, faccio qualche prova pratica con l’acquisizione dei file da parte di Kubios.

Ciao Livio.
Come ho già scritto, non sappiamo ancora di quale livello di precisione abbiamo bisogno.
Di certo, la rigorosità dell’acquisizione dei tempi RR è la chiave per ottenere risultati scientificamente attendibili anziché oroscopi.
Quindi, ben venga un tuo impegno per il miglioramento della conversione del file RAW in tempi RR, ma prima di lavorare duramente per ottenere precisioni al millisecondo, accertiamoci della effettiva necessità.
Per quanto riguarda il rumore sulla sommità della forma d’onda, penso che l’unico metodo affidabile sia il filtraggio, soprattutto hardware, per ridurre il rumore elettrico (ad esempio un filtro passa basso), e poi affidarsi a Kubios per eliminare gli artefatti.
Non dico questo perché io abbia una particolare simpatia per Kubios, ma da quello che ho letto è considerato un programma super partes, quindi possiamo prenderlo inizialmente come riferimento per verificare se i nostri futuri programmi di analisi sono affidabili.

Buongiorno Lorenzo e Livio.

Per motivi di tempo non ho ancora letto il primo link, ma ho letto di fretta il secondo perché ero contento di aver pensato da solo a un sistema che ha interessato un ricercatore universitario che ha pubblicato su una rivista scientifica.
Se ho ben capito con la veloce letture, in apparenza il mio sistema è molto simile, ma diverso nel modo di identificare il picco R.
Lui squadra il segnale, e poi analizza le pendenze per distinguere il picco R dal picco T. Non capisco esattamente consa intende, dovrei mettermi a leggere con attenzione la flow chart e le formule contenute.
Il mio metodo utilizza la differenza di ampiezza di due campioni (o quattro, ma questo è un dettaglio probabilmente ininfluente) per ottenere una valore di derivata da utilizzare per localizzare con precisione il picco.
Anche io, come lui, mi ero fatto inizialmente delle domande sull’impiego delle risorse delle CPU per l’analisi, temendo che una complessità di calcolo potesse influire sui risultati.
Ma poi non ho citato, nel mio intervento, questo particolare, in quanto mi sono reso conto che non è affatto necessario fare l’analisi RR in real time.
Anzi, la configurazione con un dispositivo che fa il log e un altro che analizza il file ottenuto è molto più logica ed efficiente dal punto di vista della precisione.
In questo caso, il logger deve fare bene solo il suo lavoro di logger, memorizzando la forma d’onda con una frequenza di campionamento il più possibile elevata, che dovremo calcolare in modo da avere un dettaglio sufficiente ma senza esagerare raccogliendo dettagli inutili.
Bisogna considerare che alla fine dei conti, con il metodo che sto proponendo, oltre un certo limite un aumento del dettaglio di campionamento non introduce un reale aumento della precisione di localizzazione del punto R, in quanto la determinazione non è legata alla effettiva ampiezza del segnale, ma solo al suo comportamento nel tempo, che può essere determinato anche con un numero di campioni relativamente modesto.
Il passo successivo di analisi del file viene fatto utilizzando tutto il tempo che occorre.
Il software di analisi può fare tranquillamente più passate sui dati del file, ottenendo progressivamente:
– i valori di ampiezza massimi
– la media dei massimi
– il range entro il quale considerare i massimi come appartenenti all’insieme delle zone di onda R
– i punti appartenenti a queste zone di onda che hanno derivata prossima a 0 (oppure precedenti e successive a 0)

Questo approccio si presta ad ulteriori sviluppi, seguendo una strada diversa e più impegnativa dal punto di vista del calcolo.
L’analisi continua della derivata di tutti i punti, comparata con le relative ampiezze, permette di identificare con buona precisione non solo il picco R, ma anche qualunque altro punto della forma d’onda, e permette anche di riconoscere forme d’onda non standard.

Vi aggiornerò sui miei progressi

Ciao
Maurizio