L'IA ha scartato una paziente idonea perché non sapeva distinguere una cateterizzazione cardiaca da una linea endovenosa

Il primo paziente che abbiamo perso, lo abbiamo perso per una parola.

Un trial di Fase III su un anticoagulante che stavamo pilotando escludeva chiunque avesse subito una "cateterizzazione cardiaca". Ragionevole: è una procedura cardiaca con rischio emorragico, esattamente il tipo di anamnesi che squalifica una persona da uno studio su un fluidificante del sangue. Il nostro sistema di matching ha segnalato una candidata come non idonea ed è andato avanti. Pulito. Sicuro. Sbagliato.

La paziente non aveva mai subito una cateterizzazione cardiaca. La sua cartella conteneva una nota su un "posizionamento di catetere venoso centrale": una linea endovenosa inserita in una vena in terapia intensiva perché potesse ricevere i farmaci. Procedura diversa. Parte del corpo diversa. Profilo di rischio del tutto diverso. Per un'infermiera, non sono lontanamente confondibili. Per l'IA che avevamo costruito, "catetere" più "venoso" più un contesto dal suono cardiovascolare risultava una quasi-corrispondenza, e una donna idonea è silenziosamente uscita dall'imbuto.

Voglio raccontarvi come sono arrivato a passare buona parte di un anno ossessionato da quell'unica paziente scartata, perché mi ha insegnato la cosa che nessuno di chi vende IA per il reclutamento nei trial clinici vuole dire ad alta voce: il problema nel matching dei pazienti non è mai stato trovare abbastanza persone. È che le macchine che eseguono il matching leggono parole, e l'idoneità a un trial riguarda concetti medici — e non sono la stessa cosa.

L'80% dei trial non rispetta i tempi di arruolamento. Il settore continua a trattarlo come un problema di offerta. È un problema di precisione.

L'errore che ho commesso per primo

Lo ammetto subito, perché è il punto attorno a cui ruota tutta la storia. Quando abbiamo iniziato, ero tra coloro che credevano che la questione fosse sostanzialmente risolta.

Il ragionamento era questo. Per anni, il matching dei trial si basava sulla ricerca per parole chiave: rozza, fragile, penosa. Poi sono arrivati i large language model, e all'improvviso il software poteva leggere una nota medica non strutturata come fa una persona. Ho guardato tutto ciò e ho concluso che la parte difficile fosse alle nostre spalle. Avremmo preso un modello potente, gli avremmo dato in pasto i criteri di idoneità e le cartelle dei pazienti, messo a punto i prompt, e il matching avrebbe semplicemente funzionato. Ne ero convinto. Ho detto al mio team che il divario rimasto da colmare era piccolo, una questione di retrieval migliore e di prompting più accurato.

Abbiamo costruito quel sistema. Nelle demo era splendido. Sui casi facili — la paziente che ha chiaramente un cancro al seno in stadio II, il criterio che dice chiaramente "nessuna chemioterapia pregressa" — era davvero valido. I numeri che vedete nelle presentazioni dei fornitori provengono esattamente da questi casi. Tempus, dopo aver acquisito Deep 6 AI all'inizio del 2025 ed essersi espansa a oltre 750 siti clinici, riferisce che il suo agente Patient Query raggiunge il 94.39% di accuratezza su un insieme di query valutate. Quel numero è reale. Ci credo. Ma misura anche i casi che non sono mai stati il problema.

La paziente della cateterizzazione è stata il momento in cui la mia versione del sistema è morta. Me ne stavo lì a ricostruire perché fosse stata scartata, aspettandomi un bug. Non c'era alcun bug. Il sistema aveva fatto esattamente ciò che fa la similarità vettoriale — valutare due stringhe in base a quanto sono vicine nello spazio semantico — e due procedure che condividono la parola "catetere" stanno davvero molto vicine. Nessuna quantità di prompt engineering avrebbe potuto insegnargli che una rientra sotto "procedura sul cuore" e l'altra sotto "cateterizzazione di una vena". Non aveva un concetto del cuore. Aveva soltanto parole sul cuore.

