Statistical Analysis Plan: cos’è, cosa deve contenere e perché va scritto prima di aprire i dati

Il SAP è uno dei documenti più fraintesi nella ricerca clinica. Molti lo considerano una formalità burocratica da compilare a progetto avanzato. In realtà è il contrario: un SAP scritto dopo aver visto i dati non vale nulla — e un reviewer esperto lo riconosce immediatamente.

Cos’è il SAP e perché esiste

Il Statistical Analysis Plan è il documento che descrive, in modo vincolante e pre-specificato, come verranno analizzati i dati di uno studio. Endpoint primari e secondari, metodi statistici per ciascuna analisi pianificata, criteri di inclusione nelle popolazioni analitiche, regole per la gestione dei missing data, analisi di sensitivity previste, definizione degli estimand.

La parola chiave è pre-specificato. Il SAP deve essere redatto, approvato e registrato prima che i dati vengano aperti e analizzati. Questo è il suo valore fondamentale: separare ciò che era pianificato da ciò che è stato trovato.

Senza questa separazione, qualsiasi analisi può essere accusata di p-hacking o HARKing (Hypothesizing After Results are Known), due pratiche che invalidano la credibilità scientifica di uno studio anche quando i risultati sono genuini.

Quando va scritto (e perché «dopo» è troppo tardi)

La regola è semplice: il SAP deve essere finalizzato prima del database lock, cioè prima che i dati vengano chiusi e resi disponibili per l’analisi. Per gli studi in cieco, questo significa prima dell’unblinding.

Nella pratica esistono sfumature. Alcune modifiche al SAP sono accettabili anche dopo il database lock, purché :

• siano documentate con data e motivazione esplicita
• siano chiaramente distinte dalle analisi pre-specificate originali
• non siano motivate dall’osservazione dei risultati (il che le renderebbe esplorazioni, non analisi confirmatory)

Un SAP modificato dopo aver visto i dati senza questa documentazione non è un SAP: è un’analisi esplorativa presentata come confirmatory. I reviewer delle riviste internazionali e gli ispettori EMA/FDA lo distinguono.

Cosa deve contenere un SAP ICH-compliant

Le linee guida di riferimento sono ICH E9 (Statistical Principles for Clinical Trials) e il suo addendum ICH E9(R1), che introduce il concetto di estimand framework. Un SAP ben costruito include:

1. Definizione degli estimand e degli endpoint

L’estimand descrive precisamente cosa si vuole stimare: la popolazione target, la variabile di interesse, la strategia per gestire gli intercurrent events (eventi che occorrono dopo il trattamento e influenzano l’interpretazione dell’endpoint) e la misura di sintesi. Senza un estimand ben definito, l’endpoint primario è ambiguo.

2. Definizione delle popolazioni analitiche

ITT (Intention-to-treat), mITT (modified ITT), PP (Per-protocol), safety population: ogni popolazione deve essere definita con criteri espliciti e non ambigui. Il SAP deve specificare quale popolazione è primaria per ciascun endpoint e perché.

3. Metodi statistici per ciascuna analisi pianificata

Per ogni endpoint — primario, secondario, esplorativo — devono essere specificati il metodo statistico, le covariate incluse nel modello, il tipo di test (superiority, non-inferiority, equivalence), il livello di significatività e, dove applicabile, le correzioni per confronti multipli.

4. Strategia per i missing data

Questo è uno dei punti più frequentemente trascurati. Il SAP deve specificare il meccanismo assunto per i dati mancanti (MCAR, MAR, MNAR), il metodo di gestione scelto (complete case analysis, imputazione singola, multiple imputation) e la giustificazione metodologica della scelta.

5. Analisi di sensitivity e analisi esplorative

Le sensitivity analysis verificano la robustezza dei risultati primari al variare delle assunzioni. Devono essere pre-specificate, non aggiunte dopo aver visto che l’analisi principale è borderline. Le analisi esplorative vanno chiaramente etichettate come tali.

6. Specifica degli output: TLF shells

Un SAP completo include le shell (struttura vuota) delle Tables, Listings e Figures che verranno prodotte. Questo garantisce che l’output finale sia coerente con quanto pianificato e facilita la verifica da parte del reviewer statistico.

I tre errori più comuni nei SAP che vediamo in fase di audit

Lavorando su audit metodologici pre-submission, incontriamo ricorrentemente tre problemi:

1. SAP scritto dopo aver visto i dati, senza documentazione delle modifiche. Il documento porta una data anteriore al database lock, ma il contenuto riflette chiaramente le analisi già effettuate. I reviewer riconoscono questo pattern dalle scelte analitiche troppo “perfette” rispetto ai dati.
2. Gestione dei missing data non specificata o troppo vaga. Frasi come “i dati mancanti saranno gestiti in modo appropriato” non hanno valore metodologico. Richiedono sempre una specifica esplicita del metodo e delle assunzioni.
3. Incoerenza tra SAP e analisi effettivamente condotte. Il SAP specifica un mixed model, ma il report presenta un’ANCOVA. Il SAP indica la popolazione ITT come primaria, ma le tabelle principali usano la PP. Queste incoerenze sono segnali di allarme immediati per qualsiasi reviewer.

Chi deve scrivere il SAP

Il SAP deve essere redatto da un biostatistico con esperienza specifica nel contesto dello studio e familiarità con le linee guida regolatorie pertinenti. Non è un documento che può essere scritto da un clinico o da un data manager senza competenza statistica specifica, anche quando le analisi previste sembrano semplici.

La domanda “chi firma il SAP?” è rilevante anche dal punto di vista regolatorio. In un trial di fase III con submission EMA, il nome del biostatistico responsabile del SAP appare nel Clinical Study Report e può essere oggetto di verifica durante un’ispezione GCP.

Un SAP ben scritto non rallenta il progetto: lo protegge. Protegge la credibilità scientifica dei risultati, riduce il rischio di richieste di chiarimento in fase di revisione regolatoria, e rende la risposta ai reviewer statisticamente difendibile. Investire nella qualità del SAP nelle fasi iniziali del progetto è sistematicamente più efficiente che correggere i problemi a submission avvenuta.

Mathsly Research redige Statistical Analysis Plan per studi clinici di fase I–IV, studi osservazionali e RWE. Output ICH-GCP compliant, pronti per submission EMA/FDA e peer-review.