Oltre Turing
Un paziente porta al polso un dispositivo indossabile che campiona il ritmo cardiaco a 250 Hz, la saturazione periferica a 1 Hz, l'accelerazione triassiale a 50 Hz. Un algoritmo di classificazione, addestrato su decine di migliaia di tracciati etichettati, segnala con elevata confidenza la presenza di un pattern compatibile con fibrillazione atriale parossistica. Il dispositivo invia un alert alla cartella clinica elettronica. Il medico riceve una notifica. Il paziente - che non avverte nulla - riceve un messaggio di raccomandazione a contattare il proprio cardiologo.
In questa sequenza operativa - ormai routinaria nella pratica clinica dei paesi OCSE - coesistono due entità categorialmente distinte. Il tracciato elettrocardiografico è un segnale: grandezza fisica misurabile, quantizzabile, trasmissibile, archiviabile. La fibrillazione atriale è un sintomo: manifestazione clinica di una condizione patologica, che appartiene al vissuto del paziente, all'anamnesi, al giudizio del medico. L'ingegneria dei dispositivi medici intelligenti - Internet of Medical Things (IoMT), wearable, Software as a Medical Device (SaMD) - vive interamente nel passaggio dal primo al secondo. Ogni architettura, ogni algoritmo, ogni interfaccia è una scelta progettuale su come tale passaggio debba avvenire, con quali garanzie, sotto quale responsabilità.
Questo capitolo ricostruisce tale passaggio dal punto di vista dell'ingegnere che progetta, valida e governa dispositivi sanitari AI-enabled, nella cornice normativa del Regolamento UE 2017/745 (MDR) combinato con il Regolamento UE 2024/1689 (AI Act). Non è una trattazione clinica. È un'analisi ingegneristica dei requisiti non funzionali che la differenza tra σῆμα e σύμπτωμα impone alla pratica progettuale contemporanea.
§1. Il segnale come grandezza misurabile
Un biosegnale - ECG, PPG, EEG, EMG, GSR, dati inerziali da accelerometro e giroscopio - è caratterizzato ingegneristicamente da un insieme di parametri verificabili: frequenza di campionamento (Hz), risoluzione in bit, rapporto segnale-rumore (SNR), banda passante, latenza di acquisizione. Il teorema del campionamento di Nyquist-Shannon fissa il limite inferiore della frequenza di acquisizione a due volte la massima componente spettrale di interesse. La catena di acquisizione è, in linea di principio, interamente progettabile: sensore, front-end analogico, filtraggio anti-aliasing, conversione analogico-digitale, pre-processing, compressione, trasmissione.
Nei dispositivi indossabili contemporanei - smartwatch clinicamente validati, patch ECG monolead, cerotti intelligenti, sensori PPG ottici - la catena è miniaturizzata e distribuita. Il sensore è al polso, al torace, al dito. L'elaborazione di prossimità - edge computing - filtra, comprime, estrae feature elementari. La trasmissione verso il gateway (tipicamente un dispositivo mobile) avviene via Bluetooth Low Energy o protocolli proprietari a basso consumo. Il backend cloud consolida, archivia, analizza, serve modelli predittivi.
Le metriche ingegneristiche rilevanti sono codificate in standard consolidati. La IEC 60601-2-47 disciplina i requisiti di sicurezza e prestazione per sistemi elettrocardiografici ambulatoriali. La IEEE 11073 definisce l'interoperabilità semantica dei dispositivi medici personali. La ISO/IEEE 11073-10101 fornisce il nomenclatura standard per la terminologia clinica. La HL7 FHIR - in particolare le risorse Observation, Device, DeviceMetric - struttura lo scambio semantico tra dispositivo e sistema informativo sanitario.
Fin qui il segnale è, a tutti gli effetti, un artefatto ingegneristico neutro. Un vettore numerico, una traccia temporale, un file EDF o MFER. La sua natura cambia nel momento in cui attraversa la frontiera che lo trasforma in informazione clinicamente azionabile. Quella frontiera è, simultaneamente, un'interfaccia software e una soglia di responsabilità.
§2. Il sintomo come categoria clinica irriducibile
Il sintomo appartiene a un ordine diverso. Nella semeiotica medica classica - da Ippocrate a Laennec, fino alla medicina basata sull'evidenza contemporanea - il sintomo è ciò che il paziente riferisce (manifestazione soggettiva), mentre il segno clinico è ciò che il medico osserva (manifestazione oggettiva rilevabile all'esame). Il biosegnale catturato dal wearable occupa uno spazio epistemologicamente intermedio: è misurazione fisica oggettiva, ma non è ancora segno clinico - perché diventa tale solo attraverso l'atto interpretativo del medico, nel contesto dell'anamnesi, della storia clinica, del colloquio con il paziente.
Questa distinzione non è pedanteria filosofica: è architettura di sistema. Un classificatore che emette l'etichetta «fibrillazione atriale parossistica rilevata» non sta producendo una diagnosi - sta producendo un'evidenza probabilistica che richiede conferma diagnostica. La confusione semantica tra queste due operazioni è una delle cause più frequenti di errore clinico nei sistemi AI-enabled: l'automation bias, documentato ampiamente nella letteratura sui sistemi di supporto decisionale (Goddard et al., 2012; Lyell e Coiera, 2017), è la tendenza dell'operatore umano a sovra-affidarsi all'output algoritmico, anche quando la confidenza dichiarata è modesta.
La mitigazione architetturale di questa asimmetria richiede che il dispositivo comunichi al medico non solo l'etichetta, ma almeno quattro informazioni quantificate: la probabilità posteriore associata alla classe; l'intervallo di confidenza di tale probabilità; la presenza o assenza di fattori di out-of-distribution rispetto alla popolazione di training; la tracciabilità dei dati che hanno contribuito alla predizione (attention maps, SHAP values, counterfactual explanations). Tutte e quattro sono oggi oggetto di standardizzazione attiva - in particolare nelle linee guida FDA sul Good Machine Learning Practice for Medical Device Development (2021), nei requisiti ISO/IEC 23894 (AI risk management, 2023) e nella ISO/IEC 42001 (AI management system, 2023).
Il sintomo, nel senso pieno, non è il classificatore che lo rileva - è l'esperienza del paziente, contestualizzata dal medico, confermata da accertamenti. Il dispositivo intelligente serve questo processo: non lo sostituisce.
§3. Architetture IoMT e classificazione di rischio
L'ecosistema Internet of Medical Things si articola su un'architettura stratificata ormai consolidata. Al livello edge operano i dispositivi terminali: wearable di primo livello (attività fisica, sonno, frequenza cardiaca), wearable clinicamente validati (ECG monolead, SpO₂ clinical grade), dispositivi impiantabili (pacemaker, loop recorder, pompe insuliniche), sensori ambientali (qualità dell'aria indoor, temperatura, umidità per pazienti fragili). Al livello fog - gateway domestici, smartphone, hub ospedalieri - avviene la prima aggregazione, la crittografia end-to-end, il buffering per garantire continuità in caso di interruzione della connettività. Al livello cloud risiedono lo storage longitudinale, i modelli AI, i sistemi di decision support, l'integrazione con la cartella clinica elettronica.
Ciascuno di questi livelli è soggetto a un quadro normativo specifico. Il dispositivo fisico ricade sotto il Regolamento UE 2017/745 (MDR): classificazione di rischio (I, IIa, IIb, III) secondo le regole dell'Annex VIII; marcatura CE; clinical evaluation ai sensi dell'Annex XIV; post-market clinical follow-up. Per i dispositivi software - MDCG 2019-11 chiarisce la qualificazione di SaMD e ne stabilisce la classificazione. Un algoritmo che fornisce raccomandazioni terapeutiche o diagnostiche in contesti che possono determinare trattamenti critici o alterazioni dello stato clinico ricade tipicamente in classe IIa o superiore.
Il Regolamento UE 2024/1689 (AI Act) si sovrappone al MDR nei casi in cui il dispositivo integri componenti AI. L'art. 6(1) in combinato disposto con l'Annex III classifica come sistemi ad alto rischio i dispositivi medici AI-enabled (qualora già soggetti a valutazione di conformità di terza parte secondo normative settoriali armonizzate, tra cui il MDR). Ciò comporta requisiti aggiuntivi: risk management system (art. 9), data governance sui dataset di training-validation-test (art. 10), documentazione tecnica (art. 11), logging automatico (art. 12), trasparenza verso l'utilizzatore professionale (art. 13), human oversight (art. 14), accuratezza, robustezza e cybersicurezza (art. 15).
La duplicazione non è ridondanza: è stratificazione. Il MDR tutela la sicurezza clinica del dispositivo come manufatto; l'AI Act tutela l'integrità del processo decisionale algoritmico. Il fabbricante deve orchestrare entrambe le conformità - tipicamente entro un sistema di gestione qualità ISO 13485, un processo di risk management ISO 14971, un ciclo di vita software IEC 62304, un sistema di gestione AI ISO/IEC 42001. Il risultato, a regime, è un dossier tecnico il cui perimetro di accountability è interamente verificabile.
§4. Dall'acquisizione alla decisione: la pipeline clinica governata
La pipeline che trasforma un biosegnale grezzo in una decisione clinicamente rilevante attraversa, in ordine, sette stadi verificabili. Acquisizione: sensore conforme, calibrazione tracciabile, timestamp sincronizzato. Pre-processing: filtraggio, denoising, rimozione di artefatti (motion artifacts, baseline wandering, interferenza di rete). Feature extraction: estrazione di parametri temporali, spettrali, non lineari (RR intervals, HRV, QT interval, spectral entropy, sample entropy). Inferenza modellistica: applicazione del classificatore o del regressore addestrato, produzione dell'output probabilistico. Calibrazione dell'incertezza: conformal prediction, ensemble disagreement, calibrazione bayesiana dell'output. Presentazione al clinico: interfaccia che espone etichetta, confidenza, spiegazione locale, possibilità di interrogazione controfattuale. Decisione e documentazione: il medico conferma, modifica o rigetta l'output; la decisione viene registrata nella cartella clinica elettronica con traccia completa.
Ciascuno stadio ha metriche ingegneristiche specifiche e, al contempo, rilevanza clinica asimmetrica. Una degradazione del SNR a monte non compromette soltanto le prestazioni numeriche del classificatore - modifica la fiducia epistemica che il clinico può legittimamente riporre nell'output. Un drift di distribuzione tra training e deployment non è solo un problema statistico - può corrispondere a sottopopolazioni cliniche sistematicamente meno rappresentate (bias di campionamento per età, sesso, etnia, comorbidità), con implicazioni dirette sull'equità del trattamento ricevuto. La letteratura ha documentato estesamente questi effetti (Obermeyer et al., 2019, sul bias algoritmico in population health management; Seyyed-Kalantari et al., 2021, sul differential performance di classificatori di imaging per sottopopolazioni demografiche).
L'implicazione progettuale è che il monitoraggio post-market non è un'attività di manutenzione accessoria - è parte integrante del sistema. L'art. 61 del MDR e l'art. 72 dell'AI Act prescrivono, rispettivamente, post-market surveillance plan e post-market monitoring system. In termini ingegneristici, questo significa: telemetria continua delle metriche di performance stratificate per sottopopolazione; drift detection automatizzato con soglie quantitative e alert definiti; re-training pianificato con gate di qualità espliciti; incident reporting tracciabile end-to-end verso l'autorità competente. Il ciclo di vita del dispositivo AI-enabled è, a regime, un ciclo di governance continua.
§5. Il resto clinico
Nessuna architettura IoMT, nessuna calibrazione bayesiana, nessuna spiegazione XAI esaurisce il paziente. Il biosegnale misura una grandezza fisica, non una persona; il classificatore etichetta una classe, non una biografia; il sistema di supporto decisionale informa una scelta, non la compie. La decisione clinica - quella che stabilisce se intervenire, come intervenire, quando intervenire, tenendo conto delle comorbidità, della storia personale, delle preferenze del paziente, del contesto familiare e sociale - resta un atto medico, iscritto nella relazione di cura, non derivabile da alcun modello.
L'ingegneria clinica matura non cerca di ridurre questo resto: lo struttura. Lo inscrive nelle procedure operative standard come momento esplicito di validazione umana; lo dimensiona nelle interfacce come spazio cognitivo tutelato per la deliberazione medica; lo protegge nei workflow come punto di non bypass algoritmico. La sorveglianza umana dell'art. 14 AI Act, quando calata nel dominio clinico, non è una concessione di cortesia: è una specifica funzionale che attraversa l'intero stack tecnologico.
Da qui la maturità dell'approccio contemporaneo sincretico tra Digital Health ed Evidence-Based Medicine: il dispositivo intelligente non ambisce a sostituire il giudizio clinico, ma a renderlo più informato, più tempestivo, più equo, più tracciabile. Il biosegnale espande la finestra temporale di osservazione - dalle ore trascorse in ambulatorio ai giorni, settimane, mesi di monitoraggio continuo. L'algoritmo estrae pattern che l'occhio umano non coglie. L'infrastruttura cloud consolida dati che sarebbero altrimenti dispersi. Ma la lettura clinica - l'atto che inscrive il dato nel senso di una persona - resta prerogativa irriducibile del medico, in dialogo con il paziente.
Un sistema IoMT progettato con questa consapevolezza non è meno potente - è meglio collocato. Sa cosa misura, sa cosa non misura, sa dove finisce la propria competenza e comincia quella clinica. Questa coscienza ingegneristica dei propri confini non indebolisce la tecnologia sanitaria: la rende credibile, deployabile, sostenibile. Non è un'ingegneria timida: è un'ingegneria matura.
Il segnale si può campionare. Il sintomo si deve ascoltare. Il biosegnale è la grandezza; il sintomo è la persona che la abita. Un dispositivo medico intelligente che riconosce questa distinzione non è meno efficace - è meglio progettato. E una medicina che non dimentica questa distinzione non è meno tecnologica - è più vera. Ciò che le grandi tradizioni chiamano custodia del malato, l'ingegneria lo chiama architettura: due lingue - questo libro le farà incontrare a ogni capitolo - per lo stesso dovere.