Come si scrive un SAP da zero

UnStatistical Analysis Plan(SAP) non è un documento burocratico. È la promessa che si fa ai dati prima ancora di raccoglierli: cosa misurerò, come lo misurerò e cosa farò se qualcosa dovesse andare storto. Scriverlo bene e scriverlo prima, è la differenza tra uno studio difendibile e uno studio che si smonta in peer review. O peggio, uno studio che controlla in fase di approvazione regolatoria. Eppure, chi si siede per la prima volta davanti al problema di redigere un SAP spesso non sa da dove cominciare. Questo articolo risponde esattamente alla domanda di chi deve scrivere un SAP ma non sa cosa fare.

Cos’è un SAP e perché esiste

Il SAP è un documento separato dal protocollo e nasce per completare il protocollo circa le modalità di analisi dei dati. Il protocollo dice perché fai lo studio, il SAP dice come analizzerai i dati che nel protocollo hai dichiatato di voler raccogliere. Questa separazione non è formale, ma è metodologica. Permette di blindare le scelte analitiche prima che i dati siano disponibili, eliminando il rischio — consapevole o no — di aggiustare l’analisi al risultato.

Nei trial clinici regolatori il SAP è obbligatorio per ICH E9 e deve essere finalizzato prima del data lock. Negli studi osservazionali e nelle ricerche in pratica clinica abituale la norma non lo impone sempre con la stessa rigidità. Tuttavia un SAP ben scritto è la forma più concreta di trasparenza metodologica che puoi offrire a un revisore, a uno sponsor o a te stesso.

Struttura, sezioni obbligatorie e checklist operativa per non dimenticare nulla

La struttura di base: le sezioni che non possono mancare

Un SAP segue una logica narrativa: parte dal contesto, entra nella classificazione dei dati, specifica le analisi, e chiude con la gestione delle eccezioni. Ogni sezione ha un ruolo preciso, e saltarne una non è mai una scorciatoia. Sfortunatamente saltare una sezione è un debito che si paga in revisione, in sede regolatoria, o peggio ancora dopo la pubblicazione.

1. Informazioni amministrative e identificative

Prima di qualsiasi contenuto scientifico, il SAP deve identificarsi senza ambiguità. Dunque è sempre necessario includere titolo completo dello studio, codice di protocollo, sponsor, fase dello studio, versione e data del SAP, elenco di tutti gli autori con il rispettivo ruolo — statistico principale, co-statistico, clinical scientist, medical writer se applicabile — e spazio per firma e data. Se il SAP è già stato scritto in precedenza e si sta eseguendo solo un aggiornamento della precedente versione, va sempre indicato l’elenco degli emendamenti con la relativa motivazione. Non basta sostituire il file, serve una traccia di cosa è cambiato e perché.

Un dettaglio che spesso si trascura è il collegamento tra SAP e protocollo. Ogni SAP deve indicare esplicitamente a quale versione del protocollo si riferisce. Quando protocollo e SAP evolvono in parallelo e non si tiene traccia di questa corrispondenza, si creano incongruenze difficili da ricostruire a distanza di anni. Nei trial regolatori queste incongruenze emergono sempre, di solito nel momento più scomodo possibile.

2. Introduzione e obiettivi dello studio

Questa sezione non è una riscrittura del protocollo. È una sintesi orientata all’analisi. Mentre nel protocollo si spiegano le motivazioni del perchè dello studio e degli obiettivi secondo un approccio clinico, nel SAP il lettore, che sia un biostatistico, un monitor, un revisore esterno o l’autorità regolatoria, deve capire rapidamente il disegno dello studio, la popolazione target, il razionale dell’intervento e la struttura degli obiettivi. E tutto senza dover necessariamente aprire un secondo documento. Il SAP, in questa parte, è per certi secondo una versione del protocollo più tecnica maggiormente orientata all’analisi. Questo non significa stravolgere quanto detto nel protocollo. Bensì significa riportare le informazioni essenziali per inquadrare lo studio e quindi comprendere il perchè delle successive analisi descritte.

