Validazione dei Sistemi Informatici (CSV) vs. Garanzia dei Sistemi Informatici (CSA): Quali sono le principali differenze?

Se lavori nell'industria farmaceutica o dei dispositivi medici, probabilmente hai sentito parlare spesso dei termini CSV e CSA. E se hai mai provato a cercarli, potresti esserti trovato davanti a pareti di linguaggio normativo che sembravano più confusi che utili.

Quindi scomponiamolo in termini semplici e chiari: cosa significano realmente questi due approcci, in cosa differiscono e perché è importante per la tua organizzazione.

Cos'è la Computer System Validation (CSV)?

Validazione dei Sistemi Computerizzati, o CSV, è stato l'approccio standard nelle industrie regolamentate per decenni. Nel suo nucleo, la CSV è un processo documentato che garantisce che un sistema informatico faccia esattamente ciò per cui è stato progettato, in modo coerente e ripetuto. L'obiettivo è assicurare l'integrità dei dati, la qualità del prodotto e la conformità alle normative GxP applicabili.

La FDA ha pubblicato per la prima volta la sua linea guida sulla CSV nel 2003, insieme alla ben nota normativa 21 CFR Part 11, che regola i documenti elettronici e le firme elettroniche. Da allora, la CSV è diventata il quadro di riferimento per le aziende farmaceutiche, le organizzazioni di ricerca clinica e i produttori di dispositivi medici quando implementano o aggiornano un sistema computerizzato.

Le quattro domande che guidano il processo CSV

Con un approccio CSV, il processo di validazione segue un ciclo di vita strutturato. Prima che inizi qualsiasi test, il team deve rispondere a quattro domande fondamentali:

• Cosa verrà validato?
• Quali sono i criteri di accettazione?
• Come verrà validato?
• E chi effettuerà la validazione?

Queste domande modellano l'intera strategia documentale e aiutano a definire l'ambito del lavoro.

I tre documenti di specifica principali

La validazione stessa si basa su tre documenti di specifica chiave. Il Specifiche dei Requisiti Utente (URS) descrive ciò che il sistema deve fare dal punto di vista dell'utente; ad esempio, un sistema di laboratorio potrebbe dover tracciare i record di formazione degli analisti, assegnare automaticamente i compiti e conformarsi a 21 CFR Part 11.

Il Functional Specification (FS) descrive come il sistema soddisferà tali esigenze dell'utente, includendo il design dell'interfaccia e l'elaborazione dei dati. La Design Specification (DS) entra più nel dettaglio dell'architettura tecnica, del design del database, delle misure di sicurezza, dei requisiti di rete e delle configurazioni delle interfacce.

Come funziona il testing: IQ, OQ e PQ

Una volta che questi documenti sono a posto, i test seguono il classico modello a V (chiamato anche approccio lineare).Installation Qualification (IQ) verifica che il sistema sia stato installato correttamente in conformità con le specifiche di design.Qualifica Operativa (OQ) verifica che il sistema funzioni come descritto nella specifica funzionale. E Qualifica delle Prestazioni (PQ) conferma che il sistema operi in linea con i requisiti dell'utente in condizioni reali. In breve, a ogni specifica corrisponde un test, con conseguente notevole volume di documentazione.

Punti di forza e critiche della CSV

Questa natura pesante di documentazione della CSV è stata da sempre sia il suo punto di forza sia la sua critica principale. Sì, è approfondita. Sì, costruisce una solida traccia documentale. Ma è anche dispendiosa in termini di tempo, costosa e a volte porta le organizzazioni a creare montagne di carta che aggiungono poco valore reale alla sicurezza del paziente o alla qualità del prodotto.

Cos'è la Computer Software Assurance (CSA)?

Ed è qui che entra in gioco Assicurazione del Software per Computer (CSA). La FDA ha introdotto la CSA tramite un documento di linea guida preliminare intitolato "Computer Software Assurance per software di produzione e di sistema qualità," pubblicato il 13 settembre 2022. L’idea alla base di CSA è semplice: invece di convalidare tutto con lo stesso livello di rigore indipendentemente dal rischio, concentra i tuoi sforzi dove contano di più.

CSA è un approccio basato sul rischio che mira a stabilire e mantenere la fiducia che il software sia idoneo al suo uso previsto. Piuttosto che generare una documentazione esaustiva per ogni funzionalità del sistema, CSA invita i team a pensare in modo critico a ciò che potrebbe andare storto e alla gravità delle conseguenze. Più alto è il rischio per la sicurezza del paziente o per la qualità del prodotto, più rigorosi devono essere i test. Per le funzionalità software a rischio minore, una documentazione ridotta e metodi di test più semplici sono perfettamente accettabili.

