Negli post precedenti, ho nominato diverse volte che un software utilizzato in ambienti regolamentati secondo le GxP deve essere validato. Quanto troverete qui non vuole essere assolutamente una procedura di validazione né vuole essere una guida completa per realizzarla, ma solo una piccola guida per aiutarvi a capire cosa significa effettuare un'attività di questo tipo.
Validare un software è un'attività abbastanza impegnativa, sia in termini di risorse umane che economiche.
Infatti per validare un software di medie dimensioni, come ad esempio un MES, si può pensare di superare abbondantemente le 100 giornate uomo, senza considerare le risorse interne.
E' in oltre necessario considerare che per considerare un software validabile, deve essere validato anche tutta la parte sottostante, quindi anche i server su cui è installato, se questi sono server virtuali, vanno validati sia i virtuali che i fisici, questo vale anche per il cloud anche se con procedure diverse.
La procedura di validazione deve far parte del QMS dell'azienda che intende utilizzare il software, mentre per la validazione è una consuetudine utilizzare anche personale esterno con la giusta esperienza.
Come abbiamo detto, ogni ente che può compromettere il sistema in validazione, questo deve essere coinvolto nella validazione.
Software Validation Plan: Quindi andremo prima di tutto a realizzare un elenco di tutti i software presenti in azienda e successivamente andremo a soppesare per impatto gli stessi andando cosi a completare il Software Validation Plan.
Introduzione: Questa è la prima parte da inserire nella validazione, si tratta di una breve descrizione di quanto si sta andando a validare.
Scopo: Individuato il software più importante, si procederà con andare a specificare lo scopo della convalida stessa, identificare i documenti da compilare, definire i ruoli e le responsabilità per poi procedere nel pianificare tutte le attività del caso.
Campo d'Applicazione: A seguito della definizione dello scopo, è necessario specificare il Campo d'Applicazione, andando a scrivere una frase del tipo "Il presente Validation Plan si applica ai componenti HW e SW del sistema xxx dello stabilimento xxxx"
Riferimenti: è necessario che nella validazione siano riportati tutti i riferimenti alla varie procedure sia interne (SOP), cosi come fare riferimento ad eventuali procedure della Corporate (nel caso se ne faccia parte), ma anche a tutte le normative ISO, GAMP o ai capitoli del Code Of Federal Regulation.
Glossario: è bene inserire anche un elenco di termini cosi che un eventuale ispettore possa leggere il documento in autonomia
Strategia di Convalida: in base ad una matrice ben definita, cosi da mostrarne le criticità sul sistema qualità, poi andremo a:
Compilare un Risk Assessment rispondendo ad una serie di domante standard

Completare la “Tabella Domande di Criticità del SW”; se almeno una delle risposte alle domande 1-7 (da 1 a 7) è risultata essere “SI”, IL SW IN ESAME RISULTA DA VALIDARE; se tutte le risposte alle domande 1-7 (da 1 a 7) sono risultate essere “NO”, IL SW IN ESAME NON RISULTA DA VALIDARE.
Part 11 Analysis; se volessimo utilizzare i record salvati in sostituzione al cartaceo il sistema dovrà essere in compliance anche con il PART11
A questo punto si è giunti al momento in cui dovremo scrivere le attività di convalida che consisteranno nel preparare:
Validation Plan
User Requirement
Functional Specificaion
Cofiguration Specification
Design Specification
Part 11 Analysis
Risk Analysis
Insallation/Operation/Performance Qualification
Operational Qualificaion Protocol
Performance Qualification Protocol
Insallation/Operation/Performance Qualification Report
Operational Qualification Report
Performance Qualification Report
Test tracability Matrix
Validation Report
Definizione delle Responsabilità
Nel caso vi servissero informazioni più di dettaglio non esitiate a contattarmi
Comments