Perché i language model confondono i termini medici?

Ecco la distinzione che ha riorganizzato il mio modo di pensare a questo intero settore.

Quando un clinico legge "posizionamento di catetere venoso centrale", non elabora cinque token. Recupera un concetto — un nodo specifico in una vasta gerarchia strutturata di conoscenza medica, con genitori, figli e fratelli, con una collocazione precisa che dice: questa è una procedura di accesso vascolare, non una cardiaca. Quella gerarchia esiste davvero, formalmente, come ontologia clinica chiamata SNOMED-CT. Al suo interno, la cateterizzazione cardiaca è il concetto con ID 41976001, catalogata tra le procedure sul cuore. La cateterizzazione venosa centrale è 392230005, catalogata tra le cateterizzazioni di una vena. Due rami diversi dell'albero. Un sistema che ragiona sull'albero non può confonderle. Un sistema che ragiona sulla prossimità delle parole le confonde di continuo.

Non è una stranezza in cui mi sono imbattuto per conto mio. Valutazioni pubblicate hanno documentato modelli di IA che commettono esattamente questo errore del tipo "cateterizzazione cardiaca uguale puntura venosa centrale" (Fierce Biotech, 2025). Rappresenta un'intera classe di fallimenti — ovunque procedure, condizioni o farmaci condividano il vocabolario ma divergano dal punto di vista medico. Angiografia coronarica e angiografia periferica. Condividono "angiografia". Una è una procedura cardiaca; l'altra è un accesso vascolare. Un language model le valuta come cugine. L'ontologia sa che sono estranee.

Ora moltiplicate tutto ciò per i criteri di un intero protocollo, su un portafoglio di trial, e non avete più un caso limite. Avete una fuga sistematica di idoneità che opera silenziosamente sullo sfondo di ogni matcher probabilistico del settore.

Un language model sa che "catetere" compare vicino a "cardiaco". Non ha idea che uno sia una procedura cardiaca e l'altro una linea endovenosa. È in quel divario che scompaiono i pazienti idonei.

Le clausole di eccezione che hanno fatto crollare tutto due volte

Una volta che ho iniziato a guardare, il divario tra parola e concetto si è rivelato solo la prima crepa.

Un'altra si annida nella grammatica stessa dell'idoneità. I protocolli reali non dicono "escludere l'ipertensione". Dicono "escludere i pazienti con ipertensione a meno che non sia ben controllata con farmaci stabili da tre o più mesi". Quella frase non è una parola chiave — è una condizione con una finestra temporale sepolta al suo interno. Ho visto il nostro primo sistema gestire quella clausola in due modi, entrambi sbagliati. A volte vedeva "ipertensione" ed escludeva il paziente, perdendo qualcuno che in realtà era idoneo. A volte lo lasciava passare saltando completamente il controllo dei tre mesi. Non ha mai fatto in modo affidabile ciò che un coordinatore fa senza pensarci: trattenere l'eccezione, poi verificare la durata.

Questo conta sempre di più ogni anno, perché i protocolli stanno diventando barocchi. Il numero mediano di criteri di idoneità nei protocolli oncologici è cresciuto grosso modo da 17 di una generazione fa a 27 nella coorte più recente, e il numero di procedure per protocollo è aumentato del 139% dal 2005 (IQVIA). Ogni "a meno che", "eccetto" e "entro sei mesi" è un punto in cui un word-matcher tira silenziosamente a indovinare. E quando arrivano gli emendamenti — l'emendamento medio ora richiede 260 giorni per essere implementato (Applied Clinical Trials, 2025) — ogni ipotesi va rifatta da capo.

Il fallimento che però mi ha davvero spaventato era diverso — toccava la possibilità stessa di difendere questo lavoro davanti a un ente regolatore. Fate passare lo stesso paziente attraverso un matcher basato su un language model due volte, con un contesto circostante leggermente diverso, e potete ottenere due risposte diverse. Per la maggior parte del software, un po' di non determinismo è tollerabile. Per un trial clinico, è squalificante. Un ente regolatore non vuole una probabilità che un paziente fosse idoneo. Vuole la ragione esatta e riproducibile per cui ogni persona è stata inclusa o esclusa — una traccia che possa leggere riga per riga. Un sistema che potrebbe decidere diversamente di martedì non può produrre quella traccia.