Passo 1: Identificare l’uso previsto

Il processo CSA inizia con l’identificazione dell’uso previsto del software. La FDA distingue tra software utilizzato direttamente come parte della produzione o di un sistema qualità, come strumenti che automatizzano i processi di produzione o raccolgono dati di qualità, e software utilizzato per supportare tali sistemi, come strumenti di test o applicazioni di gestione dei registri generali. Il software utilizzato per funzioni aziendali generali, come email o contabilità, è completamente al di fuori dell’ambito.

Passo 2: Valutare il rischio

Una volta chiaro l’uso previsto, il passo successivo è valutare il rischio. Una funzionalità software è considerata ad alto rischio quando il suo malfunzionamento potrebbe portare a un problema di qualità che compromette la sicurezza del paziente.

Ad esempio, software che mantiene parametri di processo critici come temperatura o pressione, o software che analizza l’accettabilità del prodotto senza una revisione umana aggiuntiva, rientrerebbero tipicamente nella categoria ad alto rischio. Al contrario, il software utilizzato per il routing di CAPA, il tracciamento dei reclami o la gestione del controllo delle modifiche è generalmente considerato non ad alto rischio.

Passo 3: Determinare il tipo di test appropriato

Il livello di rischio determina quindi il tipo di test richiesto. Le funzionalità ad alto rischio richiedono test robusti scriptati, strutturati, documentati e tracciabili rispetto ai requisiti. Le funzionalità a rischio medio possono utilizzare test scriptati limitati, che sono un ibrido di metodi strutturati e flessibili.

Per le funzionalità a basso rischio, metodi di test non scriptati come testing esplorativo, test ad hoc o error-guessing sono perfettamente adeguati. Il tester usa la propria conoscenza e giudizio per esplorare il sistema senza la necessità di script di test formali.

Passo 4: Mantenere le registrazioni appropriate

Le registrazioni devono comunque essere mantenute secondo CSA, ma sono più snelle e mirate. Una registrazione CSA dovrebbe catturare l’uso previsto della funzionalità software, il livello di rischio determinato, una descrizione dei test eseguiti, eventuali problemi riscontrati e come sono stati risolti, una conclusione sull’accettabilità dei risultati, la data del test e il nome della persona che lo ha eseguito.

CSV vs. CSA: Le differenze chiave

Sia CSV che CSA esistono per garantire che i sistemi computerizzati nelle industrie regolate siano affidabili, conformi e idonei all’uso. Entrambi comportano pianificazione, test, documentazione e reporting. E entrambi si applicano a sistemi che impattano la sicurezza del paziente, la qualità del prodotto e l’integrità dei dati. Ma le somiglianze iniziano a svanire quando si esaminano le filosofie alla base di ciascun approccio.

CSV: guidato dalla conformità per natura

CSV è fondamentalmente orientato alla conformità. Convalida che un sistema soddisfi un insieme predeterminato di specifiche, e lo fa con lo stesso grado di accuratezza per tutte le funzionalità del sistema. L’onere documentale è elevato, e il processo è in gran parte lo stesso indipendentemente dal fatto che si stia testando un sistema critico per l’acquisizione dati o una semplice funzione di gestione dei documenti.

CSA: guidato dall’assicurazione per progettazione

CSA, al contrario, è guidato dall’assicurazione. Invita i team a pensare in termini di rischio e ad applicare lo sforzo di testing in proporzione a ciò che è effettivamente in gioco. Sostituisce la mentalità “taglia unica” di CSV con un approccio mirato, flessibile e più intelligente. Si dedica meno tempo alla scrittura di script di test per funzionalità a basso rischio e più tempo a un’assicurazione significativa nelle aree che potrebbero davvero danneggiare i pazienti o compromettere la qualità del prodotto.

Cosa significa CSA nella pratica

Dal punto di vista pratico, CSA riduce i tempi di ciclo per la creazione, la revisione e l’approvazione dei test. Riduce il numero di documenti generati. Permette alle organizzazioni di prendere atto delle prove di test fornite dai fornitori anziché ripetere lo stesso lavoro di convalida. E supporta le aziende che si stanno orientando verso l’automazione e le pratiche di sviluppo agile, dove i modelli di convalida rigidi e lineari spesso creano colli di bottiglia.

CSA sostituisce CSV?

Una distinzione importante da notare: CSA non elimina la necessità di CSV. Piuttosto, ridefinisce come viene effettuata la convalida. Alcuni sistemi altamente regolamentati possono ancora beneficiare della struttura completa che CSV fornisce. La decisione su quale approccio utilizzare, o se combinare entrambi, dipende dalla natura del software, dal livello di rischio coinvolto e dagli obblighi normativi dell’organizzazione.

Passare da CSV a CSA

