Hogyan (ne) validáljunk? - 2. rész: Kockázatos tervezés

A tervezés témájával már korábban is foglalkoztunk, azonban vannak olyan, a gyógyszeriparra jellemző sajátosságok, melyek miatt érdemes ezen cikksorozat keretében, hasonlóan laza formában, elsősorban az íratlan (ököl)szabályok mentén is külön fejezetet szentelni, tesszük ezt ismét a teljesség igénye nélkül, hiszen a GMP környezetben zajló műszaki tervezési folyamat önmagában több kötetes könyvhöz elegendő témát szolgáltat.

A Ki írja az URS-t? című cikkünkben adtunk egy gyors körképet arról, hogy egy projekt során miért és milyen megközelítések mentén célszerű az igényeket, elvárásokat dokumentálni, milyen jellemző hibákat vétenek a projekt szereplői, míg végül az igény a beszerzési részlegtől a potenciális szállítók/kivitelezők asztalára kerül.

Folytassuk most attól a ponttól, ahol előző írásunkban abbahagytuk: hogyan tovább onnantól, hogy az elvárások rögzítésre kerültek?

Amint megszületett az írásos felhasználói igény, a projekt több szálon folytatódhat, sorrendben, vagy akár párhuzamosan is, függően attól, hogy az adott munkafázisok milyen módon és mértékben támaszkodnak egymásra. Részben a korábban már említett, szakismereti differenciák miatt, saját gyakorlatunk alapján a párhuzamosan zajló kooperatív munkamenetet szoktuk javasolni, mely semmiképp sem jelenti akár a GMP, akár egy gyártóegység helyi minőségbiztosítási rendszere által megkívánt precedencia megkerülését, sokkal inkább a csapatmunka szükségességét, melynek során a résztvevők közösen, de szaktudásuk szerint az egyes fázisok esetén más-más szerepkörben, egymás munkáját segítve, egymás preferenciáit szem előtt tartva tevékenyked(het)nek. A párhuzamos munkavégzés mellett szóló legfőbb érv, hogy ezen tevékenységek egymásra rekurzív módon hat(hat)nak, azaz az egyik során hozott döntés maga után vonhatja egy a másikban megfogalmazott állítás revízióját.

Az igények alapján a mérnökök elképzelnek egy rendszert, vagy berendezést, mely alkalmas azok kielégítésére. Az “alkalmas” szó azonban több száz elvárás, kérdés és azokra adott választ összességét szimbolizálja. Egy-egy igény teljesülését egy vagy több tervezett funkció vagy irányelv hivatott garantálni, melyet a Funkcionális Specifikációban foglalnak össze. Felsorolásra kerülnek a rendszer főbb paraméterei, funkciói, esetlegesen a tervezett műszaki megoldások részben vagy egészben. Fontos látni, hogy a tervezési folyamat ezen szakaszában még nem kell, hogy elvárás legyen egy explicit deklarált műszaki megoldás. Tekinthető ez egyfajta vázlatként, nagyjából miként képzelik el a rendszer tervezői annak majdani működését. Ahogy az URS a “Mit?”, az FS (és majdan a később tárgyalt specifikációk) a “Hogyan?” kérdésekre kell általános vagy átfogó válaszokat adjanak.

Akár már az URS alapján, de mindenképpen az FS dokumentummal párhuzamosan, vagy annak elkészültét követően ajánlott elkezdeni dolgozni a minőségbiztosítás vezetésével a Funkcionális kockázatelemzés összeállításán. Az alkalmazott módszertan változó lehet (PARMOD, FMEA, stb.) de a cél minden esetben ugyanaz: minden egyes igény / funkció mellé meghatározni annak folyamatra vetített kockázatait, értékelni azt kritikusság, előfordulási valószínűség és még egy sor más szempont alapján, majd meghatározni azon preventív lépéseket, amelyek a kockázati tényező előfordulásának és/vagy hatásának minimalizálását, észlelhetőségének maximalizálását lehetővé teszik. Több jellemző hiba (vagy leginkább ezek kombinációja) szokott felmerülni a készítés során.

Akárcsak az URS esetén, a szaktudás mellett itt is nagyon fontos (ha nem fontosabb) a gyakorlati tapasztalat, az adott rendszer és a folyamat ismerete. A kockázatelemzés tulajdonképp arra a feltételezésre épít, hogy “Ami elromolhat, az egyszer el is romlik”. A feladat tehát: megtalálni a rendszerben - célszerűen funkcióhoz kötötten - a lehetséges hibamódokat, meghatározni, miképpen fordul(hat)nak elő, gyakorlati, statisztikai és/vagy műszaki alapokon megbecsülni az előfordulás valószínűségét, jelentőségét és megoldást találni az elkerülésükre. Bármilyen képzett és tapasztalt is egy mérnök, értelemszerűen nem lesz képes egy vegyész, gyógyszerész vagy biológus szemszögéből végiggondolni egy folyamatot, és ugyanez természetesen fordítva is igaz. Persze több hasonló rendszer után mindkét oldalon megszerezhető a szükséges rutin, azonban ez nem pótolja egyik vagy másik résztvevő aktív közreműködését. A kockázatelemzés csapatmunka: minden egyes szakág a saját aspektusai szerint tudományos/gyakorlati alapon kell vizsgálja a tervezett rendszer funkcióit.