Ciò che avrei dovuto costruire fin dall'inizio

La ricostruzione non è stata sottile. Abbiamo smesso di cercare di far comportare in modo deterministico un sistema probabilistico e abbiamo costruito un sistema deterministico per costruzione.

La sua spina dorsale è l'ontologia. Mappiamo ogni termine nella cartella di un paziente e ogni termine nei criteri di idoneità sul rispettivo concetto SNOMED-CT — così il matcher confronta nodi in una gerarchia medica, non stringhe. La cateterizzazione cardiaca e la cateterizzazione venosa centrale smettono di essere vicine e diventano ciò che sono: parenti lontane su rami separati. La paziente della cateterizzazione, fatta passare attraverso questo sistema, torna idonea. Correttamente. Ogni volta.

Sopra l'ontologia abbiamo posto una logica esplicita per le parti in cui i language model inciampano — l'"a meno che", l'"eccetto", l'"entro tre mesi". Quel tipo di ragionamento è in realtà l'unione di due discipline: la logica deontica per modellare la struttura di obbligo ed eccezione di una clausola "a meno che", e il ragionamento sugli intervalli temporali per valutare "entro tre mesi" rispetto alle date effettive presenti nella cartella. Nessuno dei due è riconducibile a pattern-matching; entrambi devono essere modellati esplicitamente. E poiché ogni decisione è una catena di passaggi espliciti su concetti nominati, il sistema produce esattamente l'artefatto che gli enti regolatori desiderano: una traccia di audit riproducibile che mostra con precisione quale concetto ha corrisposto a quale criterio e perché un paziente è finito dove è finito.

Tengo a precisare neuro-simbolico, non "abbiamo buttato via i language model". Non l'abbiamo fatto. Sono eccellenti nel primo passaggio caotico — leggere una nota clinica prolissa ed estrarne un significato strutturato dalla prosa. Lasciamo che facciano questo. Semplicemente non li lasciamo essere i giudici dell'idoneità. La lettura è probabilistica; il ragionamento è deterministico. Quella divisione del lavoro è l'intero progetto.

Questo è il sistema che ora costruiamo per gli sponsor farmaceutici, le CRO e i centri medici accademici, ed è ciò a cui il nostro lavoro di IA per il reclutamento nei trial clinici è dedicato — matching personalizzato che ragiona sui grafi dell'ontologia SNOMED-CT con logica deterministica, anziché l'ennesimo scorer probabilistico.

Perché le grandi piattaforme non l'hanno semplicemente costruito?

Questa è la domanda che mi pone ogni sponsor, ed è legittima. Tempus, IQVIA, Medidata, ConcertAI, TriNetX — sono aziende serie con enormi quantità di dati. Perché nessuna di esse ha semplicemente costruito la versione fondata sull'ontologia?

Parte della risposta è che stanno ottimizzando per un obiettivo diverso, ed è un obiettivo ragionevole. IQVIA ha presentato IQVIA.ai, una piattaforma agentica unificata costruita con NVIDIA, a marzo 2026, poggiante su oltre 250 milioni di cartelle di pazienti. TriNetX gestisce una rete federata di scala analoga per il lavoro di fattibilità e sulle coorti. ConcertAI ha lanciato la sua piattaforma agentica Accelerated Clinical Trials a febbraio 2026, dichiarando riduzioni delle tempistiche da 10 a 20 mesi. AI Study Build di Medidata integra il matching nel suo sistema di acquisizione elettronica dei dati Rave in centinaia di studi. Ognuna di queste è reale e valida in ciò a cui punta — ampiezza, scala, flusso di lavoro end-to-end.

