Pe scurt: un program folosit pentru înregistrări GMP nu se certifică, se validează la fabrica care îl folosește. Validarea arată, documentat, că sistemul face ce trebuie pentru procesele tale și că rămâne așa. Volumul ei se stabilește în funcție de risc, după ghidul GAMP 5, iar furnizorul trebuie să-ți dea o bună parte din documentele de pornire.
De ce se validează un software
EU GMP Anexa 11 cere ca sistemele computerizate folosite în activități GMP să fie validate, iar 21 CFR Part 11 cere același lucru pentru înregistrările electronice pe piața americană. Ideea e simplă: dacă un dosar de lot, un rezultat de laborator sau o decizie de eliberare stau într-un program, trebuie să poți demonstra că programul le înregistrează corect, complet și fără modificări neurmărite.
Validarea nu e un certificat primit odată cu programul. Același software poate fi validat într-o fabrică și nevalidat în alta, în funcție de cum e configurat și folosit.
Abordarea pe risc: GAMP 5
GAMP 5, ghidul publicat de ISPE, e referința folosită de industrie pentru validarea sistemelor computerizate. Principiul lui: efortul de validare depinde de riscul pentru pacient, pentru calitatea produsului și pentru integritatea datelor, și de cât de mult e sistemul configurat sau dezvoltat special.
GAMP 5 împarte software-ul în categorii:
- Categoria 1, infrastructură: sisteme de operare, baze de date, rețea. Se califică, dar nu se validează funcțional.
- Categoria 3, produse neconfigurate: folosite așa cum vin. Validarea e mai ușoară și se concentrează pe felul în care sunt folosite.
- Categoria 4, produse configurate: aceeași bază, adaptată prin setări la procesele fabricii. Se verifică în special configurația.
- Categoria 5, aplicații dezvoltate la cerere: cer cea mai detaliată verificare, inclusiv a felului în care a fost scris și testat codul.
Multe sisteme reale au părți din mai multe categorii, iar încadrarea se justifică în analiza de risc.
Documentele validării, pe rând
- Planul de validare: ce se validează, cine răspunde, ce documente rezultă și criteriile de acceptare.
- Cerințele utilizatorului (URS): ce trebuie să facă sistemul, scrise de fabrică, în termenii proceselor ei. Fiecare cerință are un număr, ca să poată fi urmărită până la test.
- Analiza de risc: pentru fiecare funcție, ce se poate întâmpla dacă nu merge și cât de grav ar fi. De aici rezultă cât de mult testezi fiecare parte.
- Specificațiile funcționale și de configurare: cum îndeplinește sistemul cerințele. De obicei le scrie furnizorul.
- Matricea de trasabilitate: legătura dintre fiecare cerință, specificația care o acoperă și testul care o verifică. Inspectorii o cer des, pentru că arată dintr-o privire dacă vreo cerință a rămas netestată.
- IQ, calificarea instalării: sistemul e instalat corect, în mediul corect, cu versiunile corecte.
- OQ, calificarea funcționării: fiecare funcție lucrează conform specificațiilor, inclusiv în cazurile limită: valori în afara toleranței, semnături refuzate, acces interzis.
- PQ, calificarea performanței: sistemul funcționează în producția reală, cu oamenii, procedurile și datele fabricii, pe loturi reale.
- Raportul de validare: rezultatele, abaterile găsite și cum au fost tratate, plus concluzia că sistemul poate fi folosit.
Ce face furnizorul și ce face fabrica
| Furnizorul | Fabrica |
|---|---|
| specificațiile funcționale și de configurare | cerințele utilizatorului (URS) |
| documentația propriei dezvoltări și a testelor | analiza de risc pe procesele ei |
| șabloanele IQ, OQ, PQ și matricea de trasabilitate | executarea calificărilor și semnarea lor |
| poziția față de Anexa 11 și 21 CFR Part 11 | procedurile de operare și instruirea |
| sprijin la executarea testelor | decizia că sistemul poate fi folosit |
Responsabilitatea pentru validare rămâne a fabricii. Un furnizor bun scurtează drumul, dar nu poate semna în locul ei.
Cum rămâne sistemul validat
Validarea nu se termină la pornire. Starea validată se menține prin:
- controlul modificărilor: orice schimbare de versiune, configurație sau proces trece prin evaluarea impactului și, după caz, prin retestare;
- revizuirea periodică a sistemului: utilizatori, drepturi, incidente, modificări, backup;
- revizuirea audit trail-ului pentru înregistrările critice;
- testarea restaurării din backup, nu doar a existenței backup-ului;
- instruirea noilor utilizatori înainte să primească acces.
Greșeli frecvente
- URS copiat de la furnizor: cerințele trebuie să descrie procesul tău, nu lista de funcții a programului.
- Totul testat la fel: fără analiză de risc, se testează la fel de mult o setare de afișare și o semnătură de eliberare.
- Documente scrise după fapt: validarea făcută după ce sistemul e deja folosit în producție.
- Modificări fără control: o versiune nouă instalată fără evaluare invalidează în tăcere tot ce s-a făcut.
- Hârtie și sistem în paralel, la nesfârșit: perioada de tranziție trebuie să aibă un termen.
Întrebări frecvente
Cine semnează validarea?
Fabrica: proprietarul procesului, asigurarea calității și, după caz, responsabilul de sistem. Furnizorul semnează documentele pe care le-a produs el.
Se validează și sistemele găzduite în cloud?
Da, după aceleași principii. În plus, furnizorul și găzduirea sunt evaluate, iar contractul stabilește cine răspunde de backup, securitate și disponibilitate.
Trebuie revalidat sistemul la fiecare actualizare?
Nu complet. Prin controlul modificărilor se evaluează ce atinge actualizarea, iar retestarea se face doar pentru acele părți, proporțional cu riscul.
Ce este CSA?
Computer Software Assurance, abordarea promovată de FDA, care pune accent pe gândire critică și pe testare proporțională cu riscul, în locul documentării exhaustive. Merge în aceeași direcție cu a doua ediție a GAMP 5.
Pentru DataFlows Pharma livrăm pachetul de la care pornește validarea: URS cu matrice de trasabilitate, analiză de risc, poziția față de Anexa 11 și 21 CFR Part 11, declarația privind integritatea datelor și șabloanele IQ, OQ și PQ. Pentru imaginea de ansamblu, vezi ce trebuie să acopere un software de producție pentru industria farmaceutică.