Per le organizzazioni che hanno operato con CSV per anni, passare a CSA può sembrare un grande cambiamento culturale. E in molti sensi, lo è. La transizione richiede ai team di smettere di considerare la convalida come un esercizio di documentazione e di iniziare a considerarla come un esercizio di gestione del rischio.

Praticamente parlando, la transizione comporta la valutazione delle pratiche di convalida correnti per identificare aree in cui la documentazione può essere ridotta senza compromettere la conformità. Significa formare i team qualità e IT sui principi CSA e sul pensiero basato sul rischio.

Significa imparare a sfruttare più efficacemente la documentazione del fornitore e i dati di qualificazione dei fornitori, invece di duplicare gli sforzi di convalida internamente. E significa adottare strumenti e tecnologie che possono automatizzare parti del processo di assicurazione.

Il cambiamento non deve avvenire dall’oggi al domani. Molte organizzazioni scelgono di applicare i principi CSA alle nuove implementazioni di sistema mantenendo l’approccio CSV esistente per i sistemi legacy. Questa strategia a fasi permette ai team di acquisire esperienza e fiducia con il nuovo approccio senza interrompere le operazioni in corso.

Perché questo è importante per la tua organizzazione

Il passaggio da CSV a CSA riflette un cambiamento più ampio nell’approccio della FDA alla qualità. Piuttosto che equiparare la conformità alla documentazione, la FDA promuove una cultura in cui la qualità è integrata nei processi, le decisioni si basano sul pensiero basato sul rischio e gli sforzi di convalida si concentrano dove generano un reale valore.

Per le aziende farmaceutiche e i produttori di dispositivi medici, questo è in definitiva positivo. Significa meno tempo sepolto in script di test e più tempo dedicato a costruire sistemi realmente sicuri, affidabili ed efficaci. Significa tempi di implementazione più rapidi, un uso più efficiente delle risorse e pratiche di convalida che si adattano alla complessità del software moderno.

Che tu sia ancora pienamente impegnato nel CSV, stia esplorando attivamente il CSA o ti trovi in una via di mezzo, comprendere la differenza tra questi due approcci è il primo passo per prendere decisioni più intelligenti su come la tua organizzazione gestisce e convalida i sistemi computerizzati.

Domande frequenti

D1. Qual è la differenza principale tra CSV e CSA nel settore farmaceutico?

CSV (Computer System Validation) è un approccio focalizzato sulla documentazione e sulla conformità che convalida tutte le funzionalità del sistema con lo stesso rigore. CSA (Computer Software Assurance) è un approccio basato sul rischio introdotto dalla FDA che concentra gli sforzi di testing nelle aree con il maggiore impatto sulla sicurezza del paziente e sulla qualità del prodotto, riducendo la documentazione non necessaria per funzionalità a basso rischio.

D2. Il CSA sta sostituendo il CSV nell’industria farmaceutica?

Il CSA non sostituisce completamente il CSV. Ridefinisce invece il modo in cui viene eseguita la convalida. La FDA ha introdotto il CSA per rendere il processo di convalida più efficiente e focalizzato sul rischio. Le organizzazioni possono ancora utilizzare il CSV per sistemi altamente regolamentati o complessi, applicando i principi CSA ad altri software dove è appropriato un approccio più leggero.

D3. Quali regolamenti disciplinano CSV e CSA nelle scienze della vita?

Il CSV è disciplinato principalmente da FDA 21 CFR Part 11 e dalle linee guida GxP, insieme a GAMP 5, che classifica i sistemi computerizzati in base al rischio. Il CSA è guidato dalla bozza di orientamento della FDA del 2022 intitolata "Computer Software Assurance for Production and Quality System Software", che delinea un quadro basato sul rischio per le attività di assurance.

D4. Quali tipi di test vengono utilizzati nel CSA?

Il CSA utilizza due principali tipi di testing in funzione del livello di rischio. Per le funzionalità software ad alto rischio sono richiesti test robusti e scriptati con documentazione formale. Per le funzionalità a rischio basso o medio sono accettabili metodi di testing non scriptati come exploratory testing, test ad hoc e error-guessing, riducendo la necessità di script di test formali e di ampia documentazione.

D5. Come passa un’azienda farmaceutica dal CSV al CSA?

La transizione da CSV a CSA comporta l’applicazione del pensiero basato sul rischio ai processi di convalida esistenti, la riduzione dei test scriptati per le funzionalità di sistema a basso rischio, l’utilizzo di evidenze di qualificazione fornite dai fornitori e la formazione dei team di qualità e IT sui principi CSA. La maggior parte delle organizzazioni adotta un approccio graduale, iniziando con le nuove implementazioni di sistema prima di riesaminare i sistemi legacy.