U P O R A B N A I N F O R M A T I K A 932017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Ljubljana Borut Rusjan, Univerza v Ljubljani, Ekonomska fakulteta, Kardeljeva ploπËad 17, 1000 Ljubljana tsallu@gmail.com; borut.rusjan@ef.uni-lj.si 1 UVOD Validacija je dokumentiran postopek preizkuπanja in potrje­ vanja, da vsi procesi, materiali, oprema in sistemi v vseh fazah (razvoj, proizvodnja, kontrola, distribucija) dosegajo predpisane in æelene rezultate (Velkovrh Remec, 2007; Silva, 2013, str. 6). Pojem validacije je πirok in zajema tako rekoË vse ravni v zdruæbi, v Ëlanku pa se bomo posvetili podroËju validacije raËunalniπko podprtih sistemov. V danaπnjem svetu, ko operiramo z elektronskimi zapisi, je moænosti za spreminjanje ali kopiranje vsebin elektronskih za­ pisov, ne da bi to bilo mogoËe dokazati, izjemno veliko. Æe sama funkcija kopiranja namreË ne puπËa nobenih vidnih sledi. Kot navaja European Compliance Academy (2011a, str. 8), tudi v primeru uporabe raËunalniπko podprtih sistemov regulatorni organi æelijo zagotovilo integritete podatkov s pomoËjo zanes­ ljivih sistemov, ki odkrijejo in prikaæejo napake. Da bi zagotovi­ li integriteto podatkov, regulatorni organi zahtevajo validacijo raËunalniπko podprtih sistemov skladno s svojimi zahtevami. Vodilna regulatorna organa v svetu, ki postavljata minimalne pogoje in omejitve tako v sploπnem kot tudi na podroËju raËunalniπko podprtih sistemov v farmacevtski industriji, sta ameriπka organizaci­ ja Food and Drug Administration (v nadaljevanju Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije IzvleËek »lanek doloËa in prikazuje proces validacije raËunalniπko podprtega sistema na praktiËnem primeru v farmacevtski industriji. S pomoËjo procesnih diagramov so predstavljene faze planiranja, specificiranja, izgradnje/razvoja, verifikacije in poroËil, ki predstavljajo pet aktivnosti projektne faze/ validacije raËunalniπko podprtega sistema. Glavni namen validacije raËunalniπkih sistemov sta njihov ustrezen razvoj in delovanje, na podroËju farmacevtske industrije pa je raËunalniπko podprte sisteme treba validirati skladno z zahtevami regulatornih organov. Kot temeljno izhodiπËe smo uporabili metodologijo V-modela pristopa k validaciji. S primerom procesa poteka validacije raËunalniπko podprtega proizvodnega sistema v far- macevtski industriji zagotavljamo temeljitejπe razumevanje same izvedbe validacije v praksi, s poudarkom na upoπtevanju regulatornih zahtev farmacevtske industrije. KljuËne besede: raËunalniπko podprti sistemi, validacija, V-model, farmacevtska industrija, æivljenjski cikel. Abstract Process of computer system validation: Example from the pharmaceutical industry This paper identifies and illustrates the process of computer system validation on a practical example in the pharmaceutical industry. Planning, Specification, Development/Building, Verification and Report represent the key five activities of the project/validation phase of computer-assisted system and are presented via the process diagrams. The basic purpose of computer system validation is to assure the appropriate computer system development and operation. In the pharmaceutical industry, a computer system should be validated in accordance with regulatory requirements. As a starting point, we employed the V-model approach towards validation. Based on the example of computer-assisted produc- tion system validation process in the pharmaceutical industry, we have made possible the profound insight of the execution of computer system validation in practice, with an emphasis on meeting the regulatory requirements of the pharmaceutical industry. Keywords: computerized systems, validation, V-model, pharmaceutical industry, life cycle. ZNANSTVENI PRISPEVKI U P O R A B N A I N F O R M A T I K A94 2017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije FDA) in Evropska agencija za zdravila (angl. Euro­ pean Medicines Agency, v nadaljevanju EMA) (Euro­ pean Commission, 2013; U. S. Food and Drug Admi­ nistration, 2013, 2013a). Regulativa je po eni strani zelo sploπna, po drugi pa precej jasno navaja, kaj od zdruæbe zahteva. Kot navaja Velkovrh Remec (2007), zakonodaji ZDA in EU zahtevata validacijo vseh kritiËnih postopkov, proce­ sov in sistemov ter izobraæenost vseh posameznikov v procesu. Regulatorni organi podajajo tudi πtevilna priporoËila za izvajanje validacij posameznih siste­ mov. Poznamo veË vrst validacij, ena od njih je vali­ dacija raËunalniπko podprtih sistemov, druge pa so, kot navaja Pharmacists Pharma Journal (2010), vali­ dacija ËiπËenj, validacija procesov in validacija ana­ litskih metod. Na podroËju validacije raËunalniπko podprtih sistemov v farmacevtski industriji je skozi Ëas nastal stroki dobro poznani priroËnik Internati­ onal Society for Pharmaceutical Engineering ‡ ISPE GAMP5 (2008), ki regulatorne zahteve na podroËju validacije raËunalniπko podprtih sistemov dobro in­ terpretira in zagotavlja pomoË pri postavitvi sistema kakovosti za validacijo raËunalniπkih sistemov. V farmacevtski industriji in drugih reguliranih organizacijah uporabljajo veliko πtevilo razliËnih ti­ pov raËunalniπko podprtih sistemov, ki variirajo od preprostih samostojnih sistemov do velikih, zelo kompleksnih sistemov (PIC/S 2007, str. 8), zato je raËunalniπko podprte sisteme zaradi laæjega obvla­ dovanja smiselno razdeliti na raËunalniπko podprte proizvodne sisteme in raËunalniπko podprte labora­ torijske sisteme. 1.2 RaËunalniπko podprti proizvodni sistemi To so sistemi, ki s svojim delovanjem (nadzorom, krmiljenjem) podpirajo proizvodnjo, npr. naprave, kot so granulirna naprava, tabletirka, oblagalna naprava, tehtnice, ki imajo lastno krmiljenje, ter raËunalniπki sistem za nadzor proizvodnih procesov in zbiranje podatkov (angl. Supervisory Control and Data Aqui­ sition, v nadaljevanju SCADA). Med raËunalniπko podprte proizvodne sisteme spadajo tudi sistemi za obvladovanje pogojev okolja (angl. Heating, Venti­ lation, Air Conditioning, sistem za ogrevanje, pre­ zraËevanje in klimatizacijo, v nadaljevanju HVAC) in alarmiranja (angl. Alarm Monitoring System, v nada­ ljevanju AMS). V to kategorijo uvrπËamo proizvodne informacijske sisteme in raËunalniπko podprte siste­ me za avtomatizacijo procesov. 1.3 RaËunalniπko podprti laboratorijski sistemi Med raËunalniπko podprte laboratorijske siste­ me uvrπËamo podatkovne sisteme, sisteme, ki so v omreæju in povezani z drugimi sistemi in/ali labo­ ratorijskimi instrumenti, raËunalniπko krmiljene in­ strumente in merilne naprave, ki so krmiljene z mi­ kroprocesorjem ali krmilnikom in/ali procesirajo in hranijo elektronske zapise ali izvajajo manipulacije s podatki. Med raËunalniπko podprte laboratorijske sisteme spadajo na primer naprave za podporo la­ boratorijskih analiz, recimo sistem za visoko loËljivo tekoËinsko kromatografijo (angl. High­Performance Liquid Chromatography), sistem za ultra loËljivo tekoËinsko kromatografijo (angl. Ultra­Performance Liquid Chromatography), sistem za plinsko kroma­ tografijo (angl. Gas Chromatography) ipd. Namen Ëlanka je doloËiti in prikazati proces po­ teka validacije raËunalniπko podprtega sistema na praktiËnem primeru. S primerom procesa poteka validacije raËunalniπko podprtega proizvodnega sis­ tema v farmacevtski industriji zagotavljamo teme­ ljito razumevanje same izvedbe validacije v praksi ter povezave le­te z regulatornimi zahtevami. Kot osnovno izhodiπËe smo uporabili metodologijo V­ ­modela pristopa k validaciji, ki je na podroËju vali­ dacij raËunalniπko podprtih sistemov v farmacevtski industriji najbolj razπirjen. Osnovno raziskovalno vpraπanje Ëlanka je, kako izvesti validacijo raËunalniπko podprtega sistema ob upoπtevanju regulatornih zahtev farmacevtske indu­ strije. ProuËujemo torej, kateri so osnovni elementi pro­ cesa poteka validacije raËunalniπko podprtega sistema, s katerimi zadovoljimo zahteve evropske in ameriπke zakonske ureditve farmacevtske industrije. V teore­ tiËnem delu s pomoËjo metode deskripcije prikaæemo sploπni V­model validacije. V praktiËnem delu upo­ rabimo metodo akcijskega raziskovanja v povezavi s πtudijo primera. Z njo na konkretnem primeru testira­ mo uporabo sploπnega V­modela in doloËimo podpro­ cese za vse faze procesa poteka validacije raËunalniπko podprtega sistema, pri Ëemer zaradi panoæne narave podjetja upoπtevamo regulatorne zahteve. 2 V­MODEL VALIDACIJE RA»UNALNI©KO PODPRTIh SISTEMOV V literaturi lahko najdemo razliËne modele oz. pri­ stope k validaciji raËunalniπko podprtih sistemov (V­model, model 4Q Lifecycle, spiralni model, zapo­ redni oz. slapovni (angl. waterfall) model ipd.), po­ U P O R A B N A I N F O R M A T I K A 952017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije drobneje pa bomo predstavili le V­model validacije, ker je kot model validacije raËunalniπko podprtih sis­ temov najbolj razπirjen in poznan. Prve zametke V­modela, kot ga poznamo danes, so razvili v NemËiji pod imenom V­Modell (prva razliËica je bila predstavljena avgusta 1992) in od leta 2005 predstavlja uradno metodologijo projektnega vodenja za informacijske sisteme nemπke vlade pod imenom V­Modell XT (Industrieanlagen­Betriebsge­ sellschaft ‡ IABG, 2006). V­model (slika 1) predstavlja æivljenjski cikel razvoja in validacije raËunalniπko podprtega sistema in/ali IT aplikacije. Najlaæje ga je razumeti, Ëe je prikazan grafiËno in presekano na levi in desni del, pri Ëemer so predstavljene naËrtovalne aktivnosti na levi in verifikacijske aktivnosti na desni strani. V­model povzema kljuËne korake in sekvence, ki morajo biti izvedeni ob gradnji in validaciji siste­ ma, ki ga razvijamo. Slika 1: GrafiËni prikaz V­modela (Prirejeno po International Society for Pharmaceutical Engineering ‡ ISPE, GAMP 5: A Risk-based Approach to Compliant Gxp Computerized Systems, 2008, str. 27‡37) Pri sami validaciji raËunalniπkih sistemov in IT aplikacij V­model uporabljamo predvsem za namen minimizacije tveganj (na kakovost) raËunalniπko podprtega sistema oz. IT aplikacije ter za izboljπanje kakovosti. Kot navaja International Society for Phar­ maceutical Engineering ‡ ISPE (2008, str. 27‡37) kljuËne toËke V­modela (slika 1) predstavljajo πtiri faze æivljenjskega cikla znotraj projekta (validacije raËunalniπko podprtega sistema):  Planiranje ‡ Faza planiranja naj zajema krovno oceno tve­ ganja sistema (angl. High Level Risk Asses­ sment, v nadaljevanju HLRA), kompleksnost raËunalniπko podprtega sistema z vidika iz­ gradnje in komponent sistema ter rezultate oz. oceno presoje dobavitelja (v primeru, da nam raËunalniπki sistem razvija zunanji dobavitelj ali integrator). ‡ V tej fazi se kreirajo uporabniπke zahteve (angl. User Requirement Specification, v nadaljevanju URS). URS so temeljni dokument za validacijo raËunalniπko podprtega sistema (Stein, 2006, str. 79‡81, in Culin, 2011, str. 32‡33). V URS se definirajo zahteve uporabnikov raËunalniπko podprtega sistema, pri Ëemer je treba poleg pro­ cesnih upoπtevati tudi tehniËne in regulatorne vidike raËunalniπko podprtega sistema. ‡ Validacijo raËunalniπko podprtega sistema pla­ niramo na podlagi dokumenta plan validacije (angl. Validation Plan, v nadaljevanju VP), ki ga potrdijo kljuËne osebe ter ekspert zagotavljanja kakovosti. V VP definiramo obseg raËunalniπko U P O R A B N A I N F O R M A T I K A96 2017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije podprtega sistema, razvojno metodologijo siste­ ma, planirane validacijske aktivnosti in testira­ nja, prav tako predpiπemo sploπne postopke, ki so pomembni za delovanje sistema.  Specificiranje in izgradnja ‡ Dizajn in specifikacije sistema najpogosteje iz­ dela dobavitelj in morajo temeljiti na podanih URS. Pomembno je, da naroËnik oz. uporab­ nik ter vsi, ki so sodelovali pri pisanju URS za raËunalniπki sistem, temeljito pregledajo, ali so specifikacije dizajna, ki so lahko razdeljene na funkcijsko specifikacijo (angl. Functional Speci­ fication, v nadaljevanju FS), programsko dizajn specifikacijo (angl. Software Design Specificati­ on, v nadaljevanju SDS) in strojno dizajn speci­ fikacijo (angl. Hardware Design Specification, v nadaljevanju HDS), pravilne in skladne z URS. Izvedemo kvalifikacijo naËrtovanja (angl. De­ sign Qualification, v nadaljevanju DQ), ki po­ meni, da pregledamo FS, SDS in HDS, in sicer ali so zajete in pravilno interpretirane URS. ‡ Tako lahko priËakujemo, da bo sistem imel vse zahtevane funkcionalnosti in da bo deloval kot specificiran v dizajn dokumentih FS, HDS, SDS. FS je dokument, ki definira, kaj bo sistem delal in katere funkcije lahko izvaja, HDS definira arhitekturo strojne opreme, na primer krmil­ nike, osebne raËunalnike, proizvodno opremo, povezave med posameznimi elementi, SDS pa definira tehniËne funkcije, ki opisujejo funkcio­ nalnosti, zapisane v FS, na primer blok diagra­ me, diagrame stanj, logiËne tabele, strukturo podatkovne baze, standarde kodiranja, verzijo programske opreme ipd. Ko je dizajn dokumen­ tacijo potrdi uporabnik oz. naroËnik, dobavitelj zaËne z izgradnjo sistema skladno s specifikaci­ jami.  Verifikacija ‡ Z verifikacijo sistema potrdimo, da je sis­ tem zgrajen skladno s specifikacijami in da so doseæeni vsi postavljeni kriteriji. To doseæemo s pomoËjo naslednjih vrst testiranja:  kvalifikacija namestitve (angl. Installation Qualification, v nadaljevanju IQ), s katero testiramo dizajn dokumentacijo program­ ske SDS in strojne opreme HDS. Namen IQ je pokazati, da sta strojna in programska oprema nameπËeni skladno s specifikacija­ mi proizvajalca ali dobavitelja;  kvalifikacija obratovanja (angl. Operati­ onal Qualification, v nadaljevanju OQ), s katero testiramo vso dizajn dokumentacijo, vkljuËno s FS, saj veËji del testiramo funkci­ onalnosti raËunalniπko podprtega sistema;  kvalifikacija delovanja (angl. Performance Qualification, v nadaljevanju PQ), s katero (v veËini primerov na produkcijskem oko­ lju) testiramo URS oz. konËni uporabnik izvaja serijo testov, ali raËunalniπki sistem ustreza njegovim zahtevam (ki jih je podal v URS). ‡ Poznamo veË vrst/tipov testnih specifikacij ‡ pozitivne teste, negativne teste, testiranje pono­ vljivosti, performanËne teste, strukturne teste ipd.  PoroËilo ‡ Ko so glede na osnovni VP vse validacijske ak­ tivnosti opravljene in Ëe ni bilo odstopanj pri iz­ vedbi testiranj oziroma so bile v sklopu testiranj vse pomanjkljivosti odpravljene, to potrdimo s poroËilom o validaciji (angl. Validation Report, v nadaljevanju VR), s katerim sistem spustimo v produkcijsko/operativno rabo. 3 ÆIVLJENJSKI CIKEL RA»UNALNIŠKO PODPRTEGA SISTEMA S PRIMEROM VALIDACIJE 3.1 Æivljenjski cikel raËunalniπko podprtega sistema K æivljenjskemu ciklu pri validaciji raËunalniπkih sis­ temov lahko pristopimo na tri razliËne naËine, ki se medsebojno razlikujejo po obsegu oz. se nadgrajujejo (Remén, 2005, str. 24). Kot navaja Remén (2005, str. 24) tako loËimo æivljenjski cikel razvoja raËunalniπko podprtega sistema, æivljenjski cikel implementacije raËunalniπko podprtega sistema in celotni æivljenjski cikel raËunalniπko podprtega sistema. Da zagoto­ vimo regulatorno skladnost in da raËunalniπki sis­ tem deluje znotraj zahtevanih specifikacij, moramo upoπtevati æivljenjski cikel raËunalniπko podprtega sistema (PIC/S, 2007, str. 7), ki nam zagotavlja ra­ zumevanje zahtev, ki jih imamo glede raËunalniπko podprtega sistema, ter sistematiËnost pri razvojnih aktivnostih, implementaciji, uporabi in upokojitvi raËunalniπko podprtega sistema. Slika 2 prikazuje koncept æivljenjskega cikla raËunalniπko podprtega sistema kot celote, sestav­ U P O R A B N A I N F O R M A T I K A 972017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije ljene iz πtirih faz, kakor so navedene v priroËniku GAMP5 (International Society for Pharmaceutical Engineering ‡ ISPE, 2008, str. 26), in poglavitnih pet aktivnosti projektne faze/validacije raËunalniπko podprtega sistema ‡ planiranje, specificiranje, izgrad­ nja/razvoj, verifikacija in poroËilo. Projektna faza je podvræena celotni validaciji raËunalniπko podprtega sistema, pri Ëemer sledi­ mo celotnemu V­modelu, kot je to razvidno s slike 3. Ko se projektna faza konËa, raËunalniπki sistem preide v fazo delovanja, kar pomeni operativno rabo raËunalniπko podprtega sistema. Ko je sistem enkrat v redni uporabi, lahko pride do zahtev uporabnika, da se raËunalniπki sistem nadgradi, lahko pa pride tudi do spremembe procesa ali kakπne druge spre­ membe na raËunalniπko podprtem sistemu. »e gre za spremembe, ki ne vplivajo bistveno na delovanje raËunalniπko podprtega sistema, nam ni treba po­ novno skozi ves proces validacije, temveË izvedemo validacijo le za tisto, kar je na raËunalniπko podpr­ tem sistemu spremenjeno ‡ to na sliki 3 prikazujejo manjπi V­modeli (nad fazo delovanja). SËasoma, ko raËunalniπko podprt sistem veË ne more sluæiti v polnem obsegu ali se ga iz kakrπnih koli drugih razlogov odstrani iz operativne rabe, preidemo v fazo upokojitve, v kateri je treba sistem upokojiti skladno s predpisanimi sploπnimi postop­ ki. Ob upokojitvi raËunalniπko podprtega sistema je treba najveËjo pozornost nameniti hrambi GxP relevantnih elektronskih zapisov (podatkov) na raËunalniπko podprtem sistemu, da ostanejo dostop­ ni pooblaπËenim osebam in v celoti berljivi πe nadalj­ njih nekaj let po upokojitvi raËunalniπko podprtega sistema (obiËajno je ta doba deset let po upokojitvi). V primeru, da upokojeni raËunalniπki sistem nado­ mestimo z novim, lahko izvedemo migracijo podat­ kov v nov sistem in s tem zagotovimo dostopnost podatkov, obenem pa s tem dejanjem (migracijo) preidemo, kot prikazuje slika 3, v konceptualno fazo novega raËunalniπko podprtega sistema, ki ga je tre­ ba validirati. Podrobneje bomo pojasnili projektno fazo, saj je ta kljuËnega pomena, Ëe æelimo uspeπno validirati raËunalniπki sistem. Slika 2: Prikaz modela celotnega æivljenjskega cikla raËunalniπko podprtega sistema Podrobnejπi pregled æivljenjskega cikla raËunal­ niπko podprtega sistema v enakih fazah kot slika 2 prikazuje tudi slika 3. ©iroka puπËica na sliki 3 pri­ kazuje Ëasovnico faz (konceptualna faza, projektna faza, faza delovanja, faza upokojitve), zgornji del sli­ ke (nad puπËico) pa potek aktivnosti na raËunalniπko podprtem sistemu. U P O R A B N A I N F O R M A T I K A98 2017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije 3.2 Primer procesa validacije Farmacevtske in druge zdruæbe, ki delujejo v regu­ lirani panogi, imajo na podroËju validacij (validacije ËiπËenj prostorov/opreme, validacije raËunalniπko podprtih sistemov, validacije procesov itn.) zaposle­ ne strokovnjake, ki so eksperti na podroËju delovanja (validacij), ki ga pokrivajo. To so eksperti za zago­ tavljanje kakovosti (angl. Quality Assurance mana­ ger, v nadaljevanju QA menedæer) in strokovnjaki, ki poleg obvladovanja osnovnih principov validacij de­ lujejo tudi na podroËju elektronskih zapisov in pod­ pisov (angl. eCompliance manager, v nadaljevanju eCompliance menedæer). Vlogi QA in eCompliance sta obiËajno zdruæeni. Validacijo raËunalniπko podprtih sistemov je smi­ selno opredeliti kot projekt (projektna faza), kot to prikazujeta sliki 2 in 3, saj se validacija raËunalniπko podprtega sistema konËa, ko ta preide v fazo delova­ nja (operativno rabo). Za laæjo ponazoritev validacije raËunalniπko podprtega sistema na konkretnem pri­ meru podajamo kljuËne informacije o njem. Tehno­ log v proizvodnji farmacevtskega podjetja æeli roËno vodeni proizvodni proces nadzorovati in krmiliti raËunalniπko. V proizvodnem procesu mora tehno­ log kontinuirano paziti in nastavljati kritiËne proces­ ne parametre, kot so denimo temperatura, hitrost in Ëas meπanja v proizvodnem procesu, da parametri ne gredo iz specificiranih meja. Tehnolog izvaja korake v sekvenci skladno z navodili v proizvodnem poroËi­ lu. Tehnolog je v tem primeru uporabnik, ki zaËne s pisanjem URS za raËunalniπko podprti sistem. V naπem primeru je to SCADA, saj nadzira in krmili proizvodni proces. Poenostavljeno reËeno, tehnolog v naπem primeru torej potrebuje funkcionalnosti sis­ tema SCADA, da mu na zaslonu prikazuje vse infor­ macije, ki jih potrebuje za nemoteno delo, da lahko pogleda podatke o procesu za doloËen Ëas za nazaj v obliki grafa (x os: Ëas, y os: vrednosti kritiËnih pa­ rametrov, npr. temperatura, hitrost meπanja, Ëas meπanja), pomembna pa je tudi moænost reguliranja temperature in hitrosti meπanja. Smiselno bi bilo ime­ ti na sistemu SCADA shranjeno πe recepturo, ki bi samodejno πla skozi sekvence (zaporedje) korakov in izvajala funkcije temperiranja, meπanja ipd., skratka vse, kar je potrebno za izvajanje proizvodnega proce­ sa, popolnoma samodejno. Torej je zahteva uporabni­ Slika 3: Faze æivljenjskega cikla ‡ podrobnejπi pogled (Prirejeno po International Society for Pharmaceutical Engineering ‡ ISPE, GAMP 5: A Risk-based Approach to Compliant Gxp Computerized Systems, 2008, str. 26‡37) Potencialna migracija, hramba el. zapisov Potencialna migracija Zahteve Krovna ocena analize rizika Sprostitev sistema v produkcijsko rabo Sprememba, periodiËni pregledi Upokojitev U P O R A B N A I N F O R M A T I K A 992017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije ka tudi to, da lahko proizvodni proces preko sistema SCADA vodi roËno ali pa da celoten proizvodni pro­ ces vodi SCADA samodejno, tehnolog pa le obËasno preverja stanje in posreduje po potrebi. Temu reËemo avtomatski reæim delovanja sistema SCADA. ProuËi­ tev regulatornih zahtev in strokovne literature (U. S. Food and Drug Administration, 2002, str. 1‡34; U. S. Food and Drug Administration, 2003, str. 1‡9; U. S. Food and Drug Administration, 2004, str. 7‡8; U. S. Food and Drug Administration, 2006, str. 3‡24; U. S. Food and Drug Administration, 2013; U. S. Food and Drug Administration, 2013a; European Commission, 2011, str. 2‡9; European Commission, 2011a, str. 2‡5; European Commission, 2013; European Commissi­ on, 2013a; European Compliance Academy, 2011a, str. 2‡12; European Compliance Academy, 2011b, str. 3‡46; European Compliance Academy, 2011c, str. 3‡31; International Society for Pharmaceutical Engi­ neering ‡ ISPE, 2008, str. 65‡79; PIC/S, 2007, str. 1‡50; Huber, 2012) nas pripelje do sestave procesa poteka projektne faze oz. validacije raËunalniπko podprtega sistema, kot je opisano v nadaljevanju. Moæne so se­ veda variacije, vendar veliko manevrskega prostora glede pristopa vseeno ni. S procesnimi diagrami bomo predstavili primer poteka validacije proizvodnega raËunalniπko pod­ prtega sistema SCADA skozi faze planiranja, speci­ ficiranja, izgradnje/razvoja, verifikacije ter poroËil. Predstavljeni proces poteka projektne faze oz. vali­ dacije raËunalniπko podprtega sistema je odraz la­ stnega sklepanja na podlagi preuËenih in analizira­ nih regulatornih zahtev. 3.3 Proces poteka projektne faze/validacije raËunalniπko podprtega sistema 3.3.1 Planiranje Slika 4 s pomoËjo procesnega diagrama prikazu­ je, kako potekajo prve aktivnosti ob uvedbi novega raËunalniπko podprtega sistema. Slika 4: Procesni diagram ‡ planiranje U P O R A B N A I N F O R M A T I K A100 2017 - πtevilka 2 - letnik XXV Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije V nadaljevanju podajamo podrobnejπi opis posa­ meznih korakov v procesu. [K1] Zahteva po novem sistemu Uporabnik v proizvodnji razmiπlja o novem raËunalniπko podprtem sistemu, ki bi mu podajal koristne informacije iz proizvodnega procesa in s ka­ terim bi upravljal ter nadzoroval proizvodni proces. Uporabnik torej razmiπlja o sistemu SCADA. [K2] Napiπi uporabniπke zahteve (URS) Uporabnik prenese svoje zamisli o raËunalniπko pod­ prtem sistemu, v naπem primeru sistemu SCADA, na papir. Vsaka zahteva ima svoj edinstveni identifika­ tor (npr. URS­01 ipd.), ki nam v nadaljnjih korakih validacije sluæi za sledljivost zahtev, da pri razvoju raËunalniπko podprtega sistema ne izpustimo katere izmed funkcionalnosti, ki jo æelimo imeti v sistemu, hkrati pa s tem laæje preverimo, ali so bile testirane vse funkcionalnosti raËunalniπko podprtega sistema. Ker tehnolog, ki je kot uporabnik sistema SCADA ekspert na podroËju vodenja proizvodnega procesa, obiËajno nima dovolj znanja o regulativi na podroËju raËunalniπkih sistemov, tukaj vstopi menedæer za ka­ kovost (angl. Quality Assurance, v nadaljevanju QA) na podroËju raËunalniπkih sistemov. V naπem prime­ ru menedæer za kakovost na podroËju raËunalniπkih sistemov doda zahteve za obvladovanje integritete podatkov (onemogoËen izbris podatkov, omejen do­ stop do podatkov, uporabniπki nivoji dostopov ipd.), potrebne so tudi zahteve po alarmiranju, ne sme­ mo pozabiti na verzioniranje in hrambo receptur na raËunalniπko podprtem sistemu, omogoËena mora biti tudi zgodovina dogodkov, ki nam pove, kdo je delal na sistemu SCADA, kaj je delal, kdaj je delal in, ob doloËenih pogojih, zakaj je opravil doloËen korak. Dodatno sledijo predpisi obvladovanja dostopov do sistema SCADA, periodiËni pregledi sistema SCADA, obvladovanje odstopanj od dobre proizvodne prakse, obvladovanje sprememb na raËunalniπko podprtem sistemu itd. Svoj deleæ prispevajo πe odgovorna ose­ ba ZVO, odgovorna oseba za informacijsko varnost (angl. Information Security Officer, v nadaljevanju ISEC) itd. Tako nastane dokument URS [R1]. Vsi pod­ pisniki dokumenta URS so avtorji dokumenta. V tabeli 1 navajamo primer URS dokumenta s tre­ mi zelo preprostimi zahtevami po funkcionalnosti raËunalniπko podprtega sistema, v katerem v prvem stolpcu definiramo edinstveni identifikator zahteve zaradi zagotavljanja sledljivosti, v drugem stolpcu navedemo zahtevo za raËunalniπko podprti sistem in v tretjem stolpcu kritiËnost zahteve v smislu potreb po tej zahtevi. Lahko denimo reËemo, da je zahteva obvezna, pomembna ali æelena. [K3] Izvedi krovno oceno analize tveganj (hLRA) S HLRA izvedemo prvotno klasifikacijo raËunalniπko podprtega sistema ‡ GxP relevantnost raËunalniπko podprtega sistema in kategorizacijo raËunalniπko podprtega sistema/aplikacije. RaËunalniπke siste­ me za laæji pristop k validaciji uvrstimo v eno izmed kategorij GAMP, ki za raËunalniπke sisteme v farma­ cevtski industriji predstavljajo standard (Internatio­ nal Society for Pharmaceutical Engineering ‡ ISPE, 2008, str. 128‡132; Tedstonea, 2012; McDowall, 2010, str. 22‡31). Kar se tiËe same kategorizacije sistema SCADA, smo ga v naπem primeru (za nadzor in kr­ miljenje proizvodnje) umestili v kategorijo GAMP4, to pa zato, ker gre za konfigurabilni raËunalniπki sis­ tem. Gre torej za raËunalniπki sistem, ki ga lokalni URS ID Zahteva KritiËnost URS-x-01 … Obvezno/pomembno/æeleno … … … URS-F-49 Zaslonski prikaz nadzornega sistema mora prikazovati celoten proizvodni proces v eni sliki na zaslonu s procesnimi vrednostmi. Obvezno URS-F-50 Nadzorni sistem mora na zaslonskem prikazu prikazovati, kdo je v nadzorni sistem prijavljen, ter datum in Ëas. Obvezno URS-F-51 Nadzorni sistem mora vnesti vse procesne parametre v graf s Ëasom na osi x in vrednostmi parametrov na osi y ter omogoËati realnoËasovni prikaz teh parametrov. Obvezno … … … URS-x-n Uporabniπka zahteva ‡ n Obvezno/pomembno/æeleno Tabela 1: Primer URS ‡ funkcionalnosti v dokumentu URS U P O R A B N A I N F O R M A T I K A 1012017 - πtevilka 2 - letnik XXV integrator oz. dobavitelj priredi potrebam podjetja na podlagi æe obstojeËe aplikacijske platforme iFix. Prav tako v HLRA determiniramo, ali je raËunalniπki sistem 21 CFR Part11 (FDA, 2013b) relevanten (vpraπamo se torej, ali bo sistem hranil elektronske zapise ali bomo uporabljali elektronske podpise). V naπem primeru bo raËunalniπki sistem hranil proce­ sne podatke, ki so klasificirani kot GxP relevantni, zato sistem zapade pod regulativo 21 CFR Part11. Elektronskih podpisov ne bomo uporabljali. Ovre­ dnotimo tudi vpliv na ISEC, vpliv na ZVO ter vplive na obËutljive osebne podatke. Na podlagi rezultata HLRA [R2] se odloËimo, katere validacijske aktivno­ sti raËunalniπko podprtega sistema so potrebne, da sistem ustrezno validiramo. [K4] Izvedi oceno dobavitelja Ker se URS [R1] poπljejo v naπem primeru veË inte­ gratorjem oz. dobaviteljem nadzornih raËunalniπkih sistemov, je treba pred izbiro dobavitelja izvesti pre­ sojo tega z namenom, da ocenimo, ali je sposoben razvijati raËunalniπke sisteme skladno s standardi farmacevtske industrije in internimi standardi pod­ jetja. Presoja se zabeleæi v dokument PoroËilo o oce­ ni dobavitelja [R3]. V primeru, da smo v preteklosti (denimo zadnjih pet let) dobavitelja oz. integratorja æe presojali in je dobil ustrezno oceno, izvedba pre­ soje ob validaciji novega raËunalniπko podprtega sis­ tema/aplikacije ni potrebna. V tem primeru presojo izvedemo le, Ëe je pri dobavitelju priπlo do veËjih or­ ganizacijskih sprememb. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije Slika 5: Procesni diagram ‡ specificiranje U P O R A B N A I N F O R M A T I K A102 2017 - πtevilka 2 - letnik XXV [K5] Izdelaj plan validacije (VP) VP [R4] je dokument, ki opisuje naËin in principe va­ lidacije raËunalniπko podprtega sistema. Podlaga za izdelavo VP so URS [R1] ter HLRA [R2]. Upoπtevamo tudi poroËilo o oceni dobavitelja [R3]. VP na visoki ravni opisuje, katere aktivnosti se planirajo za izved­ bo ustreznega validiranja raËunalniπko podprtega sistema, katere interne predpise oz. sploπne postop­ ke je treba posodobiti, katera izobraæevanja je treba opraviti in kdo se mora izobraziti, kateri dokumenti bodo med postopkom validacije raËunalniπko pod­ prtega sistema kreirani, kdo bo njihov avtor, kdo jih bo pregledal in kdo (katera vloga oz. funkcija v pod­ jetju) potrdil. 3.3.2 Specificiranje Ko je podlaga novega raËunalniπko podprtega siste­ ma definirana in sta izdelana HLRA in VP, se lotimo izdelave funkcionalnosti in specifikacij raËunalniπko podprtega sistema na podlagi danih URS. Slika 5 po­ drobneje prikazuje kljuËne korake za izvedbo. V nadaljevanju podajamo podrobnejπi opis posa­ meznih korakov v procesu. [K6] Izdelaj dizajn dokumente URS [R1] so podlaga za izdelavo FS, SDS in HDS. Dizajn dokumentacijo izdela dobavitelj raËunalniπko podprtega sistema; Ëe gre za interni razvoj, pa jo izdela podjetje samo. V naπem primeru gre za nad­ zorno­krmilni sistem SCADA, ki ga za nas razvija zunanji dobavitelj, zato nam on posreduje ta sklop dokumentacije v pregled. Dobavitelj v svojih dizajn dokumentih opiπe, kako si predstavlja in razume URS, ki jih je dobil od naroËnika, hkrati pa je smiselno, da navede referenco na edinstveni identifikator URS, kot prikazuje tabela 2. Le tako je na pregleden naËin mogoËe zagotoviti, da bo dobavitelj izdelal raËunalniπki sistem skladno z URS. Prikaz je podan v FS, saj pri URS v tabeli 2 govorimo o funkcionalnosti sistema. Ob pregledovanju FS vsa neskladja s podanimi URS zapiπemo in celoto formaliziramo v DQ. »e ob pregledu ni ugotovljenih neskladnosti, je to kljub temu potrebno dokumentirati in formalizirati v DQ. [K7] Izvedi kvalifikacijo naËrtovanja (DQ) V naπem primeru sistema SCADA smo na tej toËki od dobavitelja prejeli v pregled dizajn dokumenta­ cijo, torej FS, SDS in HDS [R5]. Ker je v naπem inte­ resu, da dobimo tak raËunalniπki sistem, kot smo ga definirali v URS [R1], je v tej fazi potreben pregled, ali dizajn dokumentacija, ki nam jo je posredoval do­ bavitelj, dejansko zajema vse naπe zahteve iz URS. Dobavitelj bo namreË raËunalniπki sistem izgradil natanko tako, kot je to definiral v FS, SDS in HDS. Po opravljeni primerjavi med URS in FS, SDS ter HDS odgovorni nosilci podpiπejo zapisnik, ki je nastal ob pregledu in ki ga formalno imenujemo kvalifikacija naËrtovanja ‡ DQ [R6]. V primeru, da so bila v DQ ugotovljena odstopanja glede na URS, mora doba­ vitelj posodobiti dizajn dokumentacijo tako, da bo zajemala vse URS, ali pa uporabnik omeji svoje zah­ teve glede raËunalniπko podprtega sistema in izdela nove URS. Pomembno je poudariti, da se na raËunalniπkih sistemih v farmacevtski industriji lahko omejijo le ti­ ste funkcionalnosti raËunalniπko podprtega sistema, ki nimajo vpliva na regulatorne zahteve, nikakor pa ne moremo omejiti zahtev, ki nam jih posredno pred­ pisujejo regulatorni organi, saj v tem primeru æe v izhodiπËu validiramo raËunalniπki sistem, ki ni skla­ den s predpisano regulativo. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije FS ID Opis funkcionalnosti Referenca na URS FS-xx-01 … URS-x-01 ... ... ... FS-EP-01 Zaslonski prikaz nadzornega sistema vsebuje vse standardne elemente, prikaze in vmesnike za pregled in upravljanje proizvodnega procesa s celotnim tehnoloπkim postopkom, s prikazanimi vsemi potrebnimi parametri, vkljuËno s Ëasovno znaËko in identifikacijo prijavljenega uporabnika. URS-F-49 URS-F-50 FS-HI-01 Prikaz zajetih podatkov v obliki grafa (histografija) je del aplikacije iFix, ki poleg drugih funkcionalnosti omogoËa tudi realnoËasovni prikaz vseh definiranih parametrov. URS-F-51 ... ... ... FS-xx-n … URS-x-n Tabela 2: Primer FS ‡ funkcionalnosti sistema v dokumentu FS U P O R A B N A I N F O R M A T I K A 1032017 - πtevilka 2 - letnik XXV [K8] Izvedi (funkcionalno) analizo tveganj (FRA) Po potrjenih FS, SDS in HDS [R5] vzamemo πe URS [R1] in na podlagi te dokumentacije izdelamo FRA [R7], v kateri ocenimo vsako izmed URS glede na GxP kritiËnost posamezne funkcionalnosti raËunalniπko podprtega sistema (v naπem primeru sistema SCA­ DA), ocenimo moæna tveganja, ki se nam ob napa­ ki ali nedelovanju vsake posamezne funkcional­ nosti lahko pripetijo, ocenimo, v kakπni frekvenci lahko do teh dogodkov pride, ocenimo kritiËnost teh dogodkov z vidika vpliva na kakovost izdelka, ogroæenosti pacientov, varnosti pri delu ipd. ter oce­ nimo moænosti, da odkrijemo nepravilno delovanje ali napako. Na podlagi rezultatov ocen kritiËnosti vsake funkcionalnosti na raËunalniπko podprtem sis­ temu se odloËimo, kakπen naËin testiranja bomo za vsako funkcionalnost izbrali. Testi so lahko preprosti ali kompleksni, vsako odloËitev pa je ob vsaki funk­ cionalnosti treba obrazloæiti in pojasniti, Ëemu smo izbrali doloËen naËin testiranja doloËene funkcional­ nosti raËunalniπko podprtega sistema. Sledita torej vrednotenje in opis tveganj v pri­ meru, da raËunalniπko podprti sistem ne bi deloval sklad no s funkcionalnostmi, navedenimi v FS (v naπem primeru). Kjer so tveganja velika, v fazi ve­ rifikacije raËunalniπko podprtega sistema izvedemo ustrezna IQ, OQ ter PQ testiranja. Primer analize tveganj je razviden iz tabele 3, v kateri ocenimo GxP kritiËnost funkcionalnosti raËunalniπko podprtega sistema (DA/NE), posledice napak oz. odstopanj, moænost nastanka napake ali odstopanja ter moænost neodkritja napake oz. od­ stopanja (V ‡ visok vpliv, moænost, S ‡ srednji vpliv, moænost, N ‡ nizek vpliv, moænost). Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije FS ID Scenarij tveganja/podrobnosti morebitne napake oz. odstopanja GxP kritiËnost funkcionalnosti Vpliv/posledice napake/odstopa Moænost nastanka napake/odstopa Moænost neodkritja napake/odstopa Opomba NaËin testiranja FS-EP-01 Neustrezno vodenje proizvodnega procesa; neustrezen izdelek DA V N N / OQ test FS-HI-01 Ni procesnih podatkov za pregled; ni moænosti pregledovanja procesnih podatkov; neskladnost z regulativami; raziskava odstopanj od dobre proizvodne prakse ni moæna; izdelek ne more na trg. DA V N N / OQ test Tabela 3: Primer FRA 3.3.3 Izgradnja/razvoj Slika 6 prikazuje vloæke, potrebne za izgradnjo raËunalniπko podprtega sistema, prav tako pa rezul­ tat, ki sledi ‡ razvit raËunalniπko podprt sistem ter pripadajoËa tehniËna in uporabniπka dokumentacija. V nadaljevanju podajamo podrobnejπi opis posa­ meznih korakov v procesu. Slika 6: Procesni diagram ‡ izgradnja/razvoj U P O R A B N A I N F O R M A T I K A104 2017 - πtevilka 2 - letnik XXV [K9] Razvoj sistema/aplikacije in dokumentacije V tej fazi zaËnemo z izgradnjo raËunalniπko podpr­ tega sistema (v naπem primeru sistema SCADA). Pri razvoju je treba upoπtevati temeljna naËela razvoja, opredeljena v VP [R4], glavno dokumentacijo za ra­ zvoj pa predstavljajo FS, SDS in HDS [R5]. Rezultat je raËunalniπko podprt sistem, skladen z URS, prav tako pa je v naπem primeru dobavitelj dolæan izdela­ ti tudi tehniËno in uporabniπko dokumentacijo [R9], s katero se morajo pred uporabo raËunalniπko pod­ prtega sistema vsi uporabniki seznaniti in ustrezno izobraziti. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije Slika 7: Procesni diagram ‡ verifikacija U P O R A B N A I N F O R M A T I K A 1052017 - πtevilka 2 - letnik XXV 3.3.4 Verifikacija V sklopu verifikacije preverimo, ali raËunalniπko pod prti sistem deluje skladno s priËakovanji uporab­ nika. Kot je razvidno s slike 7, to preverimo z IQ, OQ in PQ testi. V nadaljevanju podajamo podrobnejπi opis posa­ meznih korakov v procesu. [K10] Planiranje testiranj (glede na VP [R4]) Ko imamo raËunalniπko podprti sistem razvit (v naπem primeru je to sistem SCADA), mora prestati πe testiranja, s katerimi dokazujemo, da sistem deluje brezhibno in skladno s specifikacijami. Obseg in me­ todologijo validacije raËunalniπko podprtega sistema predpisuje VP, plan testiranj [R10] pa podrobneje opisuje, katere IQ, OQ in PQ teste je treba opraviti na raËunalniπko podprtem sistemu. Ko imamo izdelan in odobren plan testiranj, napiπemo IQ [R10.1], OQ [R10.2] in PQ [R10.3] testne specifikacije, v katerih definiramo, kaj testiramo, kako opravimo testiranje in kakπen je priËakovani rezultat. [K11] Izvedba testiranj Teste izvajamo skladno s planom testiranj [R10] na predodobrene testne specifikacije IQ [R10.1], OQ [R10.2] in PQ [R10.3], ki temeljijo na rezultatih iz FRA. Namestitev raËunalniπko podprtega sistema testira­ mo z IQ testom, ki je dokumumentirana verifikacija, da je raËunalnπko podprti sistem nameπËen sklad­ no s predodobrenimi specifikacijami (International Society for Pharmaceutical Engineering ‡ ISPE, 2008, str. 209; International Society for Pharmaceutical En­ gineering ‡ ISPE, 2014); OQ testom, ki je dokumenti­ rana verifikacija, da raËunalniπki podprti sistem de­ luje skladno s predodobrenimi specifikacijami v vseh navedenih obmoËjih delovanja (International Society for Pharmaceutical Engineering ‡ ISPE, 2008, str. 334; International Society for Pharmaceutical Engine­ ering ‡ ISPE, 2014a); in PQ testom, ki je dokumentira­ na verifikacija, da je sistem sposoben delovati in/ali kontrolirati (v naπem primeru proizvodne) procese med delovanjem v produkcijskem okolju skladno s predodobrenimi specifikacijami (International Socie­ ty for Pharmaceutical Engineering ‡ ISPE, 2008, str. 284; International Society for Pharmaceutical Engine­ ering ‡ ISPE, 2014b). Izpolnjene testne specifikacije, ki jih dobimo po izvedenih testiranjih, se imenujejo poroËila o testiranjih. Tako dobimo tri sklope ‡ IQ te­ stna poroËila [R11.1], OQ testna poroËila [R11.2] in PQ testna poroËila [R11.3]. »e se je med testiranjem v testnih korakih pojavila napaka in testiranje ni bilo uspeπno ali je bilo uspeπno le delno, to dokumenti­ ramo kot odstopanje. Tako odstopi kot tudi ustrezna poroËila o testiranjih so popisani v zbirniku testov, ki ga imenujmo poroËilo testiranj in odstopov [R11]. »e si ogledamo nadaljevanje naπega primera, je iz ta­ bele 4 razvidno, da je obe funkcionalnosti raËunalniπko podprtega sistema treba testirati z OQ testom. Sama testna specifikacija mora biti pred zaËetkom izvajanja testa odobrena, testne korake po odobritvi testne spe­ cifikacije izvajamo na kopiji odobrene testne specifika­ cije. PriËakovani rezultat, ustreznost in datum ter pod­ pis vpiπemo roËno v za to predvidena polja soËasno ob izvedbi testa. V tabeli 7 prikazujemo primer OQ testne specifikacije obravnavanega primera, besedilo, ki ga vnaπamo roËno, je oznaËen s sivo barvo. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije Ime testa: OQ­1_test zaslonskega prikaza Predpogoj za izvedbo: Odobrena FS in FRA Korak Ref. URS Ref. FS Opis testa za izvedbo PriËakovani rezultat Dejanski rezultat, referenca na prilogo Ustreza? Datum in podpis 1 URS-F-49 URS-F-50 FS- EP-01 Zaæeni in se prijavi v aplikacijo iFix. Preveri, ali je na zaslonu nadzornega sistema prikazan celoten proizvodni proces, vkljuËno s procesnimi vrednostmi, datumom in uro ter prijavljenim uporabnikom. Na zaslonu je viden celotni proizvodni proces, vkljuËno s procesnimi vrednostmi, datumom in uro ter prijavljenim uporabnikom. Skladen s priËakovanim DA 30. 4. 2014 Janez Novak Tabela 4: Primer OQ testa U P O R A B N A I N F O R M A T I K A106 2017 - πtevilka 2 - letnik XXV [K12] Odprava odstopov V primeru, da imamo po izvedenih testiranjih raËunaliπko podprtega sistema v poroËilu testiranj [R11] evidentirane odstope, jih moramo odpraviti. NaËin odprave odstopanj je odvisen od same napake oz. odstopa na sistemu. Morebiti je treba v teh pri­ merih popraviti tudi sam dizajn raËunalniπko pod­ prtega sistema. Odstop je uspeπno odpravljen, ko je ponovni test, v katerem je priπlo do odstopa, uspeπno opravljen. [K13] Izdelaj matriko sledljivosti (TM) Kar smo od dobavitelja raËunalniπko podprtega sis­ tema zahtevali v URS [R1] in to, kar smo dejansko dobili, je v FS, SDS in HDS [R5], morebitna odstopa­ nja pa smo prav tako pregledali in to dokumentirali v DQ [R6]. Vendar to ni dovolj. Zagotoviti je namreË treba πe sledljivost, pri Ëemer je na pregleden naËin razvidno, ali so vse URS popisane v dizajn doku­ mentih (to preverimo æe v DQ) ter v katerih testih (IQ, OQ, PQ) smo te zahteve testirali. Za zaËetek iz­ delave TM [R12] torej ni treba Ëakati na verifikaci­ jo raËunalniπko podprtega sistema, temveË jo lahko zaËnemo sproti izdelovati æe prej (med kvalifikacijo naËrtovanja ‡ DQ). S tem zagotovimo prvi del sledlji­ vosti, in sicer med URS ter FS, SDS in HDS. Drugi del pa zagotovimo po IQ, OQ in PQ testiranjih, pri ka­ terih dizajn dokumentacijo poveæemo s testnimi po­ roËili. Kot æe omenjeno, vsako uporabniπko zahtevo oznaËimo z edinstvenim identifikatorjem, da potem lahko zagotavljamo sledljivost dizajn dokumentov in testov. »e ugotovimo, da smo izpustili testiranje ka­ tere izmed funkcionalnosti raËunalniπko podprtega sistema, moramo to dokumentirati in retrospektivno izvesti testiranje. Ko konËamo testiranje, lahko v celoti sestavimo TM, s katero preverimo in zagotavljamo, da so bile vse v URS zahtevane funkcionalnosti bile ustrezno upoπtevane in testirane skladno z rezultati FRA. TM za naπ primer je prikazana v tabeli 5. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije Ime testa: OQ­2_test parametrov in zgodovine Predpogoj za izvedbo: Odobrena FS in FRA 1 URS-F-51 FS-HI-01 V iFix odpri flzgodovino«. Preveri, ali nadzorni sistem realnoËasovno vnaπa vse procesne parametre v graf. Nadzorni sistem vnaπa vse procesne parametre v graf. Skladen s priËakovanim Priloga 1 DA 30. 4. 2014 Janez Novak 2 URS-F-51 FS-HI-01 V iFix odpri flzgodovino«. Preveri, ali ima graf na osi x Ëas in vrednosti parametrov na osi y. Graf prikazuje vrednosti parametrov na osi y, Ëas na osi x. Skladen s priËakovanim DA 30. 4. 2014 Janez Novak URS FS SDS hDS IQ OQ PQ Komentar URS-F-49 FS-EP-01 / / / OQ-1_test zaslonskega prikaza ‡ korak 1 / Ustreza URS-F-50 FS-EP-01 / / / OQ-1_test zaslonskega prikaza ‡ korak 1 / Ustreza URS-F-51 FS-HI-01 / / / OQ-2_test parametrov in zgodovine ‡ koraka 1, 2 / Ustreza Tabela 5: Primer TM 3.3.5 PoroËilo Slika 8 prikazuje zadnje aktivnosti, ki so potrebne pred sprostitvijo raËunalniπko podprtega sistema v produkcijsko in operativno rabo. U P O R A B N A I N F O R M A T I K A 1072017 - πtevilka 2 - letnik XXV V nadaljevanju podajamo podrobnejπi opis posa­ meznih korakov v procesu. [K14] Izvedi izobraæevanja Preden gre sistem v produkcijo in operativno rabo, moramo poskrbeti, da so vsi (bodoËi) uporabniki raËunalniπko podprtega sistema izobraæeni o teh­ niËni in uporabniπki dokumentaciji raËunalniπko podprtega sistema. Prav tako je uporabnike treba iz­ obraziti o navodilih oz. postopkih podjetja, ki opisu­ jejo proces in potek dela in jih raËunalniπko podprti sistem krmili. Izobraæevanje uporabnikov dokumen­ tiramo v poroËilo o izobraæevanju [R13], kot priloga poroËilu je lahko priloæen tudi test preverjanja. [K15] Izdelaj poroËilo o validaciji (VR) Ko so vse aktivnosti, predvidene v VP [R4], ustrez­ no opravljene, to popiπemo v VR [R14]. Potrjeni VR pomeni, da je raËunalniπko podprti sistem (v naπem primeru sistem SCADA) uspeπno validiran in lahko gre v redno operativno rabo brez omejitev. Zadnji datum odobritve na VR pomeni datum validacije raËunalniπko podprtega sistema. 4 SKLEP »lanek doloËi sploπni proces validacije raËunalniπko podprtega sistema ter ga prikaæe in pojasni na prak­ tiËnem primeru v farmacevtski industriji. S pomoËjo procesnih diagramov je predstavljen praktiËni pri­ mer poteka validacije proizvodnega raËunalniπko podprtega sistema SCADA skozi faze planiranja, spe­ cificiranja, izgradnje/razvoja, verifikacije ter poroËil. S fazo poroËila se projekt validacije raËunalniπko podprtega sistema konËa in zaËne se faza delovanja, kar pomeni operativno rabo raËunalniπko podprtega sistema. Prikazani proces validacije temelji na uporabi me­ todologije V­modela pristopa k validaciji. »lanek tako potrjuje, da je V­model primerna podlaga za izdelavo procesa poteka izvedbe validacije raËunalniπko pod­ prtih sistemov v farmacevtski industriji. Izkuπnje te visoko regulirane panoge pa za zagotavljanje osnov­ nega namena validacij lahko smotrno uporabimo tudi v drugih manj reguliranih dejavnostih, v katerih je zagotavljanje integritete podatkov kljuËna zahteva delovanja raËunalniπko podprtih sistemov. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije Slika 8: Procesni diagram ‡ poroËilo U P O R A B N A I N F O R M A T I K A108 2017 - πtevilka 2 - letnik XXV »lanek prispeva k razumevanju interpretacije re­ gulatornih zahtev na podroËju validacije raËunalniπko podprtih sistemov v farmacevtski industriji. Za far­ macevtsko industrijo je namreË pomembno, da se vsi dobavitelji in integratorji raËunalniπko podprtih sis­ temov, ki sodelujejo s farmacevtskimi zdruæbami na nivoju GxP relevantnih raËunalniπkih podprtih sis­ temov, zavedajo, da mnoæica predpisov poslediËno velja tudi zanje in da morajo biti sposobni dokazo­ vati, da delujejo skladno z regulatornimi zahtevami, dodatno pa tudi s predpisi in internimi standardi far­ macevtske zdruæbe, s katero sodelujejo. Farmacevt­ ske zdruæbe so namreË dolæne izvajati presoje doba­ viteljev in integratorjev, s katerimi sodelujejo, in te presoje na podroËju raËunalniπko podprtih sistemov postajajo vse stroæje, sodelovanje med zdruæbama se tako lahko hitro znajde na negotovih tleh. Glavna omejitev Ëlanka izhaja iz same metode πtudije enega samega primera, ki omogoËa raziskavo doloËenega podroËja, problema, situacije v globino in v povezavi z doloËenim kontekstom, ki ga v naπem primeru doloËa regulatorni okvir. Za potrditev prika­ zanega sploπnega procesa validacije so tako potrebne nadaljnje πtudije primerov v enakem kontekstu far­ macevtske industrije, smiselne pa so tudi nadaljnje raziskave primernosti prikazanega procesa, oziroma potrebe po njegovi prilagoditvi, poenostavitvi v dru­ gaËnem kontekstu manj reguliranih dejavnosti. 5 LITERATURA IN VIRI [1] Culin, R. V. (2011). New Approach to System Validation. Ap- plied Clinical Trials, 20(2), 32‡37. [2] European Commission (2013a). EU Legislation ‡ Eudralex. Najdeno 2. marca 2017 na http://ec.europa.eu/health/docu- ments/eudralex/index_en.htm. [3] European Commission. (2011). EudraLex ‡ Volume 4 Good Manufacturing Practice Medicinal Products for Human and Veterinary Use, Chapter 4: Documentation. Najdeno 2. mar- ca 2017 na http://ec.europa.eu/health/files/eudralex/vol-4/ chapter4_01-2011_en.pdf. [4] European Commission. (2011a). EudraLex ‡ Volume 4 Good Manufacturing Practice Medicinal Products for Human and Veterinary Use, Annex 11: Computerized Systems. Najdeno 2. marca 2017 na http://ec.europa.eu/health/files/eudralex/ vol-4/annex11_01-2011_en.pdf. [5] European Commission. (2013). EudraLex ‡ Volume 4 Good ma- nufacturing practice (GMP) Guidelines. Najdeno 2. marca 2017 na http://ec.europa.eu/health/documents/eudralex/vol-4/. [6] European Compliance Academy (2011a). Introduction to Requirements. ECA Education Course ‡ Computer Validation The GAMP5 Approach. Vienna, Austria: Concept Heidelberg GmbH. [7] European Compliance Academy (2011b). Validation Planning. ECA Education Course ‡ Computer Validation The GAMP5 Approach. Concept Heidelberg GmbH. [8] European Compliance Academy (2011c). Specifications, De- sign Review & Traceability. ECA Education Course ‡ Compu- ter Validation The GAMP5 Approach. Vienna, Austria: Con- cept Heidelberg GmbH. [9] Huber, L. (2012). Computer System Validation ‡ Tutorial. Naj- deno 2. marca 2017 na http://www.labcompliance.com/tuto- rial/csv/. [10] Industrieanlagen-Betriebsgesellschaft ‡ IABG. (2006). Will- kommen auf den V-Modell-Seiten der IABG. Najdeno 18. janu- arja 2014 na http://v-modell.iabg.de/index.php?option=com_ content&task=view&id=10&Itemid=1. [11] International Society for Pharmaceutical Engineering ‡ ISPE. (2008). GAMP 5: A Risk-based Approach to Compliant GxP Computerized Systems. Tampa, Florida: International Society for Pharmaceutical Engineering. [12] International Society for Pharmaceutical Engineering ‡ ISPE. (2014). ISPE Glossary of Pharmaceutical and Biotechnology Terminology. Najdeno 2. marca 2017 na http://www.ispe.org/ glossary?term=Installation+Qualification+%28IQ%29. [13] International Society for Pharmaceutical Engineering ‡ ISPE. (2014a). ISPE Glossary of Pharmaceutical and Biotechnology Terminology. Najdeno 2. marca 2017 na http://www.ispe.org/ glossary?term=Operational+Qualification+%28OQ%29. [14] International Society for Pharmaceutical Engineering ‡ ISPE. (2014b). ISPE Glossary of Pharmaceutical and Biotechnology Terminology. Najdeno 2. marca 2017 na http://www.ispe.org/ glossary?term=Performance+Qualification+%28PQ%29. [15] McDowall, R. D. (2010). Understanding and interpreting the GAMP5 life cycle models for software. Spectroscopy, 25(4), 22‡31. [16] Pharmacists Pharma Journal (2010). Validation in Pharmace- utical Industry Types of Pharma Validation. Pharmacists Phar- ma Journal. Najdeno 2. marca 2017 na http://www.pharmaci- stspharmajournal.org/2010/03/validation-in-pharmaceutical. html#.U2dNoKJrVLN. [17] PIC/S (2007). Pharmaceutical Inspection Co-Operation Sche- me Guidance ‡ Good Practices For Computerised Systems In Regulated Gxp Environments. Najdeno 23. decembra 2013 na http://www.picscheme.org/pdf/27_pi-011-3-recommen- dation-on-computerised-systems.pdf. [18] Remén, J. (2005). Lifecycle approach to Computer Systems Validation. Computer Systems and Software Validation ‡ Pro- ceedings Book. Duluth, MN: Institute of Validation Technology. [19] Silva, E. J. (2013). Computer System Validation. Najdeno 2. marca 2017 na http://www.slideshare.net/ericjsilva/compu- ter-system-validation-17173238#. [20] Stein, T. R. (2006). The Computer System Risk Management and Validation Life Cycle. Chico, CA: Paton Press. [21] Tedstone, B. (2012). Computer Systems Validation. Computer Systems Validation and Quality Assurance blog. Najdeno 2. marca 2017 na http://computersystemsvalidation.blogspot. com/2012/11/GAMP-Software-Category.html. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije U P O R A B N A I N F O R M A T I K A 1092017 - πtevilka 2 - letnik XXV [22] U. S. Food and Drug Administration ‡ FDA (2002). General Principles of SoftwareValidation; Final Guidance for Industry and FDA Staff. U. S. Department Of Health and Human Ser- vices Food and Drug Administration. Najdeno 2. marca 2017 na http://www.fda.gov/downloads/MedicalDevices/Device- RegulationandGuidance/GuidanceDocuments/ucm085371. pdf. [23] U. S. Food and Drug Administration ‡ FDA (2003). Guidance for Industry Part 11, Electronic Records; Electronic signatures ‡ Scope and Application. U. S. Department of Health and Human Services. Najdeno 2. marca 2017 na http://www.fda.gov/down- loads/RegulatoryInformation/Guidances/ucm125125.pdf. [24] U. S. Food and Drug Administration ‡ FDA (2004). Pharmace- utical cGMP‘s for The 21St Century, A Risk Based Approach, Final Report. U. S. Department Of Health and Human Servi- ces Food and Drug Administration. Najdeno 2. marca 2017 na http://www.fda.gov/downloads/Drugs/DevelopmentApproval- Process/Manufacturing/QuestionsandAnswersonCurrentGo- odManufacturingPracticescGMPforDrugs/UCM176374.pdf. [25] U. S. Food and Drug Administration ‡ FDA (2006). Guidan- ce for Industry, Quality Systems Approach to Pharmaceutical CGMP Regulations. Najdeno 2. marca 2017 na http://www. fda.gov/downloads/Drugs/.../Guidances/UCM070337.pdf. [26] U. S. Food and Drug Administration ‡ FDA (2013). CFR ‡ Code of Federal Regulations Title 21, Volume 4 ‡ Part 211 Current Good Manufacturing Practice for Finished Pharmaceuticals. Najdeno 2. marca 2017 na http://www.accessdata.fda.gov/ scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211. [27] U. S. Food and Drug Administration ‡ FDA (2013a). CFR ‡ Code of Federal Regulations Title 21, Volume 4 ‡ Part 11 Electronic Records; Electronic Signatures. Najdeno 2. marca 2017 na http://www.accessdata.fda.gov/scripts/cdrh/cfdo- cs/cfcfr/cfrsearch.cfm?cfrpart=11. [28] Velkovrh Remec, B. (2007). Validacije v farmacevtski indu- striji. Najdeno 2. marca 2017 na http://www.scribd.com/ doc/23022819/VALIDACIJE. Tomaæ Sallubier, Borut Rusjan: Proces validacije raËunalniπko podprtih sistemov: primer farmacevtske industrije  Tomaæ Sallubier je leta 2014 magistriral na Ekonomski fakulteti Univerze v Ljubljani, pred tem pa diplomiral na Fakulteti za organizacijske vede Univerze v Mariboru ter na viπji strokovni πoli na podroËjih organizacije in menedæmenta ter informacijskih tehnologij. Kot ekspert upravljanja kakovosti na podroËju raËunalniπkih sistemov je zaposlen v veËjem farmacevtskem podjetju, v katerem je odgovoren za postavljanje sistema kakovosti na podroËju IT-sistemov, validacije IT-sistemov, izobraæevanja ter izvedbo internih in zunanjih presoj dobaviteljev. Deluje tudi na æivilsko-prehrambnem podroËju kot pooblaπËena oseba za kakovost za klavnico ter obrat predelave mesnih izdelkov; uspeπno je izdelal sistem kakovosti, vkljuËno s HACCP, sedaj pa to stanje vzdræuje in sodeluje z nadzornimi organi Uprave RS za varno hrano, veterinarstvo in varstvo rastlin (UVHVVR).  Borut Rusjan je kot redni profesor zaposlen na Ekonomski fakulteti Univerze v Ljubljani, kjer je nosilec in izvajalec predmetov Management proizvodnih in storit- venih procesov (dodiplomski πtudij), Proizvodni management in Management poslovne odliËnosti (podiplomski πtudij). Raziskovalno se ukvarja s problematiko strategije izdelavne poslovne funkcije ter uporabe sodobnih proizvodnih in poslovnih konceptov: poslovna odliËnost, obvladovanje celovite kakovosti, prenova poslovnih procesov. Je avtor ali soavtor 33 izvirnih znanstvenih Ëlankov, objavljenih v slovenskih in tujih znanstvenih revijah. Je Ëlan uredniπkega odbora revije Quality Management Journal in Ëlan sveta delovne skupine za spremljanje in vrednotenje Strategije razvoja javne uprave 2015‡2020.