Sotto tutte loro c'è anche un divario più silenzioso. Anche quando una piattaforma esegue bene il matching, l'output di solito arriva come un elenco che un coordinatore poi reinserisce manualmente nel sistema di gestione dei trial ufficiale — Rave, Veeva Vault, Oracle Clinical One. Il matching e il sistema che gestisce lo studio in realtà non comunicano, quindi un passaggio manuale persiste esattamente dove vorreste che l'automazione fosse più stretta.

Ma ampiezza e profondità ontologica tirano in direzioni opposte. Una piattaforma che serve ogni area terapeutica alla scala di 250 milioni di cartelle è costruita per essere genericamente valida, e il genericamente valido è precisamente dove vive la classe di errori della cateterizzazione. Il ragionamento profondo e consapevole dei rami di cui ha bisogno un protocollo complesso di oncologia, malattie rare o SNC è costoso da costruire e costoso da mantenere — SNOMED si aggiorna due volte l'anno, il dizionario degli eventi avversi MedDRA si aggiorna trimestralmente, e mantenere aggiornata un'ontologia è personale fisso, non un progetto una tantum. È il genere di ingegneria poco appariscente e mai conclusa che una piattaforma in corsa verso l'ampiezza tende a rimandare.

Le piattaforme non hanno torto. Stanno risolvendo il problema della scala. La precisione ontologica è un problema diverso, ed è quello che decide se i vostri pazienti idonei vengono effettivamente trovati.

L'altra risposta onesta è la gravità dei dati. Diverse di queste piattaforme eseguono il matching al meglio all'interno della propria rete — i loro dati, i loro siti. Se i vostri pazienti risiedono nella vostra cartella clinica elettronica, dietro il vostro firewall, si tratta di un'implementazione completamente diversa. E molti sponsor e ospedali, per ottime ragioni legate all'HIPAA, non invieranno le cartelle dei pazienti nel cloud di qualcun altro per il matching.

Il costo che nessuno mette sulla slide

Lasciate che renda concreta la posta in gioco, perché gli aspetti umani e finanziari di tutto ciò sono facili da astrarre via.

Dal punto di vista finanziario: un giorno di ritardo in un trial costa una stima di $800,000 in vendite di prescrizioni perse (Tufts CSDD), e per alcune aree terapeutiche è molto peggio — i ritardi cardiovascolari arrivano a circa $1.4 milioni al giorno. Ogni fallimento di screening costa in media circa $1,200, e i tassi di fallimento dello screening vanno da un minimo del 20% a un massimo dell'80% a seconda dell'indicazione, raggiungendo picchi dell'88% nei trial sull'Alzheimer. La paziente della cateterizzazione — quella idonea che abbiamo scartato — è puro spreco in questa aritmetica: una persona che avrebbe dovuto proseguire non l'ha fatto, e qualcuno è stato pagato per selezionarla in un "no".

Ma il costo che non ho colto finché non ho passato del tempo con il personale dei siti è umano, e si accumula. I coordinatori destreggiano cinque o sei studi contemporaneamente e dedicano dal 40 al 60% del loro tempo al pre-screening. Quando uno strumento di matching produce falsi positivi al di sopra di circa il 30%, smettono di fidarsene — e lo abbandonano, spesso entro tre mesi. Ho visto succedere questo a noi prima della ricostruzione. Una coordinatrice in un sito pilota aveva semplicemente smesso di aprire le nostre segnalazioni. Non per dispetto — per triage. Lo strumento aveva gridato al lupo abbastanza spesso da rendere il controllarlo più lento della sua stessa revisione della cartella. Un matcher che erode la fiducia dell'unica persona che deve agire su di esso non è uno strumento di produttività. È un'altra scheda del browser che ha imparato a ignorare.

Questo è il vero motivo per cui la precisione batte la portata. Non sono solo i pazienti idonei che perdete a causa dei falsi negativi. È che ogni falso positivo consuma la risorsa più scarsa dell'intera impresa — l'attenzione di un coordinatore esaurito — e una volta che è finita, la migliore rete di dati al mondo finisce comunque in un vicolo cieco con un coordinatore che ha smesso di guardare.

