28.03.2023.
10 IZAZOVA VALIDACIJE RAČUNALNIH SUSTAVA
Danas gotovo da više i ne postoji GMP ili GDP regulirana organizacija koja ne koristi barem jedan računalni sustav u sklopu svojih GMP ili GDP procesa. No, s druge strane, i dalje se susreću različita pitanja i situacije vezano za validaciju računalnih sustava, stoga u nastavku donosimo izbor deset izazova s obzirom na planiranje, provedbu i dokumentiranje validacije GMP i GDP relevantnih računalnih sustava.
1) Ignoriraju se regulatorni zahtjevi (svjesno ili nenamjerno)
EU GMP Annex 11 vrlo jasno donosi sljedeće: The application should be validated; IT infrastructure should be qualified.
I EU GDP smjernice vrlo su jasne i čak nešto konkretnije oko validacije računalnih sustava: Before a computerised system is brought into use, it should be demonstrated, through appropriate validation or verification studies, that the system is capable of achieving the desired results accurately, consistently and reproducibly.
Dakle, ne postoji mogućnost opravdanja da neki računalni sustava koji se koristi u sklopu GMP ili GDP procesa nije validiran.
2) Nisu inicijalno utvrđeni korisnički zahtjevi za računalnu aplikaciju
Prvi korak u razmatranju nove GMP ili GDP računalne aplikacije treba biti priprema korisničke specifikacije (URS, User Requirements Specification) koja će obuhvatiti konkretne korisničke zahtjeve s obzirom na funkcionalnosti, performanse, kapacitet, regulatorne zahtjeve. Također, vrlo je važno (i korisno) već u URS-u navesti i podršku koja se očekuje, npr. validacija, edukacija i sl.
Ne zaboravimo kako je URS potrebno ažurirati i kod izmjena ili nadogradnji već postojeće i validirane računalne aplikacije.
Uz sve ovo, podsjetimo još i da postojanje URS-a zahtijeva i EU GMP Annex 15 Qualification and Validation pod točkom 3.2. gdje je između ostaloga navedeno i sljedeće: The URS should be a point of reference throughout the validation life cycle.
3) Testne skripte ne provode stvarni korisnici računalne aplikacije
Jeste li se već susreli s odstupanjem na inspekciji ili auditu „samo“ zbog toga što je kompletnu validaciju računalnog sustava provela jedna osoba iz IT-a (ili još bolje, predstavnik dobavljača aplikacije)?
Takvo odstupanje je potpuno opravdano jer bi pojedine validacijske testove (testne skripte) uvijek trebali realizirati stvarni korisnici pojedinih modula i funkcionalnosti, u skladu sa svojim konkretnim rolama unutar aplikacije koja se validira.
4) Provode se samo pozitivni testovi, nisu provedeni negativni testovi
Nitko neće zaboraviti tijekom validacije verificirati da QP rola može prebaciti seriju lijeka na neograničeni status (zalihu). No, jednako tako treba provjeriti i verificirati da ostale role u aplikaciji nemaju pristupna prava i mogućnost promjene statusa serije lijeka.
5) Validacijom nisu obuhvaćene sve GxP relevantne funkcionalnosti
Vraćamo se sada na URS koji treba biti podloga za Funkcijsku specifikaciju unutar koje moraju biti jasno navedene i opisane (najmanje) sve GxP relevantne funkcionalnosti i postavke neke GMP ili GDP relevantne aplikacije. Tek na temelju takvih funkcijskih opisa kreiraju se pojedine testne skripte za provedbu validacijskih testiranja.
A kako znamo da Funkcijska specifikacija obuhvaća sve relevantne GxP funkcionalnosti i da su svi korisnički zahtjevi pokriveni? Pa to je potrebno provjeriti u sklopu DQ faze (Design Qualification). Evo što o tome kratko donosi EU GMP Annex 15: The requirements of the user requirements specification should be verified during the design qualification.
6) Prilozi validacije se ne prikupljaju ispravno
Ovdje treba obratiti pažnju na nekoliko elemenata:
Prilozi trebaju biti jasno označeni kako bi se znalo kojoj testnoj skripti pripadaju
Prilozi trebaju biti usklađeni s koracima provedbe validacije s obzirom na vrijeme kreiranja priloga
Prilozi trebaju biti pregledani i odobreni
Kada se snima zaslon aplikacije, potrebno je „uhvatiti“ cijeli zaslon
7) Zaboravlja se na validaciju vanjskih softverskih servisa (SaaS, Software as a Service)
Ugovorno korištenje cloud softverskih rješenja u GxP reguliranom okruženju vrlo je kompleksna tema koju nećemo ovdje otvarati. No, uvijek treba imati na umu kako svaki računalni sustav koji se koristi u sklopu GMP ili GDP procesa treba biti validiran, neovisno o modelu korištenja takvog softvera. Što se tiče validacije vanjskih softvera, tu postoje različiti scenariji, ali uvijek je korisnik softvera (GxP regulirana kompanija) odgovoran da takva validacija bude provedena te da je validacijska dokumentacija dostupna.
8) Pristup validaciji računalnih sustava nije formalno postavljen
Koje računalne aplikacije treba validirati, što sve takva validacija mora obuhvaćati, tko provodi validaciju i tko odobrava rezultate, koje vrste dokumenata čine validacijski paket, itd; odgovori na ova i slična pitanja moraju biti jasno i konkretno navedeni u sklopu Validacijskog Master Plana (VMP) ili nekog drugog vršnog dokumenta koji pokriva temu validacije.
9) Audit trail validacijskog testiranja se ne čuva
Audit trail je sastavni dio elektroničke transakcije i elektroničkog zapisa na koje se odnosi. Prema tome, sve dok se čuvaju zapisi o validaciji računalne aplikacije treba biti dostupan i audit trail koji pokriva one transakcije koje su provedene u sklopu validacijskog testiranja.
10) Ne evaluira se potreba re-validacije u slučaju promjena i nadogradnji aplikacije
Ponekad je validacija odlično planirana, provedena i dokumentirana… ali prije 10 godina, a računalni sustav je od tada prošao niz manjih i većih promjena i nadogradnji.
Svaku promjenu koja se odnosi na neki GMP ili GDP računalni sustav treba sustavno voditi te kod svake takve promjene i evaluirati potrebu za dodatnom validacijom novih funkcionalnosti, izmijenjenih funkcionalnosti i već postojećih funkcionalnosti.
Tema GxP računalnih sustava Vam je nova? Ili se želite posjetiti na sve zahtjeve i informirati se o konkretnim situacijama iz prakse?
Evo koji su interaktivni sadržaji dostupni vezano za GxP računalne sustave:
Sve što ste ikada trebali znati o audit trail-u
Integritet podataka – stvarni primjeri iz GMP okruženja
10 najvažnijih stvari koje treba znati svaki RP
Razmišljate li o edukaciji za više zaposlenika koja bi pokrivala točno određene teme iz područja računalnih sustava? Pogledajte prednosti razvoja edukacijskog sadržaja na zahtjev.