Un nodo ESP32 con un sensore MAX30102 misura frequenza cardiaca e saturazione e pubblica i valori via MQTT in poche righe di codice, ma il datasheet del MAX30102 di Analog Devices dichiara esplicitamente che il sensore “non è un prodotto approvato dalla FDA” e non va usato a fini diagnostici. È lo stesso componente che compare in decine di tutorial di “ossimetro fai-da-te”. La distanza fra quel tutorial e qualcosa che un clinico possa usare per decidere una terapia è quasi tutta regolatoria e di processo, non di codice.

Contesto

Con l’elettronica maker assemblare una catena di telemonitoraggio è banale. Un ESP32 (Wi-Fi e Bluetooth integrati, costo sotto i 10 €) legge un sensore I2C, si connette a un broker MQTT e trasmette campioni a un backend. La libreria PubSubClient su Arduino, un broker Eclipse Mosquitto e un consumer Python con paho-mqtt chiudono la pipeline in una sera. MQTT è uno standard pubblicato: OASIS l’ha rilasciato come MQTT 3.1.1 nel 2014 ed è stato adottato come ISO/IEC 20922:2016. Consumi contenuti, riconnessione automatica e topic gerarchici lo rendono adatto a flotte di nodi a basso costo.

In fase di prototipazione tutto questo è reale e utile. I guai cominciano quando il prototipo viene presentato — o peggio, usato — come se producesse un dato clinico affidabile.

Il problema regolatorio

In Europa, un software o un dispositivo destinato a una finalità medica ricade sotto il Regolamento (UE) 2017/745 (MDR). La finalità medica comprende diagnosi, prevenzione, monitoraggio, previsione e prognosi di una malattia. La guida MDCG 2019-11 del Medical Device Coordination Group chiarisce come qualificare e classificare il software: se la finalità d’uso dichiarata è fornire informazioni usate per prendere decisioni a scopo diagnostico o terapeutico, quel software è un dispositivo medico, che giri su hardware dedicato o su un microcontrollore da 8 €.

Il punto che molti progetti maker saltano è che a determinare l’inquadramento è la finalità d’uso dichiarata, non la tecnologia. Un ESP32 che mostra un numero su un display “a scopo dimostrativo” non è regolato. Lo stesso ESP32 che invia quel numero a una piattaforma su cui un infermiere imposta una soglia di allarme ha una finalità di monitoraggio, e da lì in poi servono fascicolo tecnico, gestione del rischio (ISO 14971), ciclo di vita del software (IEC 62304) e, per la parte elettrica applicata al paziente, la conformità a IEC 60601-1.

Architettura, e dove si rompe

La catena tipica resta:

[ESP32 + MAX30102] --MQTT/TLS--> [Mosquitto] --> [consumer Python] --> [storage + UI]

Per un uso sanitario i punti deboli non sono nel trasporto. MQTT su TLS con QoS 1 dà garanzie di consegna e cifratura accettabili. I problemi stanno agli estremi.

Lato sensore, il MAX30102 è un fotopletismografo a due lunghezze d’onda: legge una forma d’onda, non una misura calibrata di SpO2. Per ricavarne una percentuale di saturazione clinicamente sensata serve una curva di calibrazione validata su soggetti reali, con diversi tipi di perfusione e di pigmentazione cutanea, e un controllo della qualità del segnale che scarti i campioni corrotti da movimento o cattivo contatto. Il datasheet stesso avverte che la lettura risente di posizionamento, movimento e luce ambientale. Senza quella validazione, il numero pubblicato su MQTT è un artefatto da banco.

Lato sistema, manca quasi sempre la gestione del fallimento. Cosa succede quando il nodo entra in deep sleep (l’ESP32 scende sotto i 10 µA, ottimo per durare a batteria) e perde campioni? Cosa succede se il broker è irraggiungibile e i retained message mostrano un valore vecchio come se fosse attuale? In ambito industriale un dato mancante o stantio è una scocciatura. In un contesto di monitoraggio paziente è un rischio, e IEC 60601-1 lo formalizza nel concetto di essential performance: la prestazione la cui perdita, oltre una soglia, genera un rischio inaccettabile.

Punto critico

Fra l’uso industriale e quello sanitario dello stesso identico hardware non cambia la qualità del segnale, cambia la conseguenza di un errore. Un MPU6050 che monitora le vibrazioni di un motore può sbagliare una FFT: si perde un allarme di manutenzione, si pianifica un fermo macchina in più. Lo stesso MPU6050 usato per la fall detection di un anziano, se sbaglia una predizione, produce un falso negativo su una caduta reale, o un falso positivo che erode la fiducia nel sistema fino a farlo ignorare.

Per questo i due domini divergono presto, pur partendo dallo stesso bill of materials. Nell’industria si ottimizzano il costo per nodo e la robustezza meccanica. In sanità il vincolo dominante diventa la tracciabilità della decisione: ogni valore mostrato deve potersi ricondurre a un sensore calibrato, a un firmware versionato, a una catena di custodia del dato. Non è burocrazia aggiunta a posteriori; è ciò che separa una misura da un’opinione numerica.

Implicazioni per chi prototipa

Anche in sanità il prototipo Arduino/ESP32 conserva un valore concreto, a patto di chiamarlo per quello che è: uno strumento per validare un’ipotesi di prodotto, una pipeline dati, un’interazione d’uso. Serve a rispondere a domande come “il paziente riesce a posizionare il sensore senza assistenza?” o “la latenza fra lettura e dashboard è accettabile?”. Sono domande oneste a cui un nodo da 15 € risponde bene.

Diventa pericoloso quando chi guarda la demo le attribuisce l’affidabilità di un dispositivo certificato. La tentazione è forte perché il numero sul display ha lo stesso aspetto. Tenere esplicita la separazione è una disciplina: il PoC misura la fattibilità del flusso, non la grandezza fisiologica. Il passaggio a dispositivo richiede sensoristica con accuratezza dichiarata e validata, isolamento elettrico conforme, gestione del rischio documentata e, se la finalità è medica, marcatura CE secondo MDR.

Limiti

Quanto sopra riguarda la qualificazione regolatoria europea e i sensori ottici di tipo consumer; non copre i casi in cui un componente è venduto già con marcatura CE come dispositivo medico, né le specificità dell’in-vitro (Regolamento (UE) 2017/746). Le soglie numeriche citate per i consumi dell’ESP32 si riferiscono al chip nudo: una scheda di sviluppo con regolatore LDO e bridge USB-seriale consuma ordini di grandezza in più, dettaglio che cambia i conti dell’autonomia a batteria in un device indossabile.

Immagine di copertina: Scheda di sviluppo ESP32 Espressif ESP-WROOM-32 con header a pin maschio su entrambi i lati, vista dall’alto su sfondo neutro — foto di Ubahnverleih, CC0 — https://commons.wikimedia.org/wiki/File:ESP32_Espressif_ESP-WROOM-32_Dev_Board.jpg