Ogni obiettivo deve essere formulato in modo da rendere immediatamente chiaro quale endpoint gli corrisponde, quale ipotesi statistica lo formalizza e quale test la verifica. Questa corrispondenza tra obiettivo e strumento analitico è il filo che tiene insieme tutto il SAP. Se si spezza questo filo in questo punto specifico del SAP, si crea ambiguità in ogni sezione successiva. Se c’è un obiettivo esplorativo, va dichiarato come tale fin da questa sezione e non relegato a una nota a piè di pagina nell’analisi.

3. Endpoint: primario, secondari, esplorativi

Questa è la sezione più critica del documento ed è quella in cui si commettono più errori. Ogni endpoint va descritto con una precisione che non lasci spazio all’interpretazione: cosa si misura, con quale strumento, in quale unità, in quale finestra temporale e come viene calcolato se è un endpont derivato — una variazione, un rapporto, una differenza rispetto al baseline.

Un endpoint come“miglioramento del dolore”non è un endpoint: è un’intenzione.“Variazione del punteggio NRS dal baseline a 12 settimane, calcolata come differenza aritmetica tra la misurazione alla settimana 12 e la misurazione al baseline”è un endpoint. La differenza non è estetica: è la differenza tra un’analisi riproducibile e una negoziabile.

L’ordine gerarchico tra endpoint primario, secondari ed esplorativi non è una formalità. Determina la struttura delle ipotesi, la strategia di correzione per molteplicità e il peso inferenziale che si può attribuire a ciascun risultato. È sempre bene ricordare che gli endpoint esplorativi generano ipotesi per studi futuri e non supportano conclusioni causali. Il SAP deve indicarlo esplicitamente.

Se ci sono endpoint compositi — come avviene frequentemente ad esempio nei trial cardiovascolari con MACE — bisogna specificare le regole di gerarchizzazione: quale componente “vince” in caso di eventi multipli nello stesso paziente, come viene gestita la competizione tra eventi, e se si usa il tempo al primo evento o una misura di frequenza cumulativa.

4. Popolazione di analisi

La determinazione della popolazione da analizzare è una delle metodologiche più importanti dell’intero SAP. Le popolazioni standard — Full Analysis Set (FAS), Per Protocol Set (PPS), Safety Set (SS) — sono definizioni di comodo che nascondono un’enorme variabilità nelle loro implementazioni concrete. Non basta scrivere “l’analisi primaria sarà condotta sul FAS”: bisogna definire con esattezza cosa significa FAS in questo studio specifico.

Il Full Analysis Set include tutti i randomizzati che hanno ricevuto almeno una dose del trattamento e hanno almeno una misurazione post-baseline? O tutti i randomizzati indipendentemente dalla compliance? La differenza può cambiare la numerosità della popolazione di analisi anche del 10-15% in studi con elevata discontinuation e quindi cambiare il risultato dell’analisi primaria. Per il Per Protocol Set, bisogna pre-specificare esattamente quali deviazioni dal protocollo comportano l’esclusione. Questa definizione deve essere concordata prima del data lock, non costruita a posteriori guardando i dati.

Per ogni popolazione si deve specificato il criterio esatto di inclusione ed esclusione, accompagnandolo da una specificazione circa la composizione della popolazione primaria. Le analisi di sensibilità sulle altre popolazioni vanno previste qui, con la loro motivazione. Esse servono a testare la robustezza del risultato primario, non a trovare la popolazione che dà il p-value più favorevole.

5. Variabili: definizione e classificazione

Ogni variabile che comparirà nelle analisi — sia come outcome, sia come covariata, sia come variabile di stratificazione — deve essere definita in questa sezione prima che i dati vengano visti. Per ciascuna variabile deve essere indicato il nome esatto come compare nel database, il tipo di variabile statistica (continua, categorica nominale, categorica ordinale, tempo-evento), unità di misura, metodo di raccolta e finestra di osservazione. Se una variabile viene raccolta in più timepoint, occorre sempre specificare come si aggrega e quale misurazione viene usata nell’analisi.