"Non è a questo che servono FHIR e l'integrazione con Epic?"

Me lo chiedono spesso, quindi lasciate che affronti le obiezioni di petto.

Partiamo dall'obiezione sugli standard dei dati: di certo FHIR ed Epic risolvono il problema del matching, no? Risolvono il problema delle tubature, il che è necessario ma non sufficiente. L'integrazione di FHIR ed Epic fa fluire dati puliti e strutturati — ma ottenere i dati è la parte che precede quella difficile. Bisogna comunque ragionare su ciò che i dati significano, ed è esattamente lì che l'ontologia svolge il suo lavoro. E nemmeno le tubature sono banali: la certificazione App Orchard di Epic è una revisione di sicurezza da sei a dodici mesi prima di poter toccare una singola cartella. Chiunque prometta un matching su EHR rapido e approfondito o ha già pagato quel costo o non l'ha ancora affrontato.

Poi c'è la preoccupazione normativa: un sistema deterministico e ricco di regole non conta forse come un dispositivo medico regolamentato, con tutto l'onere che ciò comporta? È qui che le linee guida recenti aiutano davvero. Le linee guida aggiornate della FDA sul supporto alle decisioni cliniche, emesse a gennaio 2026, hanno chiarito quali funzioni CDS ricadono al di fuori della definizione di dispositivo — e confrontare le cartelle dei pazienti con i criteri di idoneità a un trial può qualificarsi come CDS non-dispositivo. Il framework di gennaio 2025 dello stesso ente ha delineato una valutazione della credibilità in sette passaggi per l'IA nello sviluppo di farmaci. Un sistema il cui ragionamento è trasparente e riproducibile è molto più facile da far passare attraverso quel framework rispetto a uno la cui logica è una distribuzione di probabilità.

E la versione più diretta: tutto ciò è più veloce che assumere semplicemente più persone? I dati sulle prestazioni dicono un enfatico sì — quando il matching è affidabile. Lo screening con IA riportato ha ridotto i tassi di fallimento dello screening del 73% in un'implementazione, dal 54% al 14% (Trially), e ha ridotto le ore di revisione manuale delle cartelle di circa il 90%. Il punto è che quei guadagni si concretizzano solo se i coordinatori credono nell'output abbastanza da agire su di esso. La velocità costruita sui falsi positivi non è velocità. È un modo più rapido di perdere la platea.

Ciò che la paziente scartata mi ha davvero insegnato

Continuo a tornare da lei, la donna con la linea endovenosa che un algoritmo ha scambiato per una procedura cardiaca. È stata idonea per tutto il tempo. Il trial aveva bisogno di lei. Era lì, proprio dentro i dati. E l'abbiamo persa non perché la tecnologia fosse debole, ma perché era puntata sul problema sbagliato — leggere la superficie del linguaggio quando il compito era ragionare sulla medicina che vi stava sotto.

L'intero settore ha passato cinque anni a sostituire la ricerca per parole chiave con i language model e ha dichiarato risolto il problema del matching. Non lo era. Era stato spostato. Abbiamo barattato un rozzo matching di parole con un sofisticato matching di parole, e i casi che decidono se un trial si arruola nei tempi — le clausole di eccezione, le procedure a vocabolario condiviso, i criteri che richiedono che un ente regolatore possa leggerne il perché — non hanno mai riguardato le parole.

Se gestite trial e state valutando un'IA per il reclutamento, la domanda che porrei a un fornitore non è il numero di accuratezza da titolo, perché quel numero è misurato sui casi che non sarebbero mai stati mancati. Chiedete loro di far passare una cateterizzazione cardiaca e una linea venosa centrale attraverso il loro matcher e di mostrarvi, concetto per concetto, perché una esclude e l'altra no. La risposta a quell'unica domanda vi dice se avete comprato un sistema che legge, o uno che comprende davvero. Noi abbiamo scelto di costruire il secondo tipo — l'IA per il reclutamento nei trial clinici che ragiona sull'ontologia — perché il primo tipo ci è già costato una paziente che non potevamo permetterci di perdere.