Egy kockázati tétel szinte kivétel nélkül többdimenziós: vagy a funkció, vagy a hatás több területet is érint, azaz a készítéséért felelhet egyetlen ember, de az általánosan tapasztalt, talán legjelentősebb hibák egyike, hogy a kockázatelemzést végző csapat létszáma ugyanerre az egy emberre korlátozódik, aki nem ritka esetben - a korábbi cikkünkben kifejtett okok miatt - egy a rendszer szempontjából minimális releváns tapasztalattal rendelkező kezdő. Az előzőek együttesen szoktak egy kritikus besorolású, 4. vagy 5. kategóriás rendszernél egy maximum 10, általános kockázati tételt tartalmazó elemzést eredményezni, aminek értéke használhatóság szempontjából zérus.

Megjegyzés: Nem kevésbé káros, a sokszor neves - a témában egyébként kiemelkedően jártas - kifejezetten validációra szakosodott világcégek által összeállított template-ek “szent grálként”, tömeges és/vagy szakismeret nélküli, checklista-szerűen történő alkalmazása, melynek eredménye egy formai szempontból látványos és kifogástalan dokumentum, azonban a tartalom sok esetben irreleváns vagy téves, ennél fogva a levont konzekvenciák nem különben hibásak. (Jó példa erre egy ügyfelünknél a közelmúltban revalidációra jelölt rendszer, melynek egy fent említett template alapján készített kockázatelemzését tekintettük át ajánlatadáshoz. Amikor a helyszíni bejárásra sort kerítettünk, a megbízóval együttesen szembesültünk azzal, hogy az elemzés egyes pontjai egy másik, egyébként szintén azon a területen létesült rendszerhez tartoznak. - Nyilván a készítő vagy nem tudta, hogy a két berendezés egymástól egyébként független, vagy az egyik dokumentációja donorként szolgált a másik validációjához….)

Az URS, az FS és az RA együttesen képezik alapját mind a további specifikációknak (Hardware Desing Specification, Software Desing Specification, stb.), mind pedig a validációnak és annak egyes részfolyamatainak.

A rendszer szempontjából elkülönül és legtöbbször jelentőségében is háttérbe szorul a Validációs Terv valamint a Projekt Terv. Előbbi a végrehajtandó validációs tevékenységet hivatott keretbe foglalni, utóbbi (jellemzően) a munkafázisok, felelősségkörök nem iparspecifikus összefogására szolgál, saját gyakorlatunkban azonban ezt egyesített dokumentumként kezeljük.

Általános, hogy jelentőségét bagatellizálják azzal a felkiáltással, hogy validáció úgyis “sztenderd” lépések folyamata, melyet követően validált státuszúnak tekinthető a rendszer, minek ehhez tervet készíteni.

A validációs terv egyfajta összefoglalója, később vonalvezetője annak, hogy milyen rendszert, milyen irányelvek és előírások figyelembe vételével, milyen lépésekben és milyen ütemezés, precedencia szerint, kiknek, milyen szerep/felelősségkörben való részvételével validálunk. Ez, különösen a nagyobb rendszerek esetében szinte kivétel nélkül egymáshoz képest eltérő és nem egyszer összetett procedúra.

Nem készíteni ilyen tervet hiba, sablon tervet használni egy fokkal kisebb, de ez esetben nagyon fontos, hogy egy egyébként mind a validációra, mind pedig az adott rendszerre vonatkozóan jelentős ismerettel és tapasztalattal bíró személy vezesse a folyamatot, hiszen előfordulhat, hogy egyes részei - a sztenderdtől eltérően - más-más hangsúllyal, részletességgel vagy ütemezéssel kell végrehajtásra kerüljenek, melyet egy sablon terv nem képes kezelni.

Ideális esetben a Validációs terv a minőségbiztosítás, a projektmanagement és a műszaki/technológiai szakértők együttműködésének eredménye, így biztosítható, hogy az előírások, a projekt pénzügyi és egyéb ütemezésének figyelembe vétele mellett, a rendszer teljes terjedelmére vonatkozóan teljesüljenek.

A végére hagytuk a különböző specifikációkkal kapcsolatos tapasztalatokat. A “civil” életben egy rendszer életciklusa tervezés szempontjából minimum egy, de általában kettő vagy három szakaszra választható szét: koncepció terv, kiviteli terv és megvalósulási terv. Ezek közül általában a középső az, mely a laikusok szemében egyenértékű a “terv” fogalmával. (részletesen ld. Tervezni (?) kell! című cikkünkben). Ha egy rendszer a GMP hatálya alá esik, akkor a tervezéssel kapcsolatosan is szigorú elvárásoknak kell megfelelni, azonban maga a tervezés folyamata ettől még nem változik meg, tehát minimum van egy kiviteli terv (azaz annak műszaki deklarációja, amit meg kell valósítani) és - amennyiben a rendszer megvalósítása során a tervektől való bármilyen nemű, releváns eltérés szükségessé vált - egy megvalósulási terv. Ezt gyógyszeripari környezetben leginkább az egyes specifikációs dokumentumok újbóli, újabb verzióban történő kiadásával lehet követni, azonban a gyakorlati tapasztalat az, hogy - akárcsak más iparágak esetén - erre nem fordítanak kellő figyelmet, vagy a bürokráciára hivatkozva elkerülik, annak ellenére, hogy a rendszer további életciklusára vonatkozóan (ide sorolva a tesztelést, az üzemeltetést vagy akár a karbantartást) döntő jelentőségű a rendszert átfogóan és naprakészen leíró dokumentáció.

Megjegyzés #1: 

Cikkünk nem tér ki az FS, SDS, HDS és RA kötelező és opcionális formai, tartalmi elemeire. A helyes dokumentációs gyakorlat szerinti felépítésre vonatkozóan számos, akár a világhálón is fellelhető cégünk által is alkalmazott segédlet illetve előírás áll az olvasó rendelkezésére.

Megjegyzés #2: 

A cikk eredetileg 2018. május 4-én jelent meg, melyet azóta frissítettünk, hogy aktuális legyen.