La specificazione delle trasformazioni pre-specificate è uno dei punti del SAP spesso sottovalutato. Se una variabile continua verrà dicotomizzata per l’analisi — per esempio dividendo i pazienti in responder e non-responder sulla base di un cut-off — il cut-off deve essere specificato qui, con una giustificazione che faccia riferimento alla letteratura o alle linee guida, non alla distribuzione osservata nei dati. Un cut-off scelto guardando i dati è, di fatto, data dredging.

Le variabili di confondimento e le covariate di aggiustamento devono comparire esplicitamente in questa sezione. Non possono emergere nell’analisi come decisioni dell’ultimo momento, perché a quel punto si è già esposti all’accusa di aver selezionato le covariate in funzione del risultato.

6. Gestione dei dati mancanti

È la sezione che i SAP mediocri trascurano e che i revisori esperti cercano per prima. I dati mancanti non sono un incidente sfortunato: sono una caratteristica strutturale di qualsiasi studio longitudinale che coinvolga esseri umani, i quali si ammalano, si trasferiscono, cambiano idea, muoiono. Ignorarli o gestirli senza una strategia esplicita non li fa sparire: li trasforma in un’assunzione implicita che spesso non regge all’esame critico.

Il punto di partenza è il meccanismo di mancanza. I dati possono essere MCAR (Missing Completely At Random), il che significa che la probabilità di mancanza non dipende né dal valore mancante né da nessun’altra variabile osservata. Un’ipotesi raramente plausibile in pratica clinica. Possono essere MAR (Missing At Random), il che significa che la probabilità di mancanza dipende da variabili osservate ma non dal valore mancante stesso. Un’ipotesi più realistica e che giustifica l’uso dell’imputazione multipla. O possono essere MNAR (Missing Not At Random), ossia che la mancanza dipende proprio dal valore non osservato. Lo scenario peggiore, che richiede modelli di sensibilità specifici come il pattern mixture model o il selection model.

Il SAP deve dichiarare quale meccanismo si assume per le variabili principali, con quale giustificazione e quale strategia di gestione si adotta come approccio primario. Se si usa l’imputazione multipla, bisogna specificare il numero di dataset imputati — nella pratica corrente raramente meno di 20-50 —, il modello di imputazione (predictive mean matching, regressione logistica,fully conditional specification) e le variabili ausiliarie incluse nel modello. Le analisi di sensibilità — per testare cosa cambia se l’assunzione sul meccanismo è sbagliata — vanno pre-specificate qui, non aggiunte come ripensamento dopo aver visto i risultati principali.

7. Metodi statistici: analisi primaria

Questa sezione deve essere abbastanza dettagliata da permettere a un biostatistico esterno di riprodurre l’analisi senza dover fare nessuna scelta metodologica aggiuntiva. Quindi non basta una semplice dichiarazion del tipo “sarà usata la regressione logistica”. Serve indicare quale tipo di modello, con quale link function, quali variabili incluse come covariate e con quale struttura — continua, categorizzata, con o senza interazioni —, come vengono gestiti i centri negli studi multicentrici (effetti fissi o misti), quale stimatore della varianza, quale metodo per gli intervalli di confidenza e cosa succede se il modello non converge.

Va specificato il software statistico — nome e versione — e se ci sono pacchetti specifici rilevanti per le analisi principali. Va specificato il livello di significatività α adottato, se il test è a una o due code con motivazione esplicita. Un test a una coda richiede una giustificazione clinica e metodologica solida, non è una scelta di default per avvicinarsi alla significatività.

Se l’analisi primaria usa un modello misto per misure ripetute (MMRM) anziché un’analisi al singolo timepoint, bisogna specificare la struttura della covarianza assunta (non-strutturata, Toeplitz,compound symmetry), il metodo di stima e il tipo di denominatore dei gradi di libertà (Kenward-Roger, Satterthwaite). Non sono dettagli tecnici da riservare agli addetti ai lavori: sono scelte che influenzano i risultati e che devono essere tracciabili.

8. Metodi statistici: analisi secondarie ed esplorative

Le analisi secondarie confermative, quelle che contribuiscono, in modo gerarchico, al quadro di evidenza dello studio, richiedono lo stesso livello di pre-specificazione dell’analisi primaria. Il fatto che vengano dopo nella gerarchia non le rende meno vincolanti metodologicamente. Ogni analisi secondaria deve avere un modello, una statistica test, un livello α (che può essere lo stesso del primario se si adotta una procedura gerarchica, o corretto se si adotta un approccio differente), e una direzione di effetto attesa.

Le analisi esplorative sono un territorio diverso e la distinzione deve essere netta e dichiarata. Un’analisi esplorativa non è un’analisi secondaria mal gestita. È un’analisi che serve a generare ipotesi per studi futuri, che viene presentata senza aggiustamenti per molteplicità e che non può essere usata per supportare affermazioni di efficacia. Confondere i due livelli — presentare un risultato esplorativo positivo come se fosse la conferma di un’ipotesi pre-specificata — è una delle forme più comuni di bias da reporting nella letteratura biomedica.

9. Analisi per sottogruppi

Le analisi per sottogruppi sono uno degli strumenti più utili e più abusati della ricerca clinica. Utili perché permettono di capire se un effetto è eterogeneo — se funziona diversamente per uomini e donne, per anziani e giovani, per pazienti con malattia grave e moderata. Usarle senza pre-specificazione significa aprire la porta aldata dredging: testare abbastanza sottogruppi garantisce statisticamente che almeno uno mostri un effetto significativo, anche in assenza di qualsiasi effetto reale. Con 20 sottogruppi testati a α = 0.05, ci si aspetta almeno un falso positivo per pura variabilità campionaria. Quel risultato, una volta trovato, è fin troppo facile da giustificare a posteriori con una narrativa costruita su misura.

Per questo il SAP deve pre-specificare ogni analisi per sottogruppi che verrà presentata come tale. In particolare è necessario indicare il criterio esatto di definizione del sottogruppo — usando variabili raccolte al baseline, non post-randomizzazione —, la numerosità attesa in ciascun strato e il test di interazione previsto.

Significato dell’analisi per sottogruppi

Un’analisi per sottogruppi non significa replicare l’analisi primaria nel sottogruppo, ma testare se l’effetto del trattamento è significativamente diverso tra i livelli del fattore di stratificazione. La distinzione non è tecnica: è concettuale e cambia completamente l’interpretazione del risultato. Replicare l’analisi primaria nel sottogruppo significa chiedersi “Il trattamento funziona negli uomini?” e “Il trattamento funziona nelle donne?” — due test separati, ciascuno con la propria stima dell’effetto e il proprio p-value. Il problema è che un risultato significativo in un sottogruppo e non nell’altro non dimostra che l’effetto sia diverso tra i due: può semplicemente riflettere la minore potenza statistica del sottogruppo più piccolo. Uno studio che nell’intera popolazione ottiene p = 0.04 potrebbe dare p = 0.06 nelle donne e p = 0.03 negli uomini per pura variabilità campionaria, senza che ci sia nessuna vera eterogeneità dell’effetto.

Il test di interazione risponde a una domanda diversa e più precisa: “L’effetto del trattamento è statisticamente diverso tra uomini e donne?” Si stima un unico modello che include il termine di interazione tra trattamento e variabile di sottogruppo e si testa se quel termine è significativo. Solo un’interazione significativa autorizza a concludere che l’effetto è eterogeneo e quindi che ha senso guardare i risultati separatamente per sottogruppo.

La conseguenza pratica è importante: un’analisi per sottogruppi che non include il test di interazione non è un’analisi per sottogruppi nel senso metodologicamente corretto del termine. È una serie di analisi primarie replicate su campioni più piccoli, con tutto il rischio di over-interpretation che ne consegue.

Più sottogruppi si pre-specificano, più aumenta il problema della molteplicità. Problema che va quindi gestito coerentemente con la strategia descritta nella sezione dedicata.

10. Correzione per molteplicità

Ogni volta che si eseguono più test statistici sullo stesso dataset — endpoint multipli, confronti multipli, sottogruppi, analisi interim — aumenta la probabilità di trovare almeno un risultato significativo per puro caso. Senza una strategia per controllare questo rischio, il livello di significatività nominale α = 0.05 non corrisponde alla probabilità reale di errore di tipo I. In uno studio con 20 test indipendenti condotti tutti a α = 0.05 senza correzione, la probabilità di ottenere almeno un falso positivo supera il 60%.

Le strategie disponibili non sono equivalenti né intercambiabili. La correzione di Bonferroni è la più conservativa e la più semplice: divide α per il numero di test. Holm e Hochberg sono meno conservative e mantengono il controllo dell’errore di tipo I family-wise con maggiore potenza. Benjamini-Hochberg controlla il False Discovery Rate anziché il Family-Wise Error Rate, ed è più appropriata in contesti esplorativi con molti test simultanei. Le procedure gerarchiche — in cui si testa il primario, poi i secondari in ordine pre-stabilito, fermandosi al primo non-significativo — sono la scelta standard nei trial regolatori con endpoint confermatori.

La scelta deve essere esplicitata e motivata nel SAP. Non è sufficiente scrivere “verrà applicata la correzione per molteplicità”: bisogna dire quale, come e a quali analisi si applica. Perchè sì non tutte le analisi del SAP richiedono la stessa gestione della molteplicità.

11. Analisi interim e regole di stopping

Se lo studio prevede la possibilità di un’analisi dei dati prima della fine del follow-up pianificato — per ragioni di efficacia, di futility, o di sicurezza — questa eventualità deve essere pianificata nel SAP con lo stesso rigore delle analisi finali. Un’analisi interim eseguita senza un piano pre-specificato consuma α senza contabilizzarlo e invalida di fatto la significatività dell’analisi finale.

La pianificazione include: il numero e il timing delle analisi interim (dopo quante osservazioni, o a quale percentuale di eventi, o a quale data), il metodo per controllare l’errore di tipo I cumulativo — le funzioni di alpha spending come O’Brien-Fleming o Pocock sono le più usate nei trial regolatori —, le soglie decisionali sia per lo stopping per efficacia che per lo stopping per futility e la composizione e le responsabilità del Data Safety Monitoring Board, se presente.

Spesso si trascura il fatto che le analisi interim non devono essere viste dal team di conduzione dello studio prima che siano state valutate dal Data Safety Monitoring Board. Il SAP deve specificare le procedure di blinding — chi vede cosa e in quale momento — perché il solo fatto di sapere che un’analisi interim è stata condotta, anche senza vederne i risultati, può introdurre bias nel comportamento degli sperimentatori.

12. Presentazione dei risultati

Questa sezione stabilisce in anticipo come i risultati saranno mostrati, il che è meno banale di quanto sembri. Le shell delle tabelle — scheletri vuoti con l’intestazione delle righe e delle colonne ma senza i dati — sono una pratica eccellente perché obbligano a decidere in anticipo cosa si vuole vedere, in quale ordine e con quale granularità. Includere le shell nel SAP è una forma di pre-registrazione visiva dell’analisi.

Sono quindi da specificare:

1. le tabelle delle caratteristiche basali con la lista delle variabili da presentare e la statistica descrittiva per ciascuna;
2. le statistiche da riportare per le variabili continue — media e deviazione standard, o mediana e range interquartile, e la scelta deve essere coerente con la distribuzione attesa;
3. il numero di cifre decimali standard;
4. come vengono riportati i p-value, con la soglia minima e la notazione per i valori sotto soglia.

Per le figure — curve di Kaplan-Meier, forest plot per le analisi per sottogruppi, grafici di sensitività — va descritto il formato, gli assi e se saranno incluse le tavole dei soggetti a rischio o gli intervalli di confidenza punto per punto.

13. Deviazioni dal protocollo e gestione delle eccezioni

Nessuno studio clinico si conclude senza deviazioni dal protocollo: visite saltate, finestre di osservazione non rispettate, dosi modificate, criteri di eleggibilità violati retrospettivamente. La questione non è se accadranno, ma come verranno gestite quando accadono. E la risposta a quella domanda deve essere scritta prima che accadano, non mentre si sta analizzando il database.

Il SAP deve pre-specificare:

1. quali tipologie di deviazione sono considerate maggiori — cioè tali da escludere il partecipante dal Per Protocol Set — e quali minori, documentabili ma non escludenti;
2. come vengono gestite le misurazioni al di fuori della finestra di visita (si usa il valore più vicino nel tempo? si esclude? si imputa?);
3. quali decisioni richiedono la convocazione di un endpoint adjudication committee.

Questo lavoro di anticipazione riduce il numero di decisioni ad hoc che vengono prese durante l’analisi e che, se prese guardando i dati, introducono bias che non si possono più eliminare.

14. Software e riproducibilità

Il SAP si chiude con le informazioni tecniche sull’implementazione computazionale. Nome e versione del software statistico — SAS, R, STATA, o altro — con i numeri di versione esatti, perché le stesse procedure in versioni diverse dello stesso software possono dare risultati diversi. Se si usano pacchetti o librerie esterne particolarmente rilevanti per le analisi principali, vanno citati con la loro versione.

Nelle realtà più avanzate — e questa è una direzione verso cui la ricerca clinica si sta muovendo con sempre maggiore urgenza — il SAP include il riferimento a un repository di codice versionato dove i programmi di analisi sono depositati prima del data lock. Questo livello di trasparenza non solo aumenta la credibilità dello studio, ma rende la revisione peer molto più concreta. Un revisore può leggere il codice, non solo la descrizione di cosa il codice dovrebbe fare. La riproducibilità computazionale non è un optional per chi vuole fare ricerca di qualità: è parte integrante di quello che oggi significa pubblicare un risultato difendibile.

Un SAP ben scritto non garantisce risultati significativi. Garantisce qualcosa di molto più prezioso: risultati credibili.

Checklist operativa: prima di finalizzare il SAP

Prima di apporre la firma e bloccare il documento, verifica punto per punto.

Struttura e tracciabilità

• Il SAP riporta numero di versione e data
• È indicato il protocollo di riferimento (versione e data)
• Tutti gli autori e i revisori sono identificati con ruolo e firma
• Il documento è finalizzato prima del data lock

Endpoint

• L’endpoint primario è uno solo, con definizione operativa completa
• Gli endpoint secondari sono elencati in ordine di priorità
• Gli endpoint esplorativi sono distinti esplicitamente da quelli confermatori
• Per ogni endpoint è specificata la finestra temporale di misurazione

Popolazioni analitiche

• Le popolazioni analitiche sono definite con criteri di inclusione/esclusione esatti
• La popolazione primaria è dichiarata
• Le regole per i partecipanti con dati parziali sono pre-specificate

Dati mancanti

• Il meccanismo di mancanza ipotizzato è esplicitato (MCAR/MAR/MNAR)
• La strategia primaria è specificata con il metodo esatto
• Sono previste analisi di sensitività per l’impatto dei dati mancanti

Analisi statistiche

• Il test/modello primario è descritto in modo riproducibile
• Le covariate di aggiustamento sono elencate e motivate
• Il software e la versione sono indicati
• Il livello α e la direzionalità del test sono specificati
• La strategia per la molteplicità è descritta (se applicabile)
• Le analisi per sottogruppi sono pre-specificate e limitate in numero
• Le analisi interim hanno timepoint e regole decisionali definiti

Presentazione dei risultati

• Le shell delle tabelle principali sono incluse o descritte
• Il formato dei risultati (decimali, IC, p-value) è standardizzato
• Le figure previste sono descritte

Conclusione

Il SAP si scrive prima di vedere i dati. Non dopo la raccolta, non dopo la pulizia del database, non mentre si fa l’analisi esplorativa. Ogni deroga a questo principio — anche parziale, anche in buona fede — introduce un bias di analisi che non ha rimedio retroattivo. Se durante la conduzione dello studio emerge la necessità di modificare il SAP, la modifica va documentata come emendamento, con data e motivazione, e tenuta separata dalla versione originale.