From reference materials to examination results: a specification-anchored framework for version-defined qualitative properties

Nel mondo della medicina moderna, un numero crescente di test diagnostici non si limita a misurare un singolo numero, come la quantità di zucchero nel sangue. Invece, essi analizzano dati biologici complessi per collocare il campione di un paziente in una categoria, come l'identificazione di un tipo specifico di batterio o la determinazione della presenza di una mutazione genetica. Questi test si affidano a sofisticati programmi informatici che confrontano i dati biologici grezzi con vaste librerie di sequenze note. Il risultato è un'etichetta o un punteggio che guida i passi successivi del medico. Affinché questi risultati siano affidabili, gli scienziati devono essere in grado di verificare che il test funzioni correttamente. Tradizionalmente, questa verifica si è basata su materiali di riferimento — campioni fisici con proprietà note che i laboratori testano per garantire che le loro macchine siano calibrate. Tuttavia, è emerso un nuovo standard per aiutare a gestire questi materiali, ma esso lascia un vuoto per quanto riguarda i risultati complessi, guidati dal software, che i laboratori moderni producono ogni giorno.

La difficoltà fondamentale risiede nel modo in cui questi risultati digitali vengono creati. A differenza di una semplice misurazione, una diagnosi generata da un software è il prodotto di molte parti in movimento che lavorano insieme: il programma informatico specifico utilizzato, la versione del database genetico che consulta, le soglie matematiche che decidono cosa conta come una corrispondenza e le regole che determinano cosa viene riportato al medico. Ognuno di questi componenti può cambiare indipendentemente. Un aggiornamento del software potrebbe avvenire lunedì, un aggiornamento del database martedì e un cambiamento nelle regole di reporting mercoledì. Se un laboratorio riporta un risultato oggi, e lo stesso campione viene ritestato il mese prossimo dopo questi cambiamenti, la risposta potrebbe essere diversa, non perché la biologia del paziente sia cambiata, ma perché la "ricetta" del risultato è cambiata. Questo crea un problema per il controllo di qualità: come possiamo essere certi che due laboratori diversi stiano guardando effettivamente la stessa cosa se i loro strumenti digitali sono costantemente in movimento?

Un ricercatore di nome Guigao Lin, del Centro Nazionale per i Laboratori Clinici di Pechino, ha proposto un nuovo modo di pensare a questo problema. L'articolo non inventa un nuovo tipo di misurazione né sostiene di aver risolto la scienza sottostante dei test. Invece, offre un quadro per descrivere esattamente cosa significhi un risultato di un test quando quel risultato è definito da un insieme specifico di istruzioni software. L'autore sostiene che dobbiamo smettere di trattare un risultato di un test come un fatto statico e iniziare a trattarlo come la registrazione di un processo specifico. Proprio come un materiale di riferimento fisico ha una storia di provenienza, un risultato digitale deve avere una storia di come è stato realizzato. L'articolo suggerisce che, affinché un risultato sia confrontabile, dobbiamo bloccare l'intera "specifica" che lo ha prodotto. Ciò significa registrare non solo il nome del software, ma la versione esatta del software, il rilascio specifico del database, i parametri utilizzati e le regole applicate ai dati.

La soluzione proposta è quella di ancorare ogni risultato a questa specifica completa. L'autore delinea un set minimo di informazioni che devono essere registrate per rendere un risultato significativo. Ciò include l'identità dell'algoritmo utilizzato, un elenco dettagliato di tutte le versioni dei componenti coinvolti, l'ambito di ciò che il test è progettato per trovare e una registrazione che provi che il test è stato effettivamente eseguito come descritto. Fondamentalmente, l'articolo suggerisce di separare il risultato in tre livelli distinti. Il primo livello è l'evidenza grezza, come le sequenze genetiche trovate. Il secondo livello è la decisione presa dal software, come la classificazione di una sequenza come un virus specifico. Il terzo livello è l'interpretazione, ovvero il consiglio medico fornito sulla base di tale classificazione. Mantenendo separati questi livelli, gli scienziati possono capire esattamente dove si è verificato un disaccordo tra due laboratori. È successo perché un laboratorio ha mancato completamente la sequenza genetica? È successo perché l'hanno trovata ma il software l'ha filtrata? O è successo perché hanno interpretato il reperto in modo diverso in base a diverse linee guida mediche?

Questo approccio cambia il modo in cui valutiamo le prestazioni di questi test. L'articolo sottolinea che non possiamo semplicemente contare quante volte un laboratorio ha ottenuto la risposta "giusta", perché la definizione di risposta giusta dipende dalla versione specifica del software e dall'ambito del test. Se un test è progettato per cercare un set specifico di batteri, non è un fallimento se non riporta un batterio diverso che era al di fuori del suo ambito previsto. L'autore sostiene che le affermazioni sulle prestazioni devono essere legate alla specifica parte del risultato che viene valutata. Ad esempio, se un laboratorio afferma di essere bravo a rilevare un virus, tale affermazione dovrebbe essere giudicata rispetto al livello dell'evidenza grezza, non rispetto al livello del report finale, che potrebbe aver escluso il virus a causa di un filtro di sicurezza. Allo stesso modo, quando si confrontano i risultati nel tempo, l'articolo avverte che guardare semplicemente i tassi di superamento può essere fuorviante se la difficoltà del test cambia. Per ottenere un quadro reale del miglioramento, i laboratori devono utilizzare punti di riferimento fissi che rimangano costanti anche mentre il software evolve.

L'articolo affronta anche la sfida dei test che producono elenchi aperti, come un report che elenca ogni possibile patogeno trovato in un campione. In questi casi, è impossibile dimostrare che il test abbia trovato ogni singola cosa che potrebbe esserci. L'autore suggerisce che dobbiamo definire un dominio limitato per questi test, dichiarando chiaramente cosa il test è capace di trovare e cosa non lo è. Ciò ci consente di misurare errori come falsi allarmi o rilevamenti mancati all'interno di un universo di possibilità noto, piuttosto che cercare di misurare contro un infinito ignoto. Il quadro propone che dovremmo distinguere tra elementi confermati, elementi vicini al limite di rilevamento ed elementi che sono semplicemente al di fuori della capacità del test. Questa distinzione aiuta a prevenire la falsa assunzione che un test sia perfetto solo perché non ha riportato un elemento specifico; a volte, non riportare un elemento è il risultato corretto perché l'elemento non era mai entro l'ambito del test.

In definitiva, questo lavoro è un appello alla chiarezza e alla precisione in un campo che sta diventando sempre più complesso. L'autore non sostiene che questo quadro risolva tutti i problemi o che renderà immediatamente ogni risultato di test perfetto. Invece, l'articolo presenta un insieme di idee testabili, o proposizioni, per vedere se questo nuovo modo di pensare migliori effettivamente il modo in cui confrontiamo i laboratori e monitoriamo le prestazioni nel tempo. L'autore suggerisce che se separiamo i livelli di un risultato, scopriremo che molti apparenti fallimenti sono in realtà solo differenze nel modo in cui le regole sono state applicate. Se tracciamo attentamente i cambiamenti di versione, vedremo che gli aggiornamenti del software possono causare spostamenti sistematici nei risultati che sembrano errori ma sono in realtà solo deriva. L'articolo conclude che, adottando questo approccio ancorato alla specifica, la comunità medica può passare da accordi vaghi a confronti precisi e verificabili, garantendo che quando un medico riceve un risultato, sappia esattamente cosa significa e come sia stato derivato.