# HealthCam: valutazione dell’analizzatore e fonti Questa nota accompagna il caso studio HealthCam 3.0. I risultati sperimentali provengono dalla precedente tesi HealthCam 2.0: non sono un benchmark della piattaforma attuale o di tutti gli analizzatori. ## Ambito e attribuzione Diego Turri ha sviluppato acquisizione, orchestrazione, integrazione dei servizi, ingestione, analisi dei dati e prodotto web. La sostituibilità degli analizzatori è un obiettivo architetturale. L’analizzatore cardiaco integra pyVHR, framework di ricerca del PHuSe Lab dell’Università degli Studi di Milano legato alla ricerca del relatore. L’analizzatore dei blink usa i landmark di MediaPipe con logica di elaborazione dedicata. Gli algoritmi pyVHR e i modelli MediaPipe non sono stati sviluppati da Diego. - pyVHR: https://github.com/phuselab/pyVHR - Articolo scientifico: https://doi.org/10.7717/peerj-cs.929 ## Metodo La tesi valutava se le stime cardiache da webcam distinguessero differenze tra applicazioni desktop nell’uso quotidiano. Il riferimento era un Polar H10; un sensore Arduino raccoglieva la luminosità ambientale. L’analisi comprendeva allineamento temporale, errore, concordanza e confronti per luminosità. ## Fonti della presentazione Fonte: Diego Turri, “Presentazione Tesi 7.pptx”, presentazione di tesi HealthCam 2.0 fornita dall’autore. - Slide 8: foto storica della postazione. Il sito usa l’immagine già estratta dal corrispondente PDF di tesi; non mostra l’interfaccia attuale 3.0. - Slide 9: correlazioni riportate di 0,09 (MJPG) e −0,01 (lossless). - Slide 10–11: errore assoluto medio di circa 11,6 BPM rispetto a differenze tra app di circa 3 BPM. Il grafico sul sito confronta queste grandezze; non è un test di significatività o un nuovo esperimento. - Slide 15: dati grezzi, GitHub Actions e insight derivati. Le pianificazioni attuali sono state verificate nel codice 3.0, non dedotte dalla vecchia slide. La configurazione valutata non distingueva queste differenze in modo affidabile. È un limite dello stimatore nelle condizioni esaminate, non una prova che tutti i metodi pyVHR falliscano nell’uso reale o che la pipeline software HealthCam non funzioni. Una pipeline funzionante, a sua volta, non dimostra l’accuratezza fisiologica delle misure. ## Riproducibilità Il notebook H10 salvato descrive un’altra esecuzione: MAE 12,07 BPM, RMSE 14,47 BPM e 443 osservazioni abbinate. Non va unito ai dati della presentazione in un unico benchmark. I CSV locali referenziati dal notebook non sono presenti nel checkout esaminato: i risultati numerici originali non sono stati ricalcolati per questa pagina. La demo usa dati sintetici e non è una prova di accuratezza. ## Job dati attuali GitHub Actions pianifica aggiornamenti incrementali ogni cinque minuti e una ricostruzione giornaliera alle 02:10 UTC. La finestra giornaliera parte da due giorni prima dell’ultima data aggregata. Le esecuzioni possono subire ritardi: non è una garanzia di aggiornamento al minuto. Le query sui riepiloghi riducono le scansioni ripetute della telemetria grezza, senza affermare un miglioramento misurato di scalabilità